Subject: [Asrg] "worm spam" and SPF

From: Fridrik Skulason <[email-masked]>
Date: Fri, 26 Nov 2004 11:10:00 +0000

My own definition of "spam" is pretty broad, not just UCE, but pretty much
any unwanted crap in my mailbox.  In particular that includes worms as
well as worm-generated bounces and other mail directly or indirectly
created as a result of computer worm activity.

As everyone probably knows, there is a pretty large outbreak going on 
right now. According to our mail filters at http://aves.f-prot.com,
10.56% of all filtered E-mail contains W32/Sober.J@mm.  In addition,
there is a significant number of bounces as well.  

According to my definition that is "spam" - and even those who prefer
a more narrow definition should at least agree that this is unsolicited
and unwanted.

I have said before that universal adoption of SPF would kill off the
current generation of worms (and that includes Sober.J) - however,
there are a few points worth noting.

* We (f-prot.com) published a SPF record, with -all.  I am not going
  discuss the possible problems with that policy, but we did evaluate
  the advantages and disadvantages.  Hopefully someone has rejected some
  worms based on that policy - however, we are getting plenty of
  "bounces" from domains that obviously have not implemented SPF
  checking.

* Some of the domains that send us those bounces have published SPF
  records, which indicates they are aware of SPF, but for one reason
  or another they have decided not to implement SPF checking, so
  they continue to cause problems for everyone else with those
  bounces.

* In fact, it is irrelevant how many domains publish SPF records. Even
  if every single domain had a record with "-all", it would not help
  one bit with the bounces.  The reason is of course that what really
  matters is the number of domains that actually check SPF records and
  reject and drop mails that fail.

* Even worse are the domains that do not bounce the message, but 
  analyze it and reply with a message like "MDaemon Warning - virus
  found".  Sending such messages is completely unacceptable behaviour.
  Most "current generation" worms forge the sender's address, and
  a mail filter that replies to the "From:" line with a warning
  of this kind is worse than useless - it is a part of the problem,
  not a part of the solution as it is generating spam (under my own
  broad definition of "spam", as mentioned earlier).

So, the bottom line regarding worm-spam and SPF is:

* Publishing SPF records may reduce the number of worm bounce messages,
  but that depends on the number of other domains checking the records.

* Doing SPF checking will block the vast majority of the worms, but it
  will not help with the bounces or the filter alerts.

* Too many domains have incorrectly configured mail filters that reply
  with an alert to the (forged) sender's address when they find a worm. 
  That behaviour is just not acceptable - if fact, I urge everyone
  receiving a message telling them (incorrectly) that they sent out a
  worm to contact the domain sending out that alert and inform them
  that their mail filters are incorrectly configured.  My own standard
  reply follows....feel free to use that for inspiration

      ---- start of reply ----

      Your automated software just sent me the message below, where 
      you are basically accusing me of sending you a virus.

      I must express my displeasure, and insist that you fix the
      problem.

      The virus in question forges the "From:" field.  The sender can
      be anyone, and even a cursory check of the envelope address
      should reveal that the mail originated elsewhere.

      Incorrectly accusing people of spreading viruses is not only 
      impolite - it could potentially be a legal problem - no, I am 
      not threatening to sue you for defamation, but someone else might.

      My advice is to reconfigure your mail filter not to send alerts
      to the "From:" address.  If you do not, you should probably get
      legal advice on your policy.

      ---- end of reply ----
  
-- 
Fridrik Skulason   Frisk Software International   phone: +354-540-7400

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

---

From: Gadi Evron <[email-masked]>
Date: Sat, 27 Nov 2004 05:00:15 +0200

> there is a significant number of bounces as well.  

We've reached 1.5 GB an hour of this s**t since Tuesday. Only our AV 
calls it Sober.I@mm.

I agree, bounces are the very evil of the net itself.

 >   will not help with the bounces or the filter alerts.

It may block the vast majority of current worms, but I doubt it would 
stop the tide for long.
VX-ers will find other ways of abusing infected victims.. they might 
even send out email using the user's own email account and/or email client.

As long as there are huge drone armies out there, and their likes - I 
don't see how spam solutions today would really work as people hope. 
They will help reduce the numbers by a 0 or two though (if widely 
implemented in a reasonable period of time). I may actually get hundreds 
instead of thousands of spam messages a day.

	Gadi.

