Subject: [Asrg] [1] Why SPAM is worse in SMTP than in other protocols

From: "Alan DeKok" <[email-masked]>
Date: Tue, 16 Dec 2003 14:21:18 -0500 (EST)

I've written a *very* rough first draft of a document.  It's
available at:

  http://www.striker.ottawa.on.ca/~aland/smtp-sucks/problems.txt

  If there's interest in contributing to the document, I'll set up a
mailing list, and we can continue from there.

  Even as rough as it is, I feel very positive about it.  It gives a
number of *concrete* reasons as to why spam is worse in SMTP than in
any other protocol.  It allows us to classify the anti-spam measures,
and see which part of spam they fight.

  It also allows us to demonstrate the flaws in anti-spam measures.
e.g. "Pull" addresses one feature of SMTP which enables spam, but in
isolation, doesn't address others.  Therefore, pull alone is
insufficient to stop spam.

  The largest problem I can see with any attempt to "patch" SMTP to
fix it's design flaws is the continued existence of older servers.
Many older servers which won't implement any new anti-spam "fix" will
be sending spam, and many others won't be sending spam.  It will be
very difficult to tell the difference between the two, which
severely limits the effectiveness of any anti-spam system.

  Alan DeKok.

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

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 16 Dec 2003 15:56:55 -0500

