ietf-mxcomp
[Top] [All Lists]

Re: (DEPLOY) In Support of Sender ID

2004-09-03 09:15:05

On Thu, 2 Sep 2004 mazieres(_at_)gmail(_dot_)com wrote:

My challenge remains... describe a concrete scenario that requires
Sender ID, and that could not achieve the same effective result with
SPF-classic.  Vague references to banks don't convince me any more,

The following is not a vague reference, but an actual planned deployment
(I just can't tell you who is planning it for obvious reasons):

Large Bank communicates with numerous customers addresses at Large ISP.
Large ISP has indicated that they will verify inbound authentication
credentials and has negotiated preferred delivery of authenticated mail
from Large Bank's domain.  Large ISP has given Large Bank the ability to
add a limited number of bank-controlled domains to the Large ISP preferred
whitelist.

Large Bank has quite a bit of customer email delivered by a third party.
This third party delivers mail with a bounce address (MAIL FROM) of
outsource.com (so they can do the bounce processing), but a From: header
of largebank.com.  Large ISP will only whitelist largebank.com (because
that is who the ISP/Bank customers want to hear from, they don't care
about hearing from outsource.com).

In this case, Sender ID would let Large ISP whitelist largebank.com and
still allow outsource.com to deliver mail for the bank (as long as the
bank's DNS records let it do so), /and/ continue to process bounces
properly.  SPF doesn't permit From: header whitelisting (at best) and
breaks bounce handling (at worst).

WRT to Resent-From spoofing and the PRA, its important to note that it is
the PRA result which is whitelisted, so if a phisher uses Resent-From:
phisher.com w/ From: largebank.com, the message will not get preferred
treatment by the ISPs whitelist.

-Rand