Problem was that I did not have this particular settings in postfix configuration:
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
check_relay_domains
Let's split it per statement
Servers that reject all bounce mails (contrary to the RFCs).
Yes, this misconfigured server rejects all email with sender <>.
To work around this problem, postfix, for example, uses either the local postmaster address or an address of "double-bounce" in the MAIL FROM part of the callout.
Yes, this workaround will prevent misconfigured remote server reject email with sender <>.
This work-around, however, will fail if Bounce Address Tag Validation is used to reduce backscatter.
BATV was technique to verifying the bounce email to preventing backscatter. It works by rewrite the original sender to some cryptographic token. BATV checker only check the recipient address of an email if the sender was set to <>. If some MTAs used postmaster@ address to perform callback verification, the system won't pass the email to BATV checker (because it's not bounce) but rejecting them because the recipient doesn't exist (only BATV checker can verify if the recipient was match its cryptographic token).
Callback verification can still work if rejecting all bounces happens at the DATA stage instead of the earlier MAIL FROM stage, while rejecting invalid e-mail addresses remains at the RCPT TO stage instead of also being moved to the DATA stage.
Note: This statement doesn't have relation with BATV. It addressed the first problem (Servers that reject all bounce mails (contrary to the RFCs)).
So, we has two rejection process here, because 1) the recipient doesn't exist or 2) it is bounce address (identified by <>). After a client (the verifier) issued RCPT TO, the server will perform a checks to verify that the recipient address was exist. If the recipient was exist then server will reply with code 2XX OK.
Because of that, the verifier will assume that the address was OK and it will disconnect. However, the real bounce email will enter DATA stage (the email header/body haven't been sent yet...), in this stage server will reject it because of bounce email.
The resolution is to verify the address in the "Data". Since the Data isn't verified (assuming DKIM isn't being used), can't this be spoofed and isn't this a weak workaround?
No, it doesn't verify the address in the DATA (maybe you mean the address in the email header). In fact, the header haven't been sent but the server already rejected it.
Here the illustration to explain where the rejection occurs. The original source
R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
S: HELO USC-ISIF.ARPA
R: 250 BBN-UNIX.ARPA
S: MAIL FROM:<Smith@USC-ISIF.ARPA>
R: 250 OK
S: RCPT TO:<Jones@BBN-UNIX.ARPA>
R: 250 OK <--- "non existed address" rejection occurs here
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF> <--- "bounce" rejection occurs here
S: Blah blah blah... <--- email header and body
S: ...etc. etc. etc.
S: .
R: 250 OK
S: QUIT
R: 221 BBN-UNIX.ARPA Service closing transmission channel
Best Answer
The short answer is yes. The way to do it is to enable
esmtpd-msa
.Courier supports a Mail Submission Agent (MSA) which is just like a Mail Transport Agent but is intended for non-local mail injection. MSA servers not only listen on different ports (587), but are capable of correcting minor errors in the SMTP data from the client's mailer. The other main benefit is that you can easily and simply disable relaying from external hosts on the MTA and enable authorisation on the MSA. This neatly gets around trying to authenticate from particular domains which is almost impossible because the authentication request happens before the from domain is provided.
The biggest downside is that you have to change all your clients to send mail to port 587 instead of port 25.