On Fri, 3 Sep 2004 09:14:43 -0700 (PDT), Rand Wacker
<rand(_at_)sendmail(_dot_)com> wrote:
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).
Okay, now suppose SPF-classic were adopted as a standard. Large ISP
would now whitelist MAIL-FROM addresses in *.largebank.com instead of
whitelisting those addresses in the PRA.
If the bank wants outsource.com to send the mail, it sets up either a
CNAME, or else:
$ORIGIN largebank.com.
outsource MX 10 largebank-bounces.outsource.com.
outsource TXT "v=spf1 include:spf.outsource.com -all"
And outsource.com now sends mail using bounce address
"outsource.largebank.com." (As a bonus, if for some reason
outsource.com had to be fired quickly, largebank could redirect
bounces quickly to their replacement.)
Now, of course, just as phisher could always use a PRA of
postmaster(_at_)phisher(_dot_)com with a From: address of largebank.com, the
phisher can also use a MAIL-FROM address of
postmaster(_at_)phisher(_dot_)com(_dot_)
But again, just as in your example, the mail would not be whitelisted,
which is the desired result.
The mechanisms are slighly different, but the achieved security policy
is the same. I'm sure that largebank.com and outsource.com would be
happy to use either approach depending on what got standardized.
David