Re: SPF advocacy

--Meng Weng Wong <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com> wrote:

> On Sun, Jan 25, 2004 at 06:17:08PM +0000, Wechsler wrote:
> |
> | Evidently couldn't think of a real reason then, and doesn't actually
> | appear to be answering any of the questions or issues that were put to
> | him. Is postfix not open-source? If so, he doesn't *need* become an SPF
> | developer. Sounds like pure "not invented here" syndrome to me.
> |
>
> He came out pretty strongly against it, actually.
>
>   http://marc.theaimsgroup.com/?l=postfix-users&m=107413125617617&w=2


> List:       postfix-users
> Subject:    Anti-spammers destroy the infrastructure
> From:       wietse () porcupine ! org (Wietse Venema)
> Date:       2004-01-15 1:46:53
>
> Rabinowitz, Ari (Exchange):
> > And why should a server which is not 'speaking on behalf of the domain'
> > be allowed to say that error notifications should go to that domain?
> >
> > Should a spammer be allowed to use an envelope From of 
> > woods(_at_)weird(_dot_)com
> > so that you have to deal with their bounces?  Who else but the owner
> > of a domain should be able to state that error notifications should be
> > sent to that domain?
> If we carry this argument to its logical conclusion, then IP
> datagrams should specify as origin the nearest gateway instead of
> the sending end system.
That should read "If we carry this argument to its ABSURD conclusion" 
Here's another absurd metaphor that has nothing to do with the original 
problem: "If we carry this argument to its logical conclusion, every postal 
carrier who handles your mail should stick it inside another envelope and 
put his own return address on it instead of the original return address".
I mean what could the "origin of a datagram" possibly have to do with the 
"envelope sender of an SMTP message".  They are different protocols.  They 
are not even at the same layer.
> After all, no-one but the originating system should be allowed to
> claim that a datagram was sent by that system. And by imposing this
> requirement we eliminate IP address spoofing. In reality all that
> happens is that bad origin information is LAUNDERED and replaced
> by "better" information.
Hmm, in other words, if you can't attack the sensibility of the *original* 
argument, then turn it into a meaningless metaphor that has very little to 
do with the original argument, then attack the hell out of that.  This 
brought to you by the fine minds that drop their keys in the parking lot, 
and then come back into the lobby to look for them, because the light is 
better.

> Replacing the apparent origin of email by the forwarder will have
> no permanent beneficial effect on the amount of junk mail on the
> network. All you achieve is LAUNDERING a bad sender address and
> replacing it by something that is worse than useless.
Sure, but I don't think anyone is really suggesting that.
1. rewriting the sender is not the same as laundering/obscuring it
2. why not check the validity of the original envelope sender address 
*before* rewriting it?  wouldn't that be the perfect time?
3. If you insist that mail from / envelope sender address has no inherent 
value, why do you care if it gets rewritten?

> By laundering the sender address you didn't even raise the bar by
> epsilon for the abusers.  Meanwhile everyone is forever suffering
> from an infrastructure that was screwed up by half-baked solutions.
>
>         Wietse

OK... this argument is going to have at least two moving parts so try to 
stay with me here.
1. SMTP is incomplete, since it contains no sender verification.  Anyone 
who does not believe this, just count the number of emails you received 
from forged senders yesterday, or last week.  Knowing what we know now, 
SMTP as a proposed standard would get laughed right off the map if it were 
proposed today.  Forged email causes bounces and misdirected complaints to 
innocent third parties.  There is no way within the confines of SMTP for a 
domain owner to stop fake mail claiming to be from his domain.
2. The replacement for SMTP is not yet ready.  Believe it or not, the new 
version of SMTP protocol is not quite ready for prime time.  You may be 
content to wait for it, others of us are not.  Those of us who rely on SMTP 
for our daily work, but are fed up with the activities of forgers, have 
been searching for a way to identify forged messages.
3. A number of proposals exist to allow those who ELECT to publish their 
outgoing authorization to do so, to the benefit of those who ELECT to use 
the info to block known-forged mail.  It's not theoretical anymore, SPF is 
currently proved to block forged mail and therefore it "raises the bar for 
the abusers".
Based on these three points, is it really accurate to describe SPF as a 
"half-baked" solution that "screws up" email infrastructure?  If SPF 
qualifies as "half-baked", wouldn't SMTP qualify for that label as well?

Bottom line for me: I take Wietse's criticism as empty and hollow.  I will 
take his criticism more seriously when he has drafted his own proposal for 
stopping email forgeries, written it up, actively sold it to several 
stakeholders, modified it, evangelized it, and seen it through to active 
use.
Scratch that... I will take his criticism more seriously when/if it is 
*constructive* at all.

--
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;±¤Ö¤Íµø?¡