Le vendredi 30 Juillet 2004 15:24, Douglas Otis a écrit :
What about the following idea :
- Suppose that our outgoing SMTP servers encode _all_ of their
outgoing MAIL FROM with SRS, whether or not the message is a forward,
and whether or not it initially comes from our own domain.
As SRS replaces the domain to match the forwarding SPF environment, the
return path attempts to colapse to two steps of this process. If a
forwarding process does not perform this function, then the message is
rejected, as now the SPF environment is wrong.
I don't quite understand your point, as you are mixing SRS and SPF. I was
discussing SRS as a way to detect forged bounces, and this can work
completely independently from SPF.
Rather than rewriting the return path, the concept is to use a public
key
Which concept ? There is quite a number of concepts discussed here ;-)
Validation is not limited to just the sending domain.
- Now we can reject all "bounces" (MAIL FROM: <>) that we would
receive, which RCPT TO: wouldn't be a valid SRS address.
Because if this were a legit bounce, then it would be a reply to one
of our own messages, and would thus go to a valid SRS address.
BATV always allowed that.
As far as I understood (but correct me if I'm mistaken), a BATV address is
replayable if it doesn't have a validity duration limit, which the draft I
saw doesn't very clearly specify.
BATV did include a timestamp. I admit, the draft is just an outline.
There are several otheres working to make this draft more complete.
On the other hand, SRS addresses have only a limited validity in time, so
they are replayable only for a short period, which would make them of no
interest harvesting for spammers.
It would prevent the return path being used to avoid accreditation. It
would not prevent a replay attack to different MTAs spoofing as the
original message. This would be assuming the return path was being
validated as part of the acceptance process. That is not required for
this be useful.
And bounce validity checking using SRS wouldn't need any public key to be
published in DNS, nor any cooperation from the "bouncing side", it can be
implemented by the "side receiving the bounce" alone, without any impact.
If the sending side could know when a return path was being used, that
would be good, if only to ensure the return path on the bounce messages
was null.
i.e. If I decide tomorrow to patch my MTA so that _any_ outgoing mail from
my domain has an SRS <MAIL FROM>, and then that I will reject any DSN
directed to any address other than a valid SRS address, then I can close
the door to any spam or virus disguised as a DSN, as it wouldn't have a
valid destination.
You will still be struggling with some of this traffic. It will be
reduced. As I said, not all of this traffic uses a null return.
There are virus filtering programs and other noncompliant applications
that attempt to "bounce" with a non-null return path. If there were an
encoding of the return path that could be recognized and checked before
the bounce were allowed, the sending side would then be helpful getting
rid of that class of traffic.
If there were a recognizeable encoding of a return path (that would
indicate it to be a return path), then the sending side could help ensure
the message sent using this return path, would itself ensure this message
contained a null (MAIL FROM: <>) return path as a means to acknowledge it
was sending a bounce.
This concern is with respect to preventing double bounces. If the
encoding is understood, and can be validated by the sender, and this is
discovered to be not valid, then the bounce can be dropped.
-Doug