>> > 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
