nanog mailing list archives
Re: Spamhaus...
From: James Hess <mysidia () gmail com>
Date: Sat, 20 Feb 2010 16:57:17 -0600
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
Current thread:
- Re: Spamhaus..., (continued)
- Re: Spamhaus... Nick Hilliard (Feb 18)
- Re: Spamhaus... Christopher Morrow (Feb 18)
- Re: Spamhaus... John Levine (Feb 18)
- Re: Spamhaus... Marc Powell (Feb 19)
- Re: Spamhaus... Michelle Sullivan (Feb 19)
- Re: Spamhaus... Nick Hilliard (Feb 18)
- Re: Spamhaus... Larry Sheldon (Feb 19)
- Re: Spamhaus... Marc Powell (Feb 20)
- Re: Spamhaus... Patrick W. Gilmore (Feb 20)
- Re: Spamhaus... Roger Marquis (Feb 20)
- Re: Spamhaus... Robert Bonomi (Feb 20)
- Re: Spamhaus... James Hess (Feb 20)
- Re: Spamhaus... Jon Lewis (Feb 20)
- Re: Spamhaus... James Hess (Feb 20)
- Re: Spamhaus... John Levine (Feb 20)
- Re: Spamhaus... Graeme Fowler (Feb 21)
- Re: Spamhaus... James Hess (Feb 20)
- Re: Spamhaus... Michelle Sullivan (Feb 21)
- Re: Spamhaus... Jon Lewis (Feb 21)
- Re: Spamhaus... Tony Finch (Feb 21)
- Re: Spamhaus... Michelle Sullivan (Feb 21)
- Re: Spamhaus... Jon Lewis (Feb 21)
- Re: DNSBLs other than Spamhaus... John Levine (Feb 21)