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?
Best Answer
Let's split it per statement
Yes, this misconfigured server rejects all email with sender <>.
Yes, this workaround will prevent misconfigured remote server reject email with sender <>.
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).
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.
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