spf-discuss
[Top] [All Lists]

RE: Re: change of version string

2004-08-10 00:21:47
Mark -

Your concerns seem to hinge on the idea that implementors
will not check the 2822 headers in the absence of
SUBMITTER.  Yet, the drafts clearly state that you have to
check the 2822 headers for PRA, in either case.  If
SUBMITTER is present, and passes, then you sill have to
extract PRA and check that it is the same.  If SUBMITTER is
absent, then you have to extract PRA and check that.

My concern has to do with two issues:

* Spammers are not going to comply with anything we write,
but rather endeavour to exploit any available gaps or
openings for their benefit.

* Given the potential issues surrounding the implementation
of Submitter in the wild, by only asking the receiving MTA
to extract the 2822 headers for PRA and run checks, are we
leaving any gaps given the existence of a legacy
infrastructure which is open?

An MTA receives a message without an SMTP sender from or
re-sent sender from extension.

At 2821 time, we are looking at:

* Is the SMTP mail from malformed, meaning there is no
domain;

* Is the SMTP mail from spoofed;

* Is the EHELO spoofed; and

* running a PTR check to verify identity.

Each of these checks looks at the sender's identity from a
slightly different perspective.

We also know, depending on which check is carried out, this
has different repercussions for mail forwarding, 3rd party
email service providers and the like.

The objective of sender authentication is to thwart
spoofing and the use of other technical means to hide
identity.

In the absence of a Submitter extension, by running these
various checks at 2821 time, this adds to the data set of
information the receiving MTA has to make an informed
decision.

(I understand there is an argument that by doing the check
at 2821 time this may save bandwidth and cpu costs. I write
may, because it seems there is not enough data to know
whether there is a saving or not.)

Even with the Submitter extension, some receiving MTA's may
still want to run these various checks at 2821 time,
particularly the large ISPs.

Also, I suggest it is a mistake to speak of accreditation
and reputation services filling gaps in sender
authentication.

I say this because the objective of a reputation service is
to tell the receiving MTA the sender's reputation.
Therefore from a design perspective I would suggest we look
at reputation services as augmenting the value of sender
authentication is the better approach.

By focusing solely on extracting the PRA using the 2822
headers, when the Submitter extension is absent, my concern
is we are leaving 'potential openings' for spammers to
exploit.

Even though many fine minds have worked on this proposal,
it remains an hypothesis, untested in the wild. 

Having said this, I see essentially two options:

* Augment Marid core by suggesting the receiving MTA may at
2821 time carry out one or more of the checks I have noted;
or

* If the desire is to keep the PRA approach pure, which I
can fully appreciate, acknowledge from a design perspective
there is merit in redundancy if the receiving MTA wishes to
carry out additional checks, especially with the time
needed to close an open legacy infrastructure through
implementing Submitter.

How do we recognize this:

* By having the MARID WG review, discuss and put forward
CSV (which it has agreed to do) and unified SPF (which is
presently not on the table).

Now, I appreciate having agreed to the merger of SPF with
Caller-ID, you and Meng have to focus on designing and
implementing the merged protocol.

However, this should not prevent others within the SPF
community from coming forward and asking the MARID WG to
consider unified SPF (which may not be possible unless the
rules are changed); or 

The SPF community continues to work on unified SPF
hopefully under your and Meng's tacit leadership using the
Marid protocol and the unified documents as the basis for
moving forward.

Also let me be purely selfish for one moment. 

Since one hat I wear in life is that of a prudent sender, I
want to know what are the rules that I need to meet so that
a receiving MTA can run any check it wants based on these
rules and I pass.

Also, since I am lazy, I don't want to have publish any
more policy records than I absolutely have to, which is why
I like the suggestion Meng put yesterday evening to the
Marid mailing list of not changing the version string:-)

Enough. It is late at my end. Cheers, John.

John Glube 
Toronto, Canada

The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.734 / Virus Database: 488 - Release Date: 04/08/2004