---

From: Bill Cole <[email-masked]>
Date: Fri, 26 Nov 2004 22:48:21 -0500

At 5:00 AM +0200 11/27/04, Gadi Evron wrote:
>>As everyone probably knows, there is a pretty large outbreak going 
>>on right now. According to our mail filters at 
>>http://aves.f-prot.com,

No, they are not. They are a critically important part of the 
robustness of email. Broad acceptance of the idea that bounces are 
evil will be the last nail in the coffin of email.

Systems which generate bounces as a result of determining that 
particular messages are untrustworthy are evil. Software which 
determines that mail is spam (or viral, which is logically a subset 
of spam) and then goes on to trust that mail enough to generate a 
bounce message is designed by people who are either evil or stupid 
enough to be indistinguishable from evil.

>It may block the vast majority of current worms, but I doubt it 
>would stop the tide for long.

Uh, have you heard of Swen???

Viruses are already using the victim machine's mailer configuration 
to send mail. They have been doing so for a year and more.

The problem is deep design flaws in Microsoft's mailers and operating system.

The problem is Microsoft.

>As long as there are huge drone armies out there, and their likes - 
>I don't see how spam solutions today would really work as people 
>hope. They will help reduce the numbers by a 0 or two though (if 
>widely implemented in a reasonable period of time). I may actually 
>get hundreds instead of thousands of spam messages a day.

I reject about 10,000 port 25 connection attempts ever day from 
various parts of the net that I believe to house no valid 
correspondents and to house an inordinate number of zombies and 
machines owned 'legitimately' by slimeballs like Alan Ralsky, Scott 
Richter, Verisign, DoubleClick, and other untrustworthy, deceptive, 
spamming entities. The domains behind that router house less than a 
dozen distinct mail receivers.

I reject a few thousand spam attempts daily in SMTP based on the IP 
address of the connecting system. Most of that is done by rejecting 
machines which have been seen by others to be spam and worm zombies 
(Spamhaus XBL) or which are in networks I've seen machines trying to 
deliver in zombie-like ways.

95%+ of the mail delivered here is not spam. 99%+ of the attempts to 
send mail here are spam, much via zombie armies. Killing the zombie 
armies would let me move some router blocking back to SMTP and reduce 
some SMTP blocking. Global SPF adoption would kill off today's zombie 
armies, but with Swen out there as an example, that would be a brief 
respite.

-- 
Bill Cole                                  
[email-masked]

---

From: Seth Breidbart <[email-masked]>
Date: Sat, 27 Nov 2004 01:54:38 -0500 (EST)

Fridrik Skulason <[email-masked]> wrote:

> My own definition of "spam"

is a concept that makes spam-fighting worthless and undefinable.
Consider that spammers all define spam as what they don't do.  There
is one agreed definition (in the email area): Unsolicited Bulk Email.

> is pretty broad, not just UCE, but pretty much
> any unwanted crap in my mailbox.

If the bully who picked on you in fifth grade found your email address
and started picking on you in email, that would be unwanted crap, but
it wouldn't be spam.  On the other hand, "Jesus Is Coming Soon (Look
Busy!)" sent to 50 million email addresses isn't commercial, but is
spam.

>  In particular that includes worms as well as worm-generated bounces
> and other mail directly or indirectly created as a result of
> computer worm activity.

Unsolicited, surely.  Bulk, unless it's an individual worm (in which
case it isn't a worm), yes.  Email, yes.  Hence spam; no need for a
private definition.

> current generation of worms (and that includes Sober.J)

1. "universal adoption" is part of being a FUSSP.

2. The next generation would just be more careful about who they
   claimed to be.

>  they continue to cause problems for everyone else with those

At this point, strong SPF checking breaks too much stuff (especially
forwarding).

Seth

---

From: Daniel Feenberg <[email-masked]>
Date: Sat, 27 Nov 2004 18:18:50 -0500 (EST)

> evil will be the last nail in the coffin of email.

Rejection during SMTP processing is a good substitute for delayed DSN
messages. It is not necessary to drop any messages on the floor, which
would, I agree, be a terrific loss. I am aware that this is easier with
some MTAs than others, but the technical reasons for delaying notification
untill after message acceptance are not sufficiently strong to justify the
practice into the future.

