RE: Using headers instead of SRS

Hi Julian, thanks for the reply.

Your point that I'm rehashing territory that's already been gone over is 
true.  There's a lot of activity on the list lately and I haven't 
completely caught up with it all.  So, I apologize for rehashing a bit and 
I realize that can be frustrating.

--Julian Mehnle <lists(_at_)mehnle(_dot_)net> wrote:
> Exactly.  Why do so many people think that SPF breaks forwarding, while
> what so many self-proclaimed "forwarders" do is in fact "relaying"?  I
> don't think SPF's handling of forwarding is broken.  I think calling
> "relaying" "forwarding" is broken.
>
> SPF really doesn't break forwarding, it only breaks relaying from
> *untrusted* relays.

Hmm, I can see the distinction between forwarding and relaying and I agree. 
I think saying "Forwarding is not broken, but relaying (mostly) is" is 
correct, but it doesn't narrow the scope of the problem.  SPF breaks "what 
pobox.com and others do" regardless of the name.
I agree that there are a lot of options for "relay services".  The problem 
is serious, in my opinion, because the relay point is neither the sender 
nor the receiver.  They haven't "opted in" to SPF but they are at the mercy 
of others who have, a bit.
That said, I don't think it's enough of a barrier to keep SPF from being 
used to good effect.  I can see both sides of the problem, which is why I 
probably come across as wishy-washy or even contradictory.  Sorry about 
that.  I mean to say, we should march ahead, but not dismiss the barriers 
lightly.

> Although I agree that it will be far from trivial, I really think
> forwarders should fix their software instead of demanding that they be
> tolerated continuing to use it forever at the expense of address forgery
> victims.

Agreed.


> Greg Connor [gconnor(_at_)nekodojo(_dot_)org] wrote:
> > SPF also has its flaws.  Forwarding is one.  Single-minded devotion to
> > the envelope sender as the end-all and be-all of verification is
> > another.  I don't think it's going to take long for spammers to realize
> > that all they need to do is spit out something different in the
> > envelope sender that doesn't appear anywhere in any header, and it
> > passes right through SPF, even if the Sender: and From: are both
> > bgates(_at_)microsoft(_dot_)com(_dot_)
> > [...]
> > Also, any approach that pays no attention to headers at all will be of
> > limited benefit to users.  I see those as pretty big targets for SPFv2
> > to try and fix.
> SPF is not about matching the envelope sender against message headers.
> (Or am I misunderstanding you again?)  I will quote Ralf Doeblitz here:
>
> Ralf Doeblitz <list+spf-discuss(_at_)doeblitz(_dot_)net> wrote:
> > [...] SPF will force spammers to use one of their own
> > domains fpr the envelope sender. No matter what the user would see in
> > the message, we will have a valid domain that belongs to the spammer
> > (or at least its owners allows sending spam), so we can use this to
> > block spam in the SMTP dialog. Blacklisting domains will be possible
> > again.
> >
> > So it doesn't matter how much the content of the message is verifiable -
> > the fact that we can reliably use the envelope information to filter
> > spam against blacklists will be enough, IMHO.
> I mostly agree with that.  Still, like Greg Connor seems to imply, I
> think that forgery of the "Sender:" field (or "From:", if "Sender:" is
> missing) should be addressed if at all possible, as these fields are
> usually the only "origin" address fields displayed by MUAs --
> "Return-Path:" isn't.  Maybe this is what PGP/GPG or S/MIME is suited
> best for, I'm not sure.

I think we are in agreement here.

I think Ralf is half-right... Spammers will not wake up one day and say 
"Darn that SPF, now I have to use my OWN domain".  There will likely be 
some intermediate steps.  It's much easier to scan your list of forged 
from-domains and use some of the thousands (millions?) of domains not 
protected by SPF yet.  I predict it will be a long time before enough 
domains have SPF before non-spf-protected mail starts getting downgraded. 
*That* is the time I expect spammers to start abusing their own domains.
That said, it is still possible for Return-Path aka. MAIL FROM to be 
different from all the other visible headers.  If spammers learn this (and 
they will) then forging From and Sender will get worse before it gets 
better.  Focusing everything on the MAIL FROM and Return-Path is the right 
thing to do, for now.  But we have a steep climb to get users to notice 
Return-Path and understand the difference between the headers.
Longer term, I would like to see some filters a la Spamassassin that flag 
as "suspicious" if Return-Path doesn't equal Sender:.  This is not a 
proposed change in SPF, so much as a pre-emptive strike to keep spammers 
from switching the two around.  If 99% of valid mail has them the same, 
then it should be flagged.  Anything we can do to add more pain to spammers 
is worth it.


> Greg Connor [gconnor(_at_)nekodojo(_dot_)org] wrote:
> > Julian Mehnle wrote:
> > > Greg Connor [gconnor(_at_)nekodojo(_dot_)org] wrote:
> > > > Solution 2.  Modify SPF to not use Mail-From
> > > > Let's call this the "SPF V2" approach. SPF doesn't work like this
> > > > now, but in the future if SPF is modified, then it may be possible
> > > > to make Mail From go back to its original meaning (that is, who
> > > > should receive non-delivery notifications) and SPF will work its
> > > > magic on the appropriate headers.
> > >
> > > If you really think that SPFv2 should take the envelope from/sender as
> > > "where to send DSNs" only, then you should also say that we shall stop
> > > the distribution of SPFv1 ASAP, otherwise it's no use.  [...]
> >
> > Please don't put words in my mouth.  No, I'm not saying that.
> I re-added your original statement above.  You were clearly implying that
> it would be desirable "to make Mail From go back to its original meaning
> (that is, who should receive non-delivery notifications)", so yes, you
> were saying that.  The "we shall stop the distribution of SPFv1 ASAP" I
> added is only the logical consequence of what you were saying.

