On Thu, May 20, 2004 at 01:43:54PM -0400, Guillaume Filion wrote:
|
| Just to be sure I get this straight, is this a change from the way of doing
| things proposed by the MARID chairs on April 29th?
| | it is best
| | that this working group first concentrate on creating a DNS RR
| | addressing the 2821 identities and then proceed to consideration of
| | 2822 identities.
|
| I'm personally convinced that doing 2822 authentification is necessary, but
| I'm wondering if the MARID group will wait until a RFC for 2822 auth is
| finished before releasing a RFC for 2821 auth.
We are transcending the divide between 2821 and 2822 by introducing a
new parameter to the SMTP MAIL command. This is part of a new
paradigm that I have been calling The New SPF. I will post more
details soon: please wait to see the whole picture. But it is safe to
introduce a new concept now.
Today, MAIL supports the "SIZE" parameter:
http://www.faqs.org/rfcs/rfc1870.html
It looks like:
MAIL FROM:<mengwong(_at_)dumbo(_dot_)pobox(_dot_)com> SIZE=1000
The New SPF adds a "Responsible From" parameter:
As a sneak preview, suppose your email had:
From: <mengwong(_at_)pobox(_dot_)com>
Sender: <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
When that message is sent over SMTP, in The New SPF, mail would show up as:
MAIL FROM:<mengwong(_at_)pobox(_dot_)com> SIZE=1000
RFROM=<mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
So, what is RFROM? RFROM's heritage comes from Caller-ID. Caller-ID
selects a Purported Responsible Domain (PRD) from the 2822 headers,
and performs designated sender checks against that domain. The actual
semantics of the check are very similar to SPF --- it's a designated
sender scheme. Now, the nice thing about checking 2822 headers is
that you help fight phishing, at least a little bit. But the problem
is you can only reject after DATA, and that is yucky.
So, the clever idea is this: we observe that the sender should always
know ahead of time what the PRD in the headers is. If they grab that
PRD and stick it into the RFROM field, that lets receivers can do the
SPF test against the RFROM instead of against the headers. This is a
big win.
Unfortunately, today, if you give RFROM to an SMTP server, that input
produces
555 Unsupported option: RFROM=<mengwong(_at_)pobox(_dot_)com>
So ESMTP servers that grok RFROM would have to advertise RFROM
support in the EHLO response.
This is something that we couldn't have contemplated six months ago,
but together, today, SPF and Caller-ID have enough traction that the
MTA community might actually go along with a new extensioin.
As we evaluate this new proposal, it's important to distinguish
between two eras: before the flag day, and after the flag day.
Before the flag day, MTAs can always pull the PRD from the 2822
headers and run SPF checks against that domain. Unfortunately, if the
RFROM is not present, MTAs can't confidently do SPF checks against the
2821 MAIL FROM, because of the worry with forwarders.
(trusted-forwarder.org is a good enough workaround, thanks to Wayne,
that it restores a lot of that missing confidence, but large
organizations can't always rely on trusted-forwarder.org as a matter
of official organizational policy.)
After the flag day, even if RFROM is missing, MTAs can go back to
doing SPF checks on MAIL FROM. If the RFROM is present then use that.
Astute readers will notice that:
- before the flag day, The New SPF removes the benefit of joe-job
protection, because we can't reject based on MAIL FROM sans RFROM,
which will be the common case.
- after the flag day, The New SPF removes the benefit of joe-job
protection, because we don't evaluate the MAIL FROM when RFROM is
present.
- after the flag day, The New SPF only gives you joe-job protection
if RFROM is not present.
However, The New SPF points out that the joe-job protection promised
by The Old SPF was largely illusory: to really get that protection,
the whole world had to become SPF compliant. Seth Goodman has been
saying this for a long time, and The New SPF agrees with him that if
you really want joe-job protection you need to get off your ass and do
SES. With SES, you don't care whether the rest of the world
cooperates or not.
If joe-jobs are a side effect of spam, and if these techniques do
successfully reduce the amount of spam, the lazy ISP can get away with
not doing SES, now and in the future. I hope that's true, because I'm
lazy.
cheers
meng