Spamhaus...

Sat Feb 20 22:57:17 UTC 2010

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