Sorry... I misspoke a bit there.  By "it may be possible to..." I didn't 
mean to imply "I think this is a good idea to..."  just that the idea 
should be kicked around a bit.  But it sounds like I came too late for the 
kicking it around, it was already kicked to death.
Now the best course probably is to:
1. soldier on with SPF as is
2. explain our rationale to use envelope sender to SPF's critics
3. explain what envelope sender IS to users
4. start doing a lot more forwarding and a lot less relaying

Optionally, we could also try to see if there is a correlation between 
envelope sender and "Sender:" in most normal mail, and keep an eye out for 
spam that tries to confuse the two (call this one "extra credit").  There 
will be other proposals that work off of these headers (Sender, From, 
Resent-*) so I would be *very* interested in ways to extend SPF's excellent 
protection to some headers, but I'm not going to try and push for this in 
the draft or anything.
As for the idea that SPFv2 might work on headers and not envelope sender, I 
will retract my bogus suggestion :)  Anything that works on headers and not 
envelope sender is different enough that the name SPFv2 would be very very 
misleading :)



> Greg Connor [gconnor(_at_)nekodojo(_dot_)org] wrote:
> > If SPF causes relatively little pain for spammers, and much more pain for
> > forwarders, administrators will find themselves looking at alternate
> > proposals.  If that happens, let's be ready with v2.
> No, causing pain to spammers is not a primary goal of SPF.  I don't think
> trying to turn SPF into the "Final Ultimate Solution to the Spam Problem"
> just to fight other (explicit) anti-spam proposals would be a wise thing
> to do.

Agreed.


> John Warren [John(_at_)wenet(_dot_)tustin(_dot_)ca(_dot_)us] com wrote:
> > On 25 Jan 2004 at 10:24, Julian Mehnle wrote:
> > > MUAs will usually also show "Sender:", and if they don't, they're
> > > broken.  So one option would be to require MTAs to put the envelope
> > > sender into the "Sender:" field, overwriting or renaming it if it
> > > already exists.  That way, MUAs would display the envelope sender.
> >
> > NO, NO, NO, NO, Don't even thing about this. I stated this one in error
> > but the sender is NOT to have a copy of the "MAIL FROM". The correct
> > header field, as stated in the RFCs, is the "Return-Path". It's already
> > in the RFCs so don't even think about changing it since it would NEVER
> > get through.
> >
> > Given that the "Sender" is very likely to be the same as the "MAIL
> > FROM" but it does not have to be.
> I'll need to take a closer look at the RFCs, but you're probably right in
> that "Sender:" and "Return-Path:" have separate meanings.  Still, I think
> this is a flaw in the RFCs, not only in their wording, but conceptually.
> There's a definite problem with forgery of the "Sender:" field (or
> "From:", if "Sender:" is missing), see what I wrote below my quote of
> Ralf Doeblitz above.

Agreed, to both of you.  The idea that we should take envelope sender and 
stick it in for Sender: is probably asking for trouble.  What I would 
really like is some research into large volumes of mail to see if there 
already is a natural correlation, and if it is already strong enough to 
flag differences as highly suspicious.

> PS, Greg Connor:
>
> Greg Connor [gconnor(_at_)nekodojo(_dot_)org] wrote:
> > It's entirely possible that I communicated poorly, but I don't believe I
> > have a "serious misconception".  Please do me the favor of giving me the
> > benefit of the doubt.
> > [...]
> > Again, I am answering/partially agreeing with Meng's question; please
> > don't jump on me too hard.  You and I agree more than you might think.
> > [...]
> > Also, you referred me to the archives twice in this message, which is
> > interesting since you seem to have joined the list a bit more recently
> > than I.  Please try to be respectful rather than patronizing.  The
> > archives will show some examples where I fundamentally disagree with a
> > couple different people and manage to do so respectfully.
> I sincerely apologize for my harsh tone.  I was angered a bit that the
> "SPF needs to look at the headers" discussion started once again, despite
> so many good arguments *against* it were given before.  Although you
> still haven't convinced me otherwise, you are absolutely correct that I
> should have reacted much more respectfully.  I'll work on it in the
> future.

Thank you for saying so.  No harm done.  I am partly to blame for replying 
to the thread before reading the other related threads, so my apologies for 
that.
I think you jumped to conclusions a bit about what I was saying (like 
whether spf is flawed enough to merit changes to the design now) but so did 
Weschler, so perhaps that's an indication that I was not communicating 
well.  That's what I get for writing while tired.

Thank you again for your patience.  I am sorry for the frustration caused, 
but I'm happy that we seem to be in agreement on a number of important 
things.
Be well,
gregc
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>

-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
Wiki: 
http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/HomePage
To unsubscribe, change your address, or temporarily deactivate your subscription, 
please go to http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