Subject: [Asrg] Re: "worm spam" and SPF

From: [email-masked]
Date: Sun, 28 Nov 2004 18:53:49 +0000 (GMT)

>[email-masked] wrote:

>> I've been arguing PRECISELY this point for several years,
> and Wong (et al) still forge blindly ahead with SPF

> That would be at most two years if you'd count RMX as the
concept, and SPF as its realization.

I could go back and find my archived posts on the issue, but ultimately it 
matters little.  In Internet terms, anyhow, it's been quite a while.

>> SPF and other such schemes SIMPLY DO NOT WORK because they
> DO NOT SOLVE THE PROBLEM.  They only force worms to use
> "real" return addresses and "approved" servers, but that
> accomplishes very, very little.

> That's a contradiction.  First you say SPF doesn't solve "THE
PROBLEM", and then you say that SPF exactly does what it's
supposed to do.  Apparently your definition of "THE PROBLEM"
has nothing to do with SPF.  

Or, alternatively, the problem SPF "solves" is NOT the spam problem, nor is it 
the worm problem.  It doesn't even mean that E-mail comes legitimately from a 
trusted person with an authenticated return address.  It (arguably) ensures that 
the machine that sent the mail can be identified as such;  but as long as 
authenticated machines can be infected and recruited to send "authenticated" 
worm/spam messages, SPF and similar schemes do very little to prevent such 
things... you're still running along after a constantly moving target, trying to 
lock the barn door (and there are MILLIONS of them, and new ones being created 
all the time) after the horse has escaped.  And then you have the issue, too, of 
undoing the DAMAGE that SPF has done, not only to "recommission" the victim's 
E-mail integrity, but also fixing the many legitimate systems that SPF breaks.

> And your "solution" is to get rid of MIME multipart resp. text/html, and mails 
bigger than 12 KB.

No, not at all.  

The point of the permissions list is that small(ish) plain text messages 
(without attachments) are QUITE SUFFICIENT for UNEXPECTED initial contact 
messages from UNFAMILIAR senders.

Once the contact has been made, and the recipient trusts the sender, *if* there 
is going to be an extended correspondence, then the recipient can enable ONLY 
JUST the type of bulkier/riskier content that they agree that the sender wants 
and needs to send, and which the recipient trusts the sender not to abuse.  It's 
really a matter of not just WHO the sender is, to THIS recipient, but what mail 
from them is "expected" to look like.  Mail coming "from" that sender but which 
doesn't look as it normally does (e.g. suddenly it's got Java, or .CPL or .SCR 
attachments, or decryption, or obscured URLs, or ActiveX or whatever) is BY 
DEFINITION suspect BECAUSE it doesn't look like what the recipient expects to 
receive from that sender.  It doesn't fit the pattern.  (Other mail from the 
same sender probably DOES look "right" and thus will continue to sail right 
through, as it should).

> Your recipe won't help me against hundreds of bounces... 

"bounces" containing viruses or worms (for example) WOULD be identified and 
blocked if they didn't fit the default criteria from that (probably unknown) 
sender.

> ..and other crap like challenges caused by forged addresses unfortunately.

It would block what it blocks, and that's set (and changed when necessary) by 
the recipient.  It would virtually eliminate E-mail as a vector for the 
transmission of worms and viruses.  It would make major inroads against phishing 
attacks in E-mail by making it harder to spoof URLs.  With widespread adoption, 
it would reduce the sheer byte volume of unsolicited spam by forcing spammers to 
mail it as plain text of limited size, as HTML-burdened spam is generally 3-5x 
bigger than a plain text equivalent.  It doesn't break vanity domains, doesn't 
break "atypical" send paths (e.g. the cruise ship Internet cafe or the hotel 
business center or the Internet cafe) and doesn't break mailing lists or other 
forwarding.

Better yet, it is implementable on an individual system basis, provides 
IMMEDIATE benefits to those using it, requires no worldwide consensus or 
sweeping changes.  Win-win.

Gordon Peterson                  http://personal.terabites.com/
1977-2002  Twenty-fifth anniversary year of Local Area Networking!
Support free and fair US elections!  http://stickers.defend-democracy.org
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 28 Nov 2004 23:59:25 +0100

[email-masked] wrote:

> Or, alternatively, the problem SPF "solves" is NOT the spam
> problem, nor is it the worm problem.

Yes, that's true, SPF attacks the problem of forged MAIL FROM
addresses and forged HELO domains.  It's indirectly related to
spam and worms at the moment, like open relays were related to
the spam problem some years ago.