[Subject changed to be more readable, was "Re: [Asrg] [1] Why SPAM is 
worse in SMTP than in other protocols". Mod.]

> severely limits the effectiveness of any anti-spam system.

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"I want to know G-d's thoughts... the rest are details" (Albert Einstein)
-------

---

From: Dave Crocker <[email-masked]>
Date: Tue, 16 Dec 2003 14:00:57 -0800

Alan,

AD>   Even as rough as it is, I feel very positive about it.  It gives a
AD> number of *concrete* reasons as to why spam is worse in SMTP than in
AD> any other protocol.  It allows us to classify the anti-spam measures,

  An exercise like the one you are doing can be very useful.
  
  Let me strongly encourage you to re-cast the bulk of your document
  into non-technical issues, first.  That is, discuss messaging and a
  human process, without concern for whether it is paper mail, email, or
  whatever.  As you offer criticisms of the human communication modes
  available for Internet mail, compare whether they differ from the
  modes available for other messaging.

  When you suggest superior modes of operation, discuss them in terms of
  the human communication first, and the technical aspects second.

  After we have some consensus about these issues, in terms of human
  communication, it will then be reasonable to see what changes are
  needed to the technology.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 17 Dec 2003 01:27:50 +0100

> >  http://www.striker.ottawa.on.ca/~aland/smtp-sucks/problems.txt

I had only a short glance, but

*> 5. Don't allow multiple RCPT TO's for unknown senders.
*>   The problem is that you can't selectively NACK later RCTP TO's.  The
*>   sending MTA then decides that the entire message was NACK'd, and
*>   discards (or retries) it.

If the MTA is behaving that way it is seriously broken. The behaviour
as you describe only happens if you NACK the "DATA" command after the
CRLF.CRLF (RFC 2821 4.2.5 Reply Codes After DATA and the Subsequent
<CRLF>.<CRLF>)

Our mailserver doesn't allow more than 5 RCPT TO per session. The others
are answered with a temp failure (4xx code). This works without any
problems for years.

Btw. I have posted some stats (backed by someone from an university,
sorry forgot about the name) and it showed that more than 95% of all spam
is NOT multi-RCPT. However I can't find it in the archives nor in my
mailbox at the moment :((

    \Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 16 Dec 2003 19:48:28 -0500

>   modes available for other messaging.

Would it be something along the lines of the following?:

---------------
In human communications we have a sender, a receiver, the message and a 
messaging system. The sender creates the message, hands it off to the 
messaging system, and the system delivers it to the receiver.

If the delivery is unsuccessful, depending on the system used, the 
sender is notified of the failure. Different messaging systems can also 
deliver the message to multiple receivers, and combine messages from 
multiple senders into one message before being delivered to receivers.

Examples of messaging systems include: direct speech (face to face), 
telephone, fax, television, radio, email, instant messaging, postal 
mail, telegraph, etc. All of these have potential for abuse which varies 
from system to system.
---------------

>   needed to the technology.

The underlying problem is a human one and we need to understand it 
before changing the technology. The reasons why spam is being sent, and 
is profitable, are human reasons which need to be addressed.

Yakov

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"And this too shall come to pass"
-------

---

From: mathew <[email-masked]>
Date: Tue, 16 Dec 2003 21:25:26 -0500

> and see which part of spam they fight.

Here's another one:

SMTP requires resources which cost money, yet an unlimited number of 
unauthenticated users are allowed to consume those resources as much as 
they like, at no financial cost to them.

That's a big human problem. I can't think of any system with that 
problem that has worked in the real world.

mathew

---

From: J C Lawrence <[email-masked]>
Date: Tue, 16 Dec 2003 21:38:08 -0500

On Tue, 16 Dec 2003 21:25:26 -0500 
mathew  <[email-masked]> wrote:

> unauthenticated users are allowed to consume those resources as much
> as they like, at no financial cost to them.

> problem that has worked in the real world.

Just to catechise it, this is normally known as a Tragedy of the
Commons.

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
[email-masked]               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 17 Dec 2003 09:26:32 +0000

>CRLF.CRLF (RFC 2821 4.2.5 Reply Codes After DATA and the Subsequent

RFC821 was broken on this point I think? A 552 is suggested for too many
recipients, but this would imply a permanent failure for the message? I
guess that this might account for some interoperability issues :-)

>are answered with a temp failure (4xx code). This works without any

Of course, but this policy violates RFCs - what happened to the 100 RCPT
requirement? I'd be happy to see this kind of behavior written up in some
way - revising rfc2821. There's a whole lot of things that work better if
this requirement can be ignored.

--

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Dec 2003 08:21:32 -0800

Yakov,

>>   into non-technical issues, first.

YS> Would it be something along the lines of the following?:

That's a good start, for setting up the important statements.  The next
set of statements should talk about how all this is used by people.  For
example, when are senders required to formally sign their messages?
What kind of signature?  (For example, there is a big difference between
having it notarized, versus not.)

d/

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 17 Dec 2003 18:29:40 +0100

> this requirement can be ignored.

Depends on how you see it. According to RFC 2821
------------------------------------------------------------------------
7.7 Scope of Operation of SMTP Servers
   It is a well-established principle that an SMTP server may refuse to
   accept mail for any operational or technical reason that makes sense
   to the site providing the server.  However, cooperation among sites
   and installations makes the Internet possible.  If sites take
   excessive advantage of the right to reject traffic, the ubiquity of
   email availability (one of the strengths of the Internet) will be
   threatened; considerable care should be taken and balance maintained
   if a site decides to be selective about the traffic it will accept
   and process.
------------------------------------------------------------------------

We have operational and technical reasons to act as we do and to
override the 100 RCPT limit imposed by the RFC.
From our observations the only impact on the Internet mail system
is that bulk senders need more circles to get their messages through
so we think we have taken considerable care and still maintained the
balance.
From yesterdays logfile on a machine without the limits (only
connections from external hosts):

count no of rcptto per connection

   1 58
   1 32
   1 28
   1 27
   2 26
   1 25
   1 24
   2 23
  35 20
  12 19
  10 18
   5 17
  20 16
  35 15
  26 14
  17 13
  34 12
  44 11
 208 10
 155 9
 186 8
 199 7
 333 6
 460 5
 673 4
1369 3
5241 2
134885 1

This means e.g. that we had  5241  connections sending 2 rcptto during
one connection and we had 1369 connections sending 3 rcptto during one
connection.

We had 143957 connections in total.
93% of all connections sent only one RCPT TO
Allowing up to 5 RCPT TO per connection makes up for 99.076% of all
connections.

The host with 58 rcptto in one connection was definitely legal email.
It looks like MX sorting and maybe a SMTP MTA on a dialup line, as there
were about 20 different envelope senders (small company sending email to
field staff; we're running the Mailboxes for some of their field staff).

However the next hosts in the "hit list":

32 unknown:216.244.148.251			dictionary spam
28 unknown:218.28.13.138			dictionary spam
27 unknown:211.224.65.91			dictionary spam
26 cmb8-162.dial-up.arnes.si:194.249.38.162	dictionary spam
26 216.93.176.221:216.93.176.221		dictionary spam
25 67-23-157-81.chvlva.adelphia.net:67.23.157.81 dictionary spam
24 unknown:212.6.96.162				dictionary spam
23 unknown:203.82.168.133			dictionary spam
23 unknown:81.195.151.34			dictionary spam

	\Maex

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 17 Dec 2003 14:44:16 -0500

>   An exercise like the one you are doing can be very useful.

  I also have planned another document, which discusses which
protocols are used in what situations to send email.  It will point
out which use models, and which fields of which protocols, are being
abused to send spam.

>   into non-technical issues, first.

  I'm not sure why.  The intent of the document is clear: To compare
and contrast SMTP to other protocols, and to explain why and how
technical features in SMTP are being abused to send spam.

  The only non-technical issue I can see being relevant is that any
proposed changes to the use or deployment of SMTP should minimally
affect the way users currently send messages.  This issue can be dealt
with, without getting into any details of human communication modes.

> That is, discuss messaging and a

  I honestly don't see why.  The intent of the document is to describe
what's wrong with SMTP today, not to describe why or how people use
SMTP to send messages.  End-user human communication modes are not
relevant when discussing protocol flaws in SMTP, between MTA's.

>   needed to the technology.

  The discussion of human intentions and beliefs about which processes
*should* be used to send email is a topic which has spawned countless
flamewars on this list.  After being burned a number of times, I would
prefer to avoid those issues.  If you (or anyone else) writes such a
document, I'm willing to read it.  But I can't contribute to one.

  By focussing on technical issues, I can avoid these human issues, so
long as I ensure that any technical recommendations do not affect
current use patterns or beliefs about email properties (whatever those
are.)

  The only other reason I can see to discuss human communication modes
and intentions is to see if the design of SMTP fulfills our goals for
human communication.  Since SMTP has been around for 2 decades, it's a
little late to have that discussion.

  A discussion of human communication modes is best suited for a
document which describes the requirements for a protocol to replace
SMTP.  In that context, it's benefical to define our human
requirements and goals; along with the technical limitations of SMTP.
This will let us be sure that we don't make the same mistakes again.

  But I do not propose replacing SMTP.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 17 Dec 2003 14:58:14 -0500

> mail, telegraph, etc. All of these have potential for abuse which varies 

  ... and some have technical design flaws which enable more abusive
behaviour than in other protocols.

  It is clearly within the charter of this group to discuss the design
flaws of SMTP.  Other messaging systems are relevant only so far as
they do not have the same design flaws.

  It is clearly within the charter of this group to discuss which
characteristics of SMTP are being abused by spammers, and how to
address those characteristics to prevent abuse.  Other messaging
systems are not relevant for that discussion.

> is profitable, are human reasons which need to be addressed.

  The psychology of criminals is a complicated topic, with centuries
of research and discussion behind it.  The final conclusion after that
time is that the best way to deal with criminals is to catch them.
Their reasons for being criminals are not relevant to that process.
Even worse, their reasons for being criminals largely amount to
"because I want to".  There's little anyone can do to address that
problem, either, except by catching and punishing them.

  In the terms of pharmacology, spam is a problem for which treatment
is "symptomatic".  The causes don't matter.  Once the symptoms are
treated, the problem will be solved.

  Alan DeKok.

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 17 Dec 2003 15:57:47 -0500

> document, I'm willing to read it.  But I can't contribute to one.

I will be willing to write up such document.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Among all our enemies / The ones to be most feared are often the 
smallest" (Jean de la Fontaine)
-------

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 17 Dec 2003 15:49:16 -0500

> systems are not relevant for that discussion.

I believe that the intent here is to compare other messaging system to 
SMTP in regards to the design flaws and abusive behavior possible, and 
how other messaging systems have dealt with these problems, in order to 
see whether similar approaches can be used for SMTP.

For example, in the telephone network, every phone call is much more 
easily traced than emails, and people cannot "0wn" or "hack" your phone 
in order to send phone spam (well not yet anyway, think VoIP and ENUM). 
These force marketers to use specific methods, which in turn reduce the 
amount of junk phone calls. The same analogy can be applied to email - 
if email is more traceable, and less hackable, then spammers are forced 
to use other ways. While the methods to achieve the same effect vary, 
the end goals do not.

Therefore, a comparison to other messaging system can provide us with a 
set of features present in those systems, which accomplish the same goal 
of reducing abusive behavior. Then we can see which of these features 
can be added to email as well, if possible.

However, for this specific document, the comparison with other systems 
should be as only go as far, as determining which other systems have 
similar flaws and which do not, in order to be able to do the analysis 
later.

> treated, the problem will be solved.

Ok, I will agree, but I still think this issue is relevant in a slightly 
different light. Let me give you an example: most spammers send spam 
because they make money. Some spammers send spam for revenge ("joe 
jobs"). Yet some look for time machines and send chain letters. Now 
given these categories, which ones do we really care about? Probably 
only the first one or maybe two. The third one is so small, that there 
is no reason to address it. Therefore, given a proposal that addresses 
the third one, we probably would not bother researching it, since the 
benefits are negligable.

Given only the technical design flaws in the protocol, will not provide 
us with a determination of whether specific flaws are significant enough 
to be pursued. What we should do, is once we have determined what the 
flaws are, then analyze which of them are more significant then others, 
in order to best concentrate our efforts.

However, your specific document is only for listing the design flaws. 
The analysis and determination of which flaws are significant is 
something to be left for the future.

Yakov

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Power tends to corrupt, and absolute power corrupts absolutely" (Lord 
Acton)
-------

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 17 Dec 2003 17:11:08 -0500

Yakov Shafranovich <[email-masked]> wrote:
> Some spammers send spam for revenge ("joe jobs"). Yet some look for
> time machines and send chain letters. Now given these categories,
> which ones do we really care about? Probably only the first one or
> maybe two. The third one is so small, that there is no reason to
> address it. Therefore, given a proposal that addresses the third
> one, we probably would not bother researching it, since the benefits
> are negligable.

  If they're using the same methods to spam, they're identical so far
as the recipient can tell.  If they're using different methods, then
they are technically different, and technical methods of
distinguishing them can deal differently with each kind of spammer.

> to be pursued.

  Exactly.

> What we should do, is once we have determined what the flaws are,
> then analyze which of them are more significant then others, in
> order to best concentrate our efforts.

  And if we don't know what the flaws in SMTP are, we don't even know
what kinds of questions to ask, to see which behaviours are more
significant than others.

  Alan DeKok.

---

From: "Za'mbori, Zolta'n" <[email-masked]>
Date: Thu, 18 Dec 2003 15:07:51 +0100

> can be added to email as well, if possible.

IMHO there are interesting (dis)similarities between SMTP and TCP. For 
example dictionary attack is like portscan and email address forgery is 
like IP spoofing.

I think making SMTP more TCP-like can help to implement SMTP-firewalling 
functionality as in the case in the evolution from routers to firewalls.

z2

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 18 Dec 2003 18:09:07 -0500

Some comments:

> 
> 3. The sender can request that the message be forwarded to (almost)
>    anyone else.
> 
>   SMTP isn't a "user to user" protocol.  It's a "submitter to MTA"
> protocol.  In the case of open proxies, the MTA may be abused to
> re-send the mail to anyone on the net.

Isn't SMTP an MTA-to-MTA protocol, with SUBMIT being the "submitter to 
MTA" protocol?

> 6. no negative feedback
> 
>   TCP has congestion control.  ICMP "port unreachable", etc.
> 
>   When SMTP messages are thrown away, they're often done so by the end
> user.  The recipient MTA usually doesn't know, and the originating MTA
> doesn't know.  So in the absence of negative feedback, spammers
> increase their sending rates, in the hope that some messages will get
> through.

This also has to do with the fact that the body of the message and the 
SMTP transaction are separate from each other.

>  What to do about it
>   -------------------

> e.g. Messages from unknown senders should be treated with great
>   suspicion.  Any and all available information should be used to
>   determine how to process the message.

A good example would be giving a higher value to unknown senders in 
SpamAssasin.

Yakov

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"I ate your Web page. / Forgive me. It was juicy / And tart on my 
tongue." (MIT's 404 Message)
-------

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Dec 2003 21:42:49 -0600

Yakov,

>> re-send the mail to anyone on the net.

YS> Isn't SMTP an MTA-to-MTA protocol, with SUBMIT being the "submitter to

YS> MTA" protocol?

yes, although that is recent, and most poster-to-MTA interactions do

use SMTP. However access control is now typical, so the problem of

open relaying is solved technically. Whether the solution is used is

not a problem with SMTP.

>> through.

YS> This also has to do with the fact that the body of the message and the

YS> SMTP transaction are separate from each other.

Huh?

1. SMTP is equivalent to a link-level, point-to-point protocol. As

such, it has plenty of negative feedback and congestion control. The

larger mail service is a classic datagram model, like UDP. And, no,

it has no congestion control. However as one contemplates this

problem, keep in mind the challenge of doing meaningful end-to-end

congestion control in the face of multi-day latencies.

2. I think folks are trying to make the underlying transport service

be responsible for higher-level, user-to-user problems. Remember that

spam is a social problem, not a technical one. So, worry about the

end-to-end object/envelope, rather than the hop-by-hop transfer

protocool.

>> determine how to process the message.

YS> A good example would be giving a higher value to unknown senders in

YS> SpamAssasin.

How is this different from whitelisting?

How is it affected by spoofing?

d/

--

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 21 Dec 2003 01:15:15 -0500

> end-to-end object/envelope, rather than the hop-by-hop transfer

So are you implying that we shouldn't worry about the SMTP transaction
at all, and concentrate on the message content itself, kind of like the
DK proposal?

While spam itself is an end-to-end problem, the abuse of the hop-by-hop
protocol is one of the reasons why spam happens. For example, in 
Ethernet the actual cables between different network segments are 
hop-by-hop. Someone slicing a cable at that point can introduce malicous 
traffic into the system, the same way somebody messing with a single 
SMTP hop-by-hop transaction can introduce spam into the network.

I think we need to address both issues of hop-by-hop protocol security, 
and end-to-end user issues. I do have your original suggestion in mind, 
and I am working on a document about email problems from the point of 
view of human communications in general. However, Alan's document 
concentrates specifically on SMTP.

> How is it affected by spoofing?

We do not want to reject all email from unknown senders since any
anti-spam system that is deployment needs to be adoped gradually.
Therefore, a completely unknown sender will be given a higher value in
the filter, as opposed to a known sender that will be given a lower 
value. Alan's document was refering to LMAP where even a known sender 
that uses LMAP is not necessarily trusted.

Yakov

-------

---

From: "Alan DeKok" <[email-masked]>
Date: Sun, 21 Dec 2003 10:33:54 -0500

Dave Crocker <[email-masked]> wrote:
> such, it has plenty of negative feedback and congestion control.

  Which is why people using Greylisting have shown it to be useless.

  Hmm... that doesn't sound right.  Ah, that's it: "plenty != sufficient"

> The larger mail service is a classic datagram model, like UDP. And,
> no, it has no congestion control. However as one contemplates this

  I don't see constructive criticism on the *technical* merits of the
documents.  Vague generalities sound helpful, but don't contribute
meaningfully to achieving any end goal.

> be responsible for higher-level, user-to-user problems.

  Not me.  I'm looking at tweaking the underlying transport service so
it's less amenable to being abused by user-to-user problems.

> Remember that spam is a social problem, not a technical one.

  Ah.  So the technical flaws in SMTP which *enable* spammers are
meaningless.  The "joe jobbing" and forgery associated with the
attempted theft of account information are direct results of those
technical flaws...  but addressing those flaws is a low priority, as
spam is a social problem, not a technical one.

> So, worry about the end-to-end object/envelope, rather than the
> hop-by-hop transfer protocool.

  I'm sorry Dave, but everything I see from you can be paraphrased as
"SMTP is perfect.  Let's do nothing technical to solve this problem."

  Alan DeKok.

---

From: Philip Miller <[email-masked]>
Date: Wed, 24 Dec 2003 12:34:32 -0500

There are two problems caused by the potential forgery that is possible in SMTP:
1. Filtering by sender's address is hard when someone could forge a friend's
address.
2. One can't hold the victim of the forgery accountable for the junk
transmitted.

The first problem makes whitelisting slightly troublesome. However, it
doesn't actually affect any other filtering, because a spammer with a
million addresses on his list can't figure out who's on the whitelists of
all of his recipients. Thus, the best the spammer can do is use addresses
that are totally unknown. The one exception to this would be a stolen
distribution list of an email newsletter, in which case that spammer could
forge the publisher's address. As long as filters don't implicitly trust
unknown addresses, this forgery doesn't get any more spam through.

Accountability is a much thornier issue. Technical solutions are attractive,
but they require widespread buy-in before one can start rejecting messages
that don't have a sender to hold accountable. On the other hand, a legal
approach could be more powerful than we think. If the owner of an IP address
were held responsible for mail transmitted from that address, there would be
specific motivation for everyone to do their part towards security.
Businesses would have a quantifiable legal liability to compare to the cost
of locking down their networks, and ISPs would have a reason to secure their
customers' computers. My biggest misgiving is that this would be a strong
push in the 'filter port 25' direction for ISPs.

--
Philip Miller

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 24 Dec 2003 15:34:56 -0500

> 1. Filtering by sender's address is hard when someone could forge a friend's

  Which is where accountability comes in.

> 2. One can't hold the victim of the forgery accountable for the junk

  Why not?  If they haven't done anything to prevent the (ab)use of
their name, how can the recipient tell if a message is real, or
abusive?

  If they have made public statements about accountability, then they
can prevent forgery by allowing the recipient to verify that
accountability.

  e.g. You can't rent a car unless you show identification.  It's not
a government conspiracy, it's so that the rental agency can make you
pay, if you wrap the car around a tree.

> that don't have a sender to hold accountable.

  Exactly.  The single largest problem with LMAP is the sheer number
of people who won't be using it.

> If the owner of an IP address were held responsible for mail
> transmitted from that address, there would be specific motivation
> for everyone to do their part towards security.

  In many jurisdictions, communications providers are indemnified for
any illegal activities by their customers.

  Alan DeKok.

---

From: Walter Dnes <[email-masked]>
Date: Wed, 24 Dec 2003 22:25:24 -0500

On Wed, Dec 24, 2003 at 03:34:56PM -0500, Alan DeKok wrote
> their name, how can the recipient tell if a message is real, or

  A spammer sends out a viagra spam "From: "Alan DeKok" <[email-masked]>".
How are the 20 million strangers it's addressed to going to *REJECT* it?
At these volumes, merely accepting the email and storing it in
recipients' "spam folders" will cause smaller ISPs to run out of
mailspool space.  What actions can *YOU* take that would allow
verification/authentication of the "From:" during the SMTP transaction ?

> any illegal activities by their customers.

  Maybe the responsibility should be placed on the person/company
nominally in control of the sending machine.  I.e. the owner of a
compromised home machine that is spewing out this garbage, or the renter
of compromised colo machine who has put a copy of "Matt's Monstrosity"
in his CGI directory.

-- 
Walter Dnes <[email-masked]>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did

---

From: Matthew Elvey <[email-masked]>
Date: Thu, 25 Dec 2003 16:00:10 -0800

>>  Which is where accountability comes in.
Walt: I think Alan is implicitly referring to the LMAP technology, which 
WILL allow the victim to prevent abuse of their name.
Of course, it doesn't work IRL yet, and I can see how you wouldn't 
realise he was referring to it. 
Flamewar quenched, I hope.  Chill, guys.

>of compromised colo machine who has put a copy of "Matt's Monstrosity"
Most blacklists and complaints to abuse desks tend to cause the ISPs in 
control to accept responsibility, but they're far from perfect.
Laws sometimes do require them to accept responsibility.  IIRC, AOL 
successfully sued a spammers ISP where the ISP itself really was a front 
for the spammer, but I'm getting OT.

---

From: Walter Dnes <[email-masked]>
Date: Fri, 26 Dec 2003 19:10:30 -0500

On Thu, Dec 25, 2003 at 04:00:10PM -0800, Matthew Elvey wrote

> Flamewar quenched, I hope.  Chill, guys.

  I apologize if I came on too strong.  I was trying to say that Alan
should not be held responsible for the misdeeds of others.  The ultimate
responsibility lies with the spammer, and contributory negligence may be
attributed to owners of compromised machines.

  The point I was trying to make was that SMTP allows almost any text
(excepting .\n\n) in the raw DATA: body.  The DATA: body includes the
"From:" header.  Most MUAs don't know about envelope-sender, and many
ISPs omit envelope-sender in the email as delivered to the end-user's
POP account.  The only thing that the recipient can know for certain
(assuming they can parse headers) is the final external IP address that
handed the email to their ISP.

---

From: "Alan DeKok" <[email-masked]>
Date: Sun, 28 Dec 2003 18:30:46 -0500

Walter Dnes <[email-masked]> wrote:
> I was trying to say that Alan should not be held responsible for the
> misdeeds of others.

  When someone steals my credit card information, I'm held responsible
until I can demonstrate it wasn't me.  If a particular store has a
large number of fraudulent transactions, then the credit card company
can impose additional restrictions on them, or take away their card
access entirely.

  No such system of accountability exists in SMTP.  Any such system we
create will be forever limited due to the large numbers of people who
refuse to accept such accountability.

> handed the email to their ISP.

  Which is why some of the proposals involve audit trails.  Hop by hop
authentication/accountability of SMTP messages is very problematic.

  Alan DeKok.

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 29 Dec 2003 15:01:45 -0500

[Subject changed as per posting guidelines, was "Re: Forgery in SMTP
(was [Asrg] [1] Why SPAM is worse in SMTP than in other protocols)". Mod.]

> verification/authentication of the "From:" during the SMTP transaction ?

This is where something like DK comes in. As it is now, we have two sets
of proposals - one addressing the SMTP envelope (LMAP), and the second,
like DK and various PKI schemes (Lumos, TEOS, etc.) address the actual
body of the message. Both can be complementary to each other.

Yakov

-------