For example, it has been argued that there is a security advantage in not
having the user list available to the "outside" MTA, or that there is a
reliability advantage in have the secondary MX at a remote location
without access to the user list, or that anti-spam or anti-virus
processing is so CPU intensive that it needs to be queued for delayed
execution. All of these are cogent, but none are sufficiently powerfull to
justify sending DSNs to possibly forged From addresses.

It is true that some MTAs make it extremely difficult to reject invalid
users, or spam or virus messages during SMTP processing, but in the
fullness of time they will be fixed or left behind, and MTAs will be
capable of making accept/reject decisions in real time while the
connecting server waits for the final "." in the data step of the SMTP
dialog.

Daniel Feenberg

---

From: Gadi Evron <[email-masked]>
Date: Sun, 28 Nov 2004 02:12:16 +0200

> connecting server waits for the final "." in the data step of the SMTP

Most GW AV's act as mail relays.. dealing with it is not a problem.. 
there is always a queue (unless some emulation etc. starts getting 
involved).

Unrelated.. why wait for th '.'? Has anyone else noticed how sendmail 
would die after a certain amount of un-closed connections are made? 
We've seen this happening a few times in the past few months.

	Gadi.

---

From: "Bruce Brown" <[email-masked]>
Date: Sat, 27 Nov 2004 16:08:03 -0800

After consideration and reconsideration I've come to the conclusion that
delayed rejection to hide the user list is much like security through
obfuscation -- it is too easily defeated. Consequently, I've found it better
to reject messages "on the wire" and keeping them from getting past the
first MTA. Delays, so that you can send a bounce (often to a bogus address)
is at best a waste of resources.

-- Bruce

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Daniel Feenberg
> Sent: Saturday, November 27, 2004 3:19 PM
> To: Bill Cole
> Cc: [email-masked]
> Subject: Re: [Asrg] "worm spam" and SPF
> 
> 
>

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 28 Nov 2004 01:32:13 +0100

> 1. "universal adoption" is part of being a FUSSP.

True.  But in the case of SPF it's good eough if most spammers
and worm authors "adopt" it - by simply not forging proteted
addresses.

> 2. The next generation would just be more careful about who
> they claimed to be.

Yes, that's the idea.  Like closing resp. blacklisting open
relays SPF is not the FUSSP, it's the next "necessary" step.

Defining "necessary" by the minimal modification you can get
away with (excl. radical approaches like "delete all bounces"
because that breaks SMTP).

> At this point, strong SPF checking breaks too much stuff
> (especially forwarding).

It's not "especially forwarding", it's only 251-forwarding to
third parties abusing the original MAIL FROM.  That was always
illegal in STD 10, you had to add the route to the MAIL FROM.

RfC 2821 removed the routing from bounces, and that implicitly
obsoleted 251-forwarding.  It's not SPF breaking stuff, quite
the contrary, SPF tries to fix something broken by 2821.  Bye.

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sun, 28 Nov 2004 02:11:07 +0100

On 2004-11-28 01:32:13 +0100, Frank Ellermann wrote:
> third parties abusing the original MAIL FROM. 

You mean section 3.2?

The 251 reply is used to tell the sender the correct address, so that
the sender can send the next mail directly. I have never seen this, and
I would consider it broken under most circumstances (I.e., if I give
somebody an email address A which is forwarded to my other address B, I
do not want to disclose B to that person). The 551 reply may be useful
sometimes.

> That was always illegal in STD 10, you had to add the route to the
> MAIL FROM.

Yes, but that is true for all kinds of relaying (see section 3.6):

| In any case, the SMTP adds its own identifier to the reverse-path.

I don't know if that requirement of RFC 821 was ever widely implemented.
If it was, it was discontinued at least 15 years ago.

> RfC 2821 removed the routing from bounces,

Yes, because nobody was using it anyway.

> and that implicitly obsoleted 251-forwarding. 

I see no connection between source-routes and forwarding in rfc 821.

> It's not SPF breaking stuff, quite the contrary, SPF tries to fix
> something broken by 2821.  Bye.

