spf-discuss
[Top] [All Lists]

Re: New ideas for RFC2822 headers checking with SPF

2004-10-27 14:32:56
Seth Goodman wrote:

Perhaps we are misunderstanding each other (how incredibly 
unusual for this list!).

LOL.  We're more like getting to the point:  If "you" (that's
the "you" including Jim and Meng) want to do interesting stuff
with 2822-headers, then "you" have to update RfC 2476.  And I
would probably support "you" at this step.  But the the next
important step is to update all MSAs of the world.  And hell
freezes before I pretend that this is already the case, and
that there are no problems with abusing v=spf1 for PRA _now_

It is simply _not_ true.  They (the "you" minus you) are lying,
they are deleting valid mails, they are raping v=spf1 policies.

MSA's SHOULD enforce submission rights.

When you say "enforce submission rights" you mean 6.1 and 8.1
in 2476.  The definition of "enforce submissio rights" in 2476
is _only_ 6.1 (= reject MAIL FROM if it's not authenticated):

| 6.1.  Enforce Submission Rights

8.1 is "MAY add Sender", and instead of adding a Sender where
necessary (From != MAIL FROM) you could maybe also demand to
reject mail with PRA != MAIL FROM.  But it's another chapter:

| 8.  Message Modifications
[...]
| 8.1.  Add 'Sender'

It's not part of "enforce submission rights" as defined in RfC
2476.  And both parts are at the moment only optional.  So if
you want to sail with Sender-ID first fix this RfC and all MSAs
in the world.  It's really not my fault... :-(

Let's go back to basics.  An MUA authenticates itself to an
MSA and then submits a message to the MSA.  The MSA has an
authenticated identity for the MUA and a message submitted by
the MUA.

It could be more than one identity, if you define "identity" =
mailbox address (e.g. my vanity host xyzzy has infinitely many
valid addresses), but that's probably only a minor point.
  
the bottom line is that the MSA is in the best position to
prevent forgery since the MUA has to authenticate to it.

OTOH spammers are free to create "MSAs" in any way they like.

using an identity that the MUA does not have the right to
use.

My MUA has the right to use one of my From addresses with one
of my MAIL FROM addresses (by my appointment ;-)

There is nothing technically wrong with this concept, except
that no ISP is going to go to this trouble.

That's the problem of almost all FUSSPs.

With a Return-Path default Sender-ID could work.
I agree that this approach is not workable.

No idea with whom you agree.  I proposed this solution of the
most obvious Sender-ID bug several times here and in mxcomp.

You can't assume a header that is not present.

Of course you can, if you get a MAIL FROM:<m-e(_at_)hamburg(_dot_)test>
with From: nobody(_at_)xyzzy, and without Sender: m-e(_at_)hamburg(_dot_)test,
then obviously I sent it via hamburg.test (and you can bounce
or auto-respond to m-e(_at_)hamburg(_dot_)test), but I'd prefer "normal"
replies to nobody(_at_)xyzzy(_dot_)

What else could it mean ?  Especially if you'd know that the
hamburg.test MSA enforces submission rights (2476 definition).

either Gmane or Listbox deleted my Sender
Looks like it didn't quite make it through

Tough.  I'll test it in another Gmane newsgroup (mailing list).

 [MX tests 2821 and notes "eh", MUA tests "eh"]
The problem is we want to reject forgeries, not silently
discard them.

As soon as the MAIL FROM is okay, plain old bounces do fine.
Even C/R systems start to work as soon as MAIL FROM is okay.

The anti-phishing "equivalences" are only a marketing gimmick
and not essential for SMTP (unlike SPF, that's essential).

If the MUA cannot handle the "eh", then nobody really needs it.
See Meng's story about a MUA showing the PRA header in yellow.

                         Bye, Frank



<Prev in Thread] Current Thread [Next in Thread>