Does the RFC say what to do if the reverse-path has been damaged and now points to somebody who had nothing what ever to do with the email? Do the TCP RFCs say what to do in response to a SYN packet, if the source IP address has been damaged, and now points to some source IP that has "nothing whatever" to do with the packet?
You can only do the best possible -- discard the packet, if something allows you to determine the SYN is obviously spoofed or invalid, sure, drop it, otherwise you have no real choice. With SMTP there are many cases where you have no choice but to 250 the message, and send a DSN/bounce back later. E-mail users expect that when they send someone a message, it gets there in 6 hours or less, or they get an error within 6 hours. The purpose of SMTP protocol is to provide reliable mail delivery, which includes reporting errors. Spurious DSNs are less harmful than missing DSNs. Spurious DSNs can be discarded easily by the mail server that knows it didn't pass that message. DSNs that were not generated cannot be recovered. Discarding is currently the responsibility of the mail server whose address has been forged. Just like it's the responsibility of a host whose source address was forged in a TCP transaction, to discard the "ACK" packet for a connection that resulted from a spoofed SYN. The mail server sending DSN for the fake message, or replying to a spoofed SYN is not a spammer in any way, they are actually a victim wasting their own bandwidth responding to a bogus message. They have no real choice in the matter -- Weaknesses in SMTP protocol and lack of SPF implementation forced them into this position, they can't tell if the "MAIL FROM" line is real, anymore than a host on the internet can look at a source IP on a packet and know it's real or not. In the general case, Basic DNS and SPF tests are basically all the receiving mail server has to work with in "validating" return path. And they should perform these tests, before responding 250. When you responded with "250 Message accepted for delivery", that says you were satisfied that the message was legitimate, and the RETURN PATH and TO address is verifiable as far as you can tell. You can't NOT send DSNs if a failure occurs after that point, that is contrary to the requirements for reliable mail delivery. Rliable storage and delivery of legitimate messages is just as important as suppression of noise. Without reliable delivery, we don't really have a such thing as "internet mail" anymore. And by the way, a backup MX cannot verify the recipient when the primary MX is down. Especially when the backup MX is hosted off-site by another provider. The job of the backup is to hold mail in queue until the main mail system is back in operation, so "recipient verification" cannot actually be guaranteed. The perimeter MX also has no idea, that the recipient's mailbox has run out of disk space and cannot store the message, or that the alias points to a catch-all address on a different provider's mail server, where the user's account has been deleted. Some backscatter is to be expected as long as we have a reliable mail system, and it relies on returning messages via DSN to unverifiable MAIL FROM addresses. I only really see three options here.... give up on reliable mail delivery (might as well abandon SMTP entirely then, and replace it with a simpler protocol), revise SMTP to allow authentication of 'MAIL FROM', Or revise SMTP to require somehow validating the entire delivery path before "250 OK" can be accepted for any RCPT TO line. As in, eliminating the ability for mail servers to 'queue' messages for delivery. Instead when you issue 'RCPT TO', your mail server must immediately connect to the next hop mail server, start the SMTP transaction, and get an OK for that 'RCPT TO' prior to returning "Recipient OK" back to you. So you getting 250 OK to "RCPT TO" means every mail server in the delivery path simultaneously has a port 25 connection open to the next hop, has just returned 250 to the same RCPT TO line. -- -Mysid