A source route in the reverse-path isn't any more reliable than
Received-headers. It solves nothing without additional requirements
(like: "every relay needs to record which mails it forwarded an relay
bounces in the opposite direction"), and therefore SPF cannot fix what
wasn't broken.

	hp

-- 
   _  | Peter J. Holzer    | Je höher der Norden, desto weniger wird
|_|_) | Sysadmin WSR       | überhaupt gesprochen, also auch kein Dialekt.
| |   | [email-masked]         | Hallig Gröde ist fast gänzlich dialektfrei.
__/   | http://www.hjp.at/ |   -- Hannes Petersen in desd
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Bill Cole <[email-masked]>
Date: Sat, 27 Nov 2004 20:34:05 -0500

>practice into the future.

It isn't a matter of specific MTA's, but of the complexity of 
internal mail systems behind an external MX. If an external MX is is 
an entry point for a mail system where you cannot do final delivery 
synchronously with message acceptance, there will be cases where a 
later DSN, silent quarantine, or silent dropping are the only options.

>justify sending DSNs to possibly forged From addresses.

I disagree, but only slightly. There is no excuse for sending DSN's 
to addresses that you can reasonably expect to be forged, i.e. 
because you determine the mail to be viral or spam and therefore 
refuse to deliver it. If you refuse to deliver a message because you 
have determined that the real sender (a spammer or a piece of 
malware) is not to be trusted and that the mail is itself 
untrustworthy, it makes no sense at all to generate a DSN for the 
message.

>connecting server waits for the final "." in the data step of the SMTP

This is not an MTA issue at its heart. the core problem is that a lot 
of mail systems, particularly larger ones that are not structured as 
simply as most ISP systems, cannot even in principle do all mail 
delivery synchronously with exterior gateway SMTP acceptance. If 
there is a finite period where the message has been accepted but has 
not been finally delivered to whatever point the user eventually 
picks up their mail from, there will be some cases where the user 
existed and their mailbox was capable of accepting a message when it 
was accepted but where at least one of those will not be true when 
final delivery is tried. Mail systems have been built this way for 
decades because email usually and Internet email in particular have 
been designed for store-and-forward operations, not synchronous 
end-to-end delivery. Redefining that imposes major re-architecture 
requirements on a lot of large (mostly corporate) mail systems.

-- 
Bill Cole
[email-masked]

---

From: der Mouse <[email-masked]>
Date: Sun, 28 Nov 2004 01:30:10 -0500 (EST)

> After consideration and reconsideration I've come to the conclusion
> that delayed rejection to hide the user list is much like security
> through obfuscation -- it is too easily defeated.

I agree - and furthermore, if you defer rejection until after the data,
it is approximately as hard to abuse as accept-and-bounce.  (It does
require a little care with 4xxing RCPTs to preserve protocol
conformance while making it nontrivial to game, but that can be done.)
Yes, rejecting after data burns bandwidth to carry the body - but
accept-and-bounce is even worse.

/~\ 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: Daniel Feenberg <[email-masked]>
Date: Sun, 28 Nov 2004 09:05:07 -0500 (EST)

It occurs to me that a site that was unwilling to handle policy rejections
during SMTP processing, and hence faced with the choice of returning DSNs
to a possibly forged "From" address or dropping them on the floor, does
have an intermediate choice. They could return the DSN via the connecting
host or the MX for that connecting host. That is, whatever the "From"
address, go back to the connecting host to deposit the DSN into the mail
stream. In many legitimate cases that host will accept mail for that
"From" address, it is very unlikely to accept forged mail unless it is an
open relay.

There is already a mechanism "source routing" as the basis for
implementation. RFCs still require the ability to process source routes
for servers, although it is no longer required for clients. In any case,
the connecting host doesn't actually have to do anything special. It just
sees the "mail rcpt" address and either accepts or rejects the message
depending upon its ability to deliver to that user.

It is interesting to contemplate how this would play out if a few major
players adopted it as a policy. I don't see any feasible response by
spammers - this doesn't really affect them, only legitimate mail. Note
that while a spammer could adopt forged "from" addresses that would be
accepted by his host, it wouldn't help him deliver any spam. 

As I said, I don't consider this superior to rejection during SMTP
processing, but it is an interesting substitute.

