spf-discuss
[Top] [All Lists]

RE: a "never relays" parameter

2004-06-10 23:49:20
From: Graham Murray
Sent: Friday, June 11, 2004 1:08 AM


"Seth Goodman" <sethg(_at_)GoodmanAssociates(_dot_)com> writes:

Since you propose that recipient MTA's should all maintain
trusted forwarder
lists, is there really any need for originator tests?  Playing
the devil's
advocate here, if all recipients maintained trusted forwarder
lists, there
really isn't any need for SRS, either.  If we need SRS because
not all sites
have forwarder whitelists, we also need originator tests, since those
recipients can't distinguish a trusted forwarder from a forger.
How do we reconcile this?

What about people who (for whatever reason) use a chain of
forwarders? The final forwarder could be in the recipient's trusted
forwarder list, and the first forwarder can do checks on the original
sender, but will the mail not fail the checks when passed between
forwarders? Using SRS will allow this to work.

Unless the forwarders whitelisted each other, you are right, an address
rewriting protocol is needed.

In that case, we are back to square one.  If an address rewriting protocol
is needed, we currently have three choices: RSR, SUBMITTER and SRS.  For an
end recipient, unless their site has a trusted forwarder list, they can't
necessarily trust MAIL FROM: addresses on forwards to send DSN's to.  We can
provide the tools for sending sites to provide validation of their signed
originating addresses through DNS, but we can't force them to adopt them.
Since hosted sites have little control over their DNS, there will probably
be a lot of sites whose originating addresses will be unverifiable via DNS.

Therefore, in the absence of a trusted forwarder list at recipient sites,
there will be cases where a DSN should be sent in response to a forwarded
message but the originator address can't be verified.  Sending the DSN risks
abusing an innocent third party and silently dropping the message is equally
wrong.  It appears that the only way to avoid this situation is to maintain
a local list of trusted forwarders.  If this analysis holds up, we probably
need to make that clear in the standard.  Just providing the whitelist
function in the reference library is not sufficient.  If recipient trusted
forwarder whitelists are integral to the correct operation of the whole SPF
system, it needs to be in the standard.  That won't make everyone do it, but
more sites will do it if it _is_ in the standard than if it isn't.

This is another reason that we should _strongly_ recommend SES or SRS at the
originator to protect sites from DSN's resulting from forgeries.  Since we
can't force other sites to adopt measures to avoid sending out bogus DSN's,
at least we can protect ourselves from the results of their failure to
operate responsibly.

--

Seth Goodman