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 ;-)
- 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.
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.
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.
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 ou virus disguised as a DSN, as it wouldn't have a valid
destination.
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.
I have read this paragraph 5 times and don't get your meaning at all ;-)
Regards.
--
Michel Bouissou <michel(_at_)bouissou(_dot_)net> OpenPGP ID 0xDDE8AC6E