> as long as authenticated machines can be infected and
> recruited to send "authenticated" worm/spam messages, SPF
> and similar schemes do very little to prevent such things

It allows to find the relevant abuse desk fast, not too shabby.
All these weird challenges / out-of-office / vacation mails
won't hit innocent bystanders, if many receivers support SPF.

"Many" is good enough, spammers and worm authors won't waste
their time with something not working at say AOL or behind SA.

> undoing the DAMAGE that SPF has done

There's no "damage", if you don't like it just don't publish a
sender policy.

>> your "solution" is to get rid of MIME multipart resp.
>> text/html, and mails bigger than 12 KB.

> No, not at all.

You said so in <[email-masked]> :

| default is to (by default) not accept messages that:  
| (1) are are bigger than some limited size (say 10K-25K),
| (2) contain attachments, and/or (3) contain HTML

12,000 bytes is a limit in my own "popstop" script, but it's
within your size limits.

> Once the contact has been made, and the recipient trusts the
> sender, *if* there is going to be an extended correspondence,
> then the recipient can enable ONLY JUST the type of
> bulkier/riskier content that they agree

Okay, in fact I have "special" addresses (not nobody@xyzzy)
where I don't limit the size, and don't look for any TV or UE
starting a base64 attachment (poor man's AV, credits to John)

But the UBE still sits there in my POP3 mailbox waiting for an
over quota or my script.  And many of the bounces and all other
crap caused by forged addresses were relatively small.

> With widespread adoption

That's the problem of all FUSSPs.  As you see I have no problem
to mix different ideas, as far as that's possible for a normal
POP3 user without the root password for the MX of his provider.

                           Bye, Frank

---

From: der Mouse <[email-masked]>
Date: Sun, 28 Nov 2004 21:24:14 -0500 (EST)

> There's no "damage", if you don't like it just don't publish a sender
> policy.

There is damage, even for a total non-adopter, like me.

First, it's drained off a nontrivial amount of effort that could have
gone towards developing something more effective.

Second, because it breaks bounces, and because some people feel that
the appropriate reaction to that is not "don't do that, then" but
rather to break bounces even more contrivedly, I've already had one
message produce a misfire from my automated filtering because its
envelope-from was mangled by SRS (itself a direct consequence of SPF).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 29 Nov 2004 18:26:22 +0100

der Mouse wrote:

 [SPF]
> First, it's drained off a nontrivial amount of effort that
> could have gone towards developing something more effective.

For Gordon's idea, some kind of elaborated white listing based
on the sender if I got it right, you'll need a way to identify
the sender.  SPF could help there (of course it's not the only
or even best solution, but it's near to a "minimal" solution).

And Gordon's idea sounds like Meng's "AGUPI" (assume guilty
until proven innocent).  Okay, that has nothing to do with SPF.

> Second, because it breaks bounces

SPF doesn't break bounces, it's an almost desperate attempt to
save them.  If I'd send a mail to your address, and that is a
"traditional forwarder", and the next hop rejects the forward,
because you're not allowed to forge my MAIL FROM, then I get a
bounce from your forwarder.  Nothing broken in this scenario.

If it's a "responsible forwarder" the next hop won't reject
your forward based on my sender policy.  And if something else
breaks in this case you own the pieces, it's your mail.

> I've already had one message produce a misfire from my
> automated filtering because its envelope-from was mangled by
> SRS (itself a direct consequence of SPF).

Just use another way to forward your mail if SRS confuses your
filters, and if modifying your filters is really no option.

                          Bye, Frank

---

From: der Mouse <[email-masked]>
Date: Mon, 29 Nov 2004 18:30:16 -0500 (EST)

>> Second, because [SPF] breaks bounces

This was a braino on my part.  I meant "forwarding".

>> I've already had one message produce a misfire from my automated
>> filtering because its envelope-from was mangled by SRS (itself a
>> direct consequence of SPF).

No, you misunderstand.  This was damage done by SRS to a message that
wasn't being forwarded.  Apparently the envelope was SRSed before the
message got bounced.  (Perhaps the message was being forwarded
internally, but it seems to me that shouldn't provoke SRS.)

I don't entirely understand _why_ SRS got its paws on the envelope, and
it may be fairer to call it an implementation bug, but it certainly
wouldn't've happened without SRS, and I thus consider it to at least
some extent damage done by SPF.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign