ietf-mxcomp
[Top] [All Lists]

Re: PRA algorithm and use of non-standard header fields

2004-07-26 12:47:23

On Mon, 2004-07-26 at 12:08, Greg Connor wrote:
On Tue, 2004-07-20 at 09:36, Margaret Olson wrote:
Evaluating the PRA based on records published for SPF-classic is not 
valid. SPF-classic publication is itself a non-representative 
subsection of the net, and on top of that SPF classic records are not 
Sender ID records - the semantics are different - so "pass" and "fail" 
does not mean anything.

Actually, this is exactly what SenderID proposal is based on -- the
assumption is that published SPF records will be effective when used
against the PRA.  The proposal depends on this, so it's good that it's
actually getting tested.

I see PRA as a first step of possibly several in our quest to determine
what identity to check.  Eventually, if Submitter becomes widely used,
we will reach a point where SUBMITTER is either there, or we fall back
to MAIL FROM, and then we will be close to where SPF Classic would be if
we had continued down the SRS path.

A typical technique used by spammers is to forge the RFC 2821 MAIL FROM
as a "back door" means to submit messages into a domain that would have
prohibited direct assess.  With focus moved from a useful check of the
RFC 2821 MAIL FROM to some RFC 2822 sender identity, how does this
ensure this "back door" remains closed?  The sender identity could point
to any random open SPF record or to one specifically designed to gain
full approval from a PRA evaluation.  PRA rather than Classic SPF
ensures the "back door" may never be closed.  Classic SPF can be made
much better by including BATV.

I would prefer to see the BATV be used in conjunction with the SPF
record.  If the SPF record were closed, then this could over-ride the
BATV signature.  The BATV signature would not require a full listing of
all domains, but could serve as a useful means to list just the domain's
outbound SMTP clients irrespective of other domains that carry their
mail.  This could become the preferred method, if a DomainKey technique
allows verification of the RFC 2821 MAIL FROM.

A 'replay' of this bounce address could be easily caught and keeps the
"back door" closed.  MAIL FROM addresses that do not use the BATV
signature and have a SPF record could then apply the matching address
requirement as a means of thwarting spoofed MAIL FROM addresses.

Looking at address records to sort mail based upon RFC 2822 identities
into different folders supports filtering and little else.  Filtering in
general will only lower the integrity of the mail system.  This seems to
be a bad direction to take, if there is a means to actually stop abuse
before it enters the mail stream.  A CSV accreditation by name used in
conjunction with strong checks on the RFC 2821 MAIL FROM have the
ability to close the door on abuse.  I would not expect SPF records to
be comprehensive enough in all cases, where a signature scheme could
take over in those cases as with BATV.  A signature method would also
provide a solution to many of the problems seen just using addresses
alone.

-Doug