On Wednesday, August 18, 2004 2:34 PM, Nate Leon wrote:
I realize concern around this topic has been raised multiple
times (Dave Crocker, Doug Otis, Chris Haynes, etc...) but I
still can't help feel we are under-estimating the seriousness
of this issue. If I missed the posting where everybody
agreed on the solution (entirely possible) please point me to it. :)
I expect it will take years before all MUAs are updated (and widely
deployed) to display the PRA, which I do not think is an
acceptable timeframe to put a serious dent into phishing attacks.
For completeness, here is another example of the concern:
MAIL FROM:<> // don't care
RCPT TO:<valid-recipient(_at_)example(_dot_)com>
DATA
Subject: update your account info
Resent-From: JoePhisher(_at_)phishingScam(_dot_)com // valid domain
authenticated by MARID
...
From: account-services(_at_)yourbank(_dot_)com // Spoofed domain,
displayed by the MUA
To: valid-recipient(_at_)example(_dot_)com // bummer for you
...
Are we really going to RFC with this issue left open?
If nothing else, I at least want to add my vote to more
thought being put into this topic.
To address the forged Sender/Resent problem I suggest we could add the
following logic:
If PRA != 2822.From and SPFCheck(PRA) != "Pass" then receiver MAY reject
a message after DATA.
In other words, if we validate an identity different from 2822.From,
then there's a higher bar for a message to be accepted. The higher bar
is that check of the SPF record must return PASS, else the receiver MAY
reject the message.
Another approach that's been discussed is to fall back to doing a check
on the MAIL FROM address when there is no SPF record for the PRA.
Both alternatives share some things in common:
- Neither approach permits rejecting a message before DATA, unless
SUBMITTER is present. If SUBMITTER is present then both approaches
permit rejection before DATA.
- Both place a higher burden on the "specialty" senders, namely the
forwarders and list servers. This is a good thing. (Not that it's a
good thing to place a burden, but that the burden is on the specialty
senders rather than all MTAs in general.)
- Neither approach can be done on day 1. At minimum we need to allow
time for the specialty senders to publish SPF records.
I think the approach I'm suggesting has several advantages:
- It's semantically cleaner. We're basing the check on 2822 identities,
with a higher burden in special cases where PRA is different from
2822.From. This isn't just a theoretical distinction. As we have
repeatedly discussed on this list there are substantial semantic
differences between MAIL FROM and the 2822 identities.
- More importantly, this allow us to give much clearer directions to
senders in terms of what to publish. You publish the IP addresses of
servers authorized to send mail on behalf of your domain. We're not
trying to mix this up with the IP addresses of servers that receive
bounce messages on behalf of your domain.
- This approach involves fewer DNS lookups because you're only
performing the spoof check on one identity in all cases.
Thus, if a spammer wants to forge a Sender or Resent- header, they have
to use their own domain name. That'll get block-listed fairly quickly. I
belive that plugs the hole that we're addressing.
At this late point in the process I'm not sure whether this idea needs
to go into the spec itself. It could be written up in a BCP.