2

This Wikipedia article describes how SMTP verification of the MFROM may have issues if BATV is enabled.

Servers that reject all bounce mails (contrary to the RFCs). 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. This work-around, however, will fail if Bounce Address Tag Validation is used to reduce backscatter.[3] 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.1[2]

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?

1 Answer 1

1

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:<[email protected]>
R: 250 OK

S: RCPT TO:<[email protected]>
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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .