On Wed, Aug 11, 2004 at 12:07:32PM -0400, Andrew Newton wrote:
|
| In rereading the Jabber logs and reading the recent threads on
| SUBMITTER, I'd like to point everyone to a simple sentence Meng wrote
| in the Jabber session:
|
http://www.xmpp.org/ietf-logs/marid(_at_)ietf(_dot_)xmpp(_dot_)org/2004-08-04.html
|
| > [11:05:42] <mengwong> if submitter is not present, we fall back to
| >mail-from. people are missing this.
|
| In defense of "people", I reread marid-submitter and marid-core this
| morning and could not find the place where this was stated. However,
| this statement is significant. I'm not saying it is a good or bad
| idea, but it profoundly changes how SUBMITTER is used, the nexus of
| SUBMITTER and PRA, and even the semantics of the RR version identifier.
|
I should explain the thinking behind that statement. It is
not my intention to open a can of worms, but since I'm
likely to get yelled at either way I might as well err on
the side of openness.
Sender ID is complicated by the fact that it has "before"
and "after" aspects.
In May, in my meeting with Microsoft when Submitter was
first proposed, we tossed around a few ideas for how it
could be used.
The vision we arrived at (and Harry, Jim, please correct me)
looks something like this:
The core identity in Sender ID is the PRA.
To make the PRA available without the bandwidth and processing
burden of DATA, Submitter is used to provide a sneak preview
of the PRA at MAIL time.
Since the goal is a preview, if Mail-From and Submitter are
identical, there is strictly speaking no need to display
Submitter.
In the early days of Sender ID, you have to check the PRA,
because you can't assume the typical sender is Submitter
aware. This is the "before" aspect.
But after Submitter has become more widely supported, a
receiver may be able to assume that Submitter was omitted
because the PRA and the Mail-From match. This is the
"after" aspect, the long-term endgame scenario. I would
like to get there sooner rather than later.
The language in 4.1 alludes to this assumption.
4.1 Setting the SUBMITTER Parameter Value
The purpose of the SUBMITTER parameter is to allow the
SMTP client to indicate to the server the purported
responsible address of the message directly in the RFC
2821 protocol.
Therefore, SMTP clients that support the Responsible
Submitter extension MUST include the SUMBITTER parameter
on all messages where the purported responsible address,
as defined in section 4 of [SENDER-ID] differs from the
MAIL FROM address. This includes messages where the MAIL
FROM address is empty or "<>". SMTP clients SHOULD
include the SUBMITTER parameter on messages where the
purported responsible address is the same as the MAIL
FROM address.
I take this to mean that an SMTP client that supports the
Responsible Submitter extension MAY omit the parameter on
messages where the Mail From is the same as the PRA. And an
SMTP receiver that supports the Responsible Submitter
extension MAY assume that the Mail From is a good predictor
of the PRA.
I think that this line of thinking is useful.
If, however, we don't want to make the assumption that a
missing Submitter means we use the Mail-From, we would
require a Submitter aware sender to always pass Submitter,
even when PRA == Mail-From. Then the language could be
changed to read:
SMTP clients that support the Responsible Submitter
extension MUST always include a SUBMITTER parameter on all
messages. This includes messages where the MAIL FROM
address is empty or "<>".
This may also be useful, but we should consider the tradeoffs.
First, this would remove a receiver's ability to assume that
Mail-From == PRA when Submitter is absent. Second, this
would also require PRA checks on all mail where Submitter is
not provided, and therefore make it impossible to detect and
reject envelope spoofs before DATA. I believe that such a
change would have serious implications for the acceptance of
the proposed standard in the marketplace. I will go into
more detail below, but first, I want to take a look at
Submitter.
I like the idea of Submitter. Because it is a new
construct, we can load it up with powerful semantics right
out of the gate.
I believe it was Bob Atkinson who pointed out that if a
sender was aware of Submitter, that sender should also be
aware of Sender ID. This meant that anytime a receiver sees
a Submitter, the SPF check on Submitter should return a PASS
result. Obviously if it returns a FAIL result you reject.
But if the spf/Submitter test returns an UNKNOWN, you can
also reject!
Why? Because no legitimate, Submitter-aware MTA should ever
send a Submitter field that doesn't result in a PASS. If
the purported responsible address doesn't resolve in a PASS,
why bother
If we can say that for Submitter, UNKNOWN isn't good enough,
then we have a stronger level of assurance than the
spf/Mail-From test, and we make it harder for spammers to
spoof domains in SUBMITTER. This statement of applicability
may not be in the specification; if it is not too late,
perhaps it could be added. I would be happy if that
happened. If it did not happen, I expect spammers would
forge non-SPF-publishing domains in the SUBMITTER field.
We're getting close to last call. Now that code has been
written, conformant products are shipping, specifications
have been drafted, and the design has been documented,
perhaps it's time to talk about requirements.
The anti-false-positive community wants to easily whitelist
known good senders without hurting deliverability. This
includes the ESP industry and receiving ISPs. Because this
is the most modest requirement, spf/Mail-From,
spf/Submitter, spf/PRA, CSV, and DK are all good enough for
this community. They just want us to pick one and get on
with it. Apparently S/MIME is not good enough because
people using mail clients from 1995 are an important
demographic who must not be confused by new technology.
The anti-phishing community wants to make it possible for
MUAs to validate what the end-users see, to easily detect
obvious forgeries, to easily detect obvious good mail, and
allow room for accreditation. If we could construct an
email analogue of the https padlock icon, that would be a
step in the right direction. Any one of DK, SMG, PGP, or
Sender ID can provide that padlock, at varying levels of
assurance. Sender ID tries to help by offering the
designated sender approach. I expect the MASS WG to
complement our work with good cryptographic solutions.
But technical solutions can never perfectly solve the
phishing problem. The genie is out of the bottle: we can't
keep arbitrary graphical content from being displayed to
end-users. What we can do is flip toward an AGUPI paradigm.
Once enough reputable senders authenticate themselves, we
can relegate all unauthenticated or unreputable senders to a
second class folder, and create new user expectations for
the differences between first class and second class folder.
Getting out of that folder should be easy for good guys and
hard for bad guys. We can do this using accreditation and
reputation.
The SPF Classic community wants some level of protection
from blowback; the ability to reject before DATA; and a
strong proposal which can be quickly rolled out at the MTA
level independent of the MUA. While we appreciate that
BATV/SES are the final word in blowback prevention, because
many spams are overwhelmingly directed at large ISPs, if we
can get those large ISPs to reject at SMTP time instead of
generating bounces or silently swallowing suspected spam,
then we already have a significant benefit.
Sender ID is a compromise between SPF Classic and Caller ID.
The opensource community has been very vocal in its defense
of its requirements. So has the anti-phishing community.
My goal in exploring the affordances of Submitter is to
build a bridge between the two sets of requirements, which
are, to some degree, in conflict. I would like to offer the
opensource and SPF Classic communities a strong argument
that their objectives will be met by Sender ID. I fear that
if we do not, Sender ID will lose their support.
With this in mind, we can come back to the question:
In the absence of Submitter, should a receiver assume that
the Mail From is a good predictor of the PRA?
I would like to live in a world where the answer is yes.
Because of the "before/after" issue we may have to wait a
while before we can safely make that assumption. This is
not the place to discuss how long, but I would like it to be
sooner rather than later. (I happen to feel that the spam
problem is pretty urgent. The baby is drowning in the
bathwater.)
I believe that if we choose a world where the answer is no,
then the SPF Classic community will continue to pursue
Mail-From solutions independent of Sender ID. SPF code has
been written and has been packaged into the majority of
opensource MTAs. If I cannot offer a compelling argument
that their requirements are respected in Sender ID, I may
not be able to convince them to move toward SUBMITTER and
PRA. Of course, I may not need to do anything; when the
RFCs are out, there is a certain expectation that they will
be followed.
I understand that many participants in this working group
have, during the course of the standards process,
accumulated a fair amount of frustration. I am not
bringing up these issues because to be contrarian. I am not
bringing up these issues to further some secret agenda. I
believe that Sender ID is very close to being good enough
for nearly everyone. I'm just not sure that it's there yet,
and I want to help it go the rest of the way.
If we leave these issues unaddressed, I fear that an
important constituency will simply respond by declining to
adopt our standard.
I fear that if we are not explicit about exactly what the
value proposition is, people who buy into the system
expecting a silver bullet will accuse us of false
advertising.
I fear that if we do not think through the full range of
WWSD scenarios and answer each one convincingly, the
solution will not last.
I am bringing up these issues because I hope that they can
be avoided.
I recognize that perhaps this input is too late, not
appropriate to this forum, or places too high a value on
cooperation between different communities. If you feel that
this message has not been constructive, I apologize in
advance; please understand that I am doing what I think is
right. I will not raise these issues again; all you have to
do is not reply, and it will go away.
On a separate note, I have heard that EzMLM and YahooGroups
lists do not pass the PRA test. The new core draft may
benefit from an applicability statement that waives the PRA
test for recognized mailing lists.