Authentication is not required to send mail as a local domain user to another local domain user over port 25 remotely.

[Aterfax]

When connecting with telnet to port 25 you are able to send email from a local user to themselves or another user without needing to authenticate. This allows impersonation of other users on the mail domain which is problematic for numerous reasons.

Affects current docker but I have not tested older versions. Tested as vulnerable on 2 separate instances, spam filter will catch these if emails are formatted as badly as below but I saw a spearphishing email using this technique in the wild yesterday on a live instance.

To replicate:

telnet mail.yourdomain.com 25

Connected to mail.domain.com.
Escape character is '^]'.

220 mail.domain.com ESMTP Haraka/2.8.27 ready
EHLO domain.com
250-mail.domain.com Hello localdomain.local [X.X.X.X], Poste.io is at your service
250-PIPELINING
250-8BITMIME
250-SMTPUTF8
250-SIZE 26214400
250 STARTTLS
MAIL FROM:[e-mail]
250 sender [e-mail] OK
RCPT TO:[e-mail]
250 recipient [e-mail] OK
DATA
354 go ahead, make my day
Subject: The authentication is not required to send this email which is bad.

From: [e-mail]

I'm pretending to be an administrator!

.

250 Message Queued (8CI72C035GA10L12-XXXX-XXXX-XXXX-D8867195C4FF.1) (8CI72C035GA10L12-XXXX-XXXX-XXXX-D8867195C4FF.1)

p.s. you might wanna set this issue as invisible.

[Aterfax]

I have now seen another attempted spearphishing attempt using this.

[Aterfax]

And another attempted spearphishing attempt using this.

[Varant Ghougassian]

Tried to recreate this on my own server using exactly these steps. Everything went exactly the same, except instead of queuing the message, it quarantined the email instead. I’m unsure if the expected behavior is to allow progression through the steps until the attempted send; I’m also unsure what specific criteria identified this as a threat and whether sending messages through this route would quarantine consistently.

‌

telnet mail.domain.com 25
Trying XX.XX.XX.XX...
Connected to mail.domain.com.
Escape character is '^]'.
220 mail.domain.com ESMTP Haraka/2.8.28 ready
EHLO domain.com
250-mail.domain.com Hello pool-XX-XX-XX-XX.XXXXXX.fios.verizon.net [XX.XX.XX.XX], Poste.io is at your service
250-PIPELINING
250-8BITMIME
250-SMTPUTF8
250-SIZE 26214400
250 STARTTLS
MAIL FROM:[e-mail]
250 sender <[e-mail]> OK
RCPT TO:[e-mail] 
250 recipient <[e-mail]> OK
DATA
354 go ahead, make my day
Subject: This is a fake subject line

From: [e-mail]

This body was generated through Telnet

.
250 Quarantined! (925EE97D-FD9E-41DC-BAFF-9772C61DA801.1)

‌

[Aterfax]

Yes, I have seen some attempts get caught by the quarantine filter but it doesn’t always flag them. In any case, the mail should never be accepted and sent without authentication first taking place.

[Aterfax]

Given the total lack of interest from the maintainer for a critical issue I would recommend that all admins/users of Poste start migrating to another solution.

Who knows what other issues are present.

[SH]

Sorry, not an bug. SMTP has very wide problematic, its not only user->server protocol or sending server->receiving server protocol and it has lot of corner cases which might broke if you start tightening policies like you suggest. But these messages should be delivered anyway, see example:

     sh@hovnocuc ~ swaks -f [e-mail] -t [e-mail] -s gmail-smtp-in.l.google.com
    === Trying gmail-smtp-in.l.google.com:25...
    === Connected to gmail-smtp-in.l.google.com.
    <-  220 mx.google.com ESMTP qw34-20020a1709066a2200b00726b8c59accsi22416383ejc.787 - gsmtp
     -> EHLO hovnocuc
    <-  250-mx.google.com at your service, [178.248.60.83]
    <-  250-SIZE 157286400
    <-  250-8BITMIME
    <-  250-STARTTLS
    <-  250-ENHANCEDSTATUSCODES
    <-  250-PIPELINING
    <-  250-CHUNKING
    <-  250 SMTPUTF8
     -> MAIL FROM:<[e-mail]>
    <-  250 2.1.0 OK qw34-20020a1709066a2200b00726b8c59accsi22416383ejc.787 - gsmtp
     -> RCPT TO:<[e-mail]>
    <-  250 2.1.5 OK qw34-20020a1709066a2200b00726b8c59accsi22416383ejc.787 - gsmtp
     -> DATA
    <-  354  Go ahead qw34-20020a1709066a2200b00726b8c59accsi22416383ejc.787 - gsmtp
     -> Date: Wed, 20 Jul 2022 10:34:33 +0200
     -> To: [e-mail]
     -> From: [e-mail]
     -> Subject: test Wed, 20 Jul 2022 10:34:33 +0200
     -> Message-Id: <20220720103433.1791680@hovnocuc>
     -> X-Mailer: swaks v20190914.0 jetmore.org/john/code/swaks/
     ->
     -> This is a test mailing
     ->
     ->
     -> .
    <-  250 2.0.0 OK  1658306073 qw34-20020a1709066a2200b00726b8c59accsi22416383ejc.787 - gsmtp
     -> QUIT
    <-  221 2.0.0 closing connection qw34-20020a1709066a2200b00726b8c59accsi22416383ejc.787 - gsmtp
    === Connection closed with remote host.

Thats why DKIM, SPF and other detection methods were invented...

[Aterfax]

This is not some SMTP protocol problem that I am aware of, it seems to be a “badly configured setup” problem.

The MTA should not allow unauthenticated email forwarding/sending as local users from non-trusted IP addresses. Public IP addresses should not be able to impersonate a local user email account and stand a good chance (only sometimes getting caught by a spam filter? DKIM and SPF are both are applied on my domain) of LMTP delivering to the target local users' inboxes.

In simple terms, the mail server when accepting/forwarding email to local users with the From: field also being a local user for the domain/s it serves, should be enforcing an authentication check. The mail server should still quite happily continue forwarding email to local users where a non-local user is in the From: field without the authentication being required.

It has been a long while since I manually configured Postfix but I am fairly sure the above setting is quite possible, even with LAN devices on trusted IPs being able to send mail without requiring authentication from any local user or it causing any problems whatsoever.

Edit: This appears to have been discussed here: https://serverfault.com/a/51122