Daniel Feenberg

---

From: Bill Cole <[email-masked]>
Date: Sun, 28 Nov 2004 09:29:55 -0500

At 9:05 AM -0500 11/28/04, Daniel Feenberg  imposed structure on a 
>"From" address, it is very unlikely to accept forged mail unless it is an

That is so far from anything resembling rational behavior for any 
mail server that I'm hard pressed to respond to it within the decorum 
bounds of this mailing list.

I'll just say that I think this is an idea that I pray never sees 
application in the real world.

>depending upon its ability to deliver to that user.

I think you might find it useful to read RFC2821 again a bit more carefully.

-- 
Bill Cole
[email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 28 Nov 2004 18:49:24 +0100

Bill Cole wrote:
 
> That is so far from anything resembling rational behavior for
> any mail server that I'm hard pressed to respond to it within
> the decorum bounds of this mailing list.

If you don't like STD 10 you could try to inform the RfC-editor
about your reservations.

> I think you might find it useful to read RFC2821 again a bit

RfC 2821 is the bible of spammers, forgers, and worm authors,
it's a "worst common practice" if there ever was one.  Trying
to fix a minor problem in STD 10 it got the routing examples
completely wrong.
                          Bye, Frank

---

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

>>> [suggestion to send bounces to the host who handed off the mail to
>>> you, or its MX]
>> mail server that I'm hard pressed to respond to it within the
>> decorum bounds of this mailing list.
> If you don't like STD 10 you could try to inform the RfC-editor about
> your reservations.

If you think STD 10 or RFC 2821 (which obsoleted 821 over three and a
half years ago) permits such behaviour, I suspect you need to go reread
it.  As far as I can tell you are either sending a bounce somewhere
other than the envelope-from or you are sending mail to a given address
somewhere other than the (possibly implicit) MX for the domain portion
of the address (or your own smarthost).  I've never seen any standard
support for either; if you think you have, I would very much like to
see a specific reference.

In particular, if you have any reason to think that disliking such
behaviour means disliking STD 10, or its superseding document, I want
to see a specific reference.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 29 Nov 2004 19:16:16 +0100

der Mouse wrote:

> STD 10 or RFC 2821 (which obsoleted 821 over three and a
> half years ago)

RfC 2821 _wanted_ to obsolete STD 10, describing SMTP as it
is today.  But obviously there's a problem with today's SMTP,
that's why we are here.

> As far as I can tell you are either sending a bounce
> somewhere other than the envelope-from

No, you send it using the Return-Path, as the name says.  For
the first hop MAIL FROM:<me> you return it to me.  If all is 
okay for this hop it becomes a MAIL FROM <@hop1,me>, and then
the Return-Path is <@hop1,me>.  Later <@hop2,@hop1,me> etc.,
essentially the same as bang paths, you can stil see it in all
Usenet news articles as Path: header field.

hop1 was ready to accept any bounces MAIL FROM <> RCPT TO <me>,
hop2 handled any bounces MAIL FROM <> RCPT TO <@hop1,me>, etc.

It's completely useless in all "normal" cases today, because
"your" side knows where its mailout to reach my MX is, and my
MX knows how to find my POP3 mailbox or whatever else.  It's
also useless if we're both UUCP users, or if we use aliases.

But forwarding to a third party was never a "normal" case, it
has its own 251 and 551 result codes.  In a world where MX do
what the name says it's a waste of bandwidth if hop1 has to
to send stuff to a completely unrelated hop2.  It was a quick
and dirty hack to abuse the original MAIL FROM <me> instead of
<@hop1,me> in this case, and it fired back with tera bytes of
forgeries.  SPF puts an end to this abuse.  RfC 2821 RIP.

> I want to see a specific reference.

See the STD 10 quotes in:

<http://article.gmane.org/gmane.ietf.mxcomp/5455>
<http://article.gmane.org/gmane.ietf.mxcomp:5454>
<http://article.gmane.org/gmane.ietf.mxcomp/5453>

5454 was John's answer ("quixotic quest"), where he explains
why simply returning to STD 10 isn't good enough.  That's of
course true, and SPF doesn't try this stunt.  Arguably SRS
goes in this direction.
                        Bye, Frank