Subject: Re: Allowing MTAs to split messages to different recipients
From: [email-masked]
To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Mon, 29 Jan 2001 08:08:25 -0800 (PST)
List-Id: <ietf-822.imc.org>

> when it became apparent that open relays were being abused by spammers,
> we took steps to limit the ability of spammers to use cs.utk.edu in this
> way.  in effect, we limited the number of non-local recipients to which
> any one IP address could send in any 24 hour period.  we did this because
> we had legitimate users who needed to send mail from random locations
> in the Internet without having to reconfigure their user agents each time.

> these measures were in fact effective - which is not to say that we
> relayed no spam at all, but the number of messages relayed was limited
> to a few in any one day...and yes, we monitored the number of messages
> blocked to see that this was the case.   our goal was to make it easier
> to send the spam directly than through us, and we succeeded.

> however, multiple blacklists insisted that we were running an open relay,
> and a number of sites believed them and used those blacklists as an excuse
> to block legitimate mail.  eventually we were directed by higher ups
> (who had no appreciation of the technical issues) to close our relay
> entirely, thus impairing our legitimate users.

A not uncommon story, unfortunately. There are all sorts of ways to block spam
relay effectively but blacklists are a crude tool at best for assessing this
level of effectiveness.

Another common case is that of setups where spam is blocked but not immediately
during the SMTP dialogue. Some blacklists only check as far as the RCPT TO
being successful, and incorrectly believe such sites are open to relay.

Yet another potentially abusive case is blacklisting because you're on an
address assumed to be associated with dialup users.

Another common case is where it took one or even no incident to get on a
blacklist, but even after the "problem" was fixed it took a week or more to get
off.

These things can get totally out of hand. One time I received a threatening
note saying I was going to be blacklisted not because I was an open relay -- I
wasn't -- but because I was listed as providing secondary name service for a
domain which contained one system that was acting as an open relay. I responded
explaining how important geographically distributed secondaries are to the
proper functioning of the Internet and how little this had to do with email.
The response in turn was that I should be more careful about who I chose to
provide secondary services for. (The domain with the open relay -- which of
course was quickly fixed -- belonged to the Oklahoma Regents of Higher
Education -- a real hotbed of intentionally open relays, I'm sure.)

> this is why I term the blacklists as a distributed denial of service
> attack based on disinformation - because it's exactly what they are.

Unfortunately I've seen this happen in many other cases -- too many cases to
ignore.

> > > In this case the attackers were naive
> > > about the likely good that it would do and about the harm that would
> > > result.

> > Experince says they were naive only insofar as they underestimated the
> > good, and overestimated the bad effects.

> My experience says exactly the opposite.

So does mine. Admittedly my experience is biased towards the cases where
blacklists were a problem rather than a solution to anything, but to imply that
the harm done is always minimal just isn't right. The situation, as usual, is
more complex than that.

				Ned

From: Keith Moore <[email-masked]>
To: [email-masked] (Kai Henningsen)
cc: [email-masked]
Subject: Re: Allowing MTAs to split messages to different recipients 
Date: Sun, 28 Jan 2001 19:26:48 -0500
Sender: [email-masked]

> > were mounting a distributed denial-of-service attack, using
> > propaganda and disinformation to entice gullible MTA administrators
> > into filtering using their criteria.
> 
> You certainly won't convince me by insulting me.
> 
> Then again, the fact that cs.utk.edu didn't manage to do *anything* about  
> being a wide open relay for *months* is in itself an appalling display.

cs.utk.edu was, like most other machines that had been around awhile,
a wide-open relay for several years, dating back to the first cs.utk.edu
machine.

when it became apparent that open relays were being abused by spammers, 
we took steps to limit the ability of spammers to use cs.utk.edu in this
way.  in effect, we limited the number of non-local recipients to which
any one IP address could send in any 24 hour period.  we did this because
we had legitimate users who needed to send mail from random locations
in the Internet without having to reconfigure their user agents each time.

these measures were in fact effective - which is not to say that we
relayed no spam at all, but the number of messages relayed was limited
to a few in any one day...and yes, we monitored the number of messages
blocked to see that this was the case.   our goal was to make it easier 
to send the spam directly than through us, and we succeeded.

however, multiple blacklists insisted that we were running an open relay,
and a number of sites believed them and used those blacklists as an excuse
to block legitimate mail.  eventually we were directed by higher ups
(who had no appreciation of the technical issues) to close our relay
entirely, thus impairing our legitimate users.

this is why I term the blacklists as a distributed denial of service
attack based on disinformation - because it's exactly what they are.

> But it is, of course, a long inhonourable tradition to shoot the  
> messenger.

if the messenger is lying, perhaps he deserves to be shot...or at least
hung by his thumbs.

> And the statistics certainly draw a pretty clear picture. The amount of  
> spam I receive that gets filtered out via blacklists is incredibly huge.

how much lossage of other people's legitimate mail is an acceptable
amount for an attacker to cause?

> >   In this case the attackers were naive
> > about the likely good that it would do and about the harm that would
> > result.
> 
> Experince says they were naive only insofar as they underestimated the  
> good, and overestimated the bad effects.

My experience says exactly the opposite.    

Keith

Date: 26 Jan 2001 20:56:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: Allowing MTAs to split messages to different recipients
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Keith Moore)  wrote on 15.01.01 in <[email-masked]>:

> To my way of thinking, the blacklists were indeed abusive.  They

ORBS was (possibly still is - I don't know), for reasons I don't want to  
go into here because I've done so often enough in other places in the  
past. The MAPS stuff, OTOH, doesn't seem to be abusive in any way, shape,  
or form.

Unless you want to spam, that is.

> were mounting a distributed denial-of-service attack, using
> propaganda and disinformation to entice gullible MTA administrators
> into filtering using their criteria.

You certainly won't convince me by insulting me.

Then again, the fact that cs.utk.edu didn't manage to do *anything* about  
being a wide open relay for *months* is in itself an appalling display.

But it is, of course, a long inhonourable tradition to shoot the  
messenger.

And the statistics certainly draw a pretty clear picture. The amount of  
spam I receive that gets filtered out via blacklists is incredibly huge.

Since MTAs I control do mark, but not throw away, mail from blacklisted  
servers, I have a pretty good idea of how much spam there is, and how much  
non-spam. It's a case of no contest.

>   In this case the attackers were naive
> about the likely good that it would do and about the harm that would
> result.

Experince says they were naive only insofar as they underestimated the  
good, and overestimated the bad effects.

MfG Kai

Date: 26 Jan 2001 20:45:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: Statistics of "intelligence" in e-mail spams
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Keith Moore)  wrote on 22.01.01 in <[email-masked]>:

> > My statistics thus supports the idea that spammers are getting
> > more intelligent.
>
> or at least, the folks who are writing spam software are getting
> more intelligent.

Or perhaps more precisely, the more "intelligent" spam tools gain  
marketshare.

MfG Kai

Date: 26 Jan 2001 20:15:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: WG: Limitation in bcc-field of emails?
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Jacob Palme)  wrote on 23.01.01 in <p05010407b6938a14a50e@[130.237.150.141]>:

> I am not sure if this is really correct, according to RFC822
> each Bcc recipient should see its own name (and possibly also
> other Bcc recipients) in a "Bcc" header in the mail.

That is *not* what the standard says.

> Below is the text in RFC822 on the Bcc field, and which
> explains the procedure which many mailers do not adhere to:
>
>       4.5.3.  BCC / RESENT-BCC
>
>          This field contains the identity of additional  recipients  of
>          the  message.   The contents of this field are not included in
>          copies of the message sent to the primary and secondary  reci-
>          pients.   Some  systems  may choose to include the text of the
>          "Bcc" field only in the author(s)'s  copy,  while  others  may
>          also include it in the text sent to all those indicated in the
>          "Bcc" list.

That is, either send the original Bcc field to only the Bcc recipients, or  
else do not send it to anyone. Which captures the two most common ways of  
implementing it.

> The new msgfmt standard, which soon will replace RFC822,
> accepts the existing practice by allowing it as one new
> way of handling the "Bcc" header. Below is the text in
> the new msgfmt standard:
>
>      The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
>      addresses of recipients of the message whose addresses are not to be
>      revealed to other recipients of the message. There are three ways in
>      which the "Bcc:" field is used. In the first case, when a message
>      containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
>      removed even though all of the recipients (including those specified in
>      the "Bcc:" field) are sent a copy of the message. In the second case,
>      recipients specified in the "To:" and "Cc:" lines each are sent a copy
>      of the message with the "Bcc:" line removed as above, but the
> recipients      on the "Bcc:" line get a separate copy of the message
> containing a      "Bcc:" line. (When there are multiple recipient addresses
> in the "Bcc:"      field, some implementations actually send a separate copy
> of the message      to each recipient with a "Bcc:" containing only the
> address of that      particular recipient.) Finally, since a "Bcc:" field
> may contain no      addresses, a "Bcc:" field can be sent without any
> addresses indicating      to the recipients that blind copies were sent to
> someone. Which method      to use with "Bcc:" fields is implementation
> dependent, but refer to the      "Security Considerations" section of this
> document for a discussion of      each.

What it does allow as a new option is the one you erroneously claimed RFC  
822 asked for, that is, construct different Bcc headers for each Bcc  
recipient.

MfG Kai

From: "Gwinn, Allen" <[email-masked]>
To: [email-masked]
Subject: RE: Back-queries?
Date: Wed, 24 Jan 2001 09:11:33 -0600
Sender: [email-masked]

This approach certainly isn't perfect :)

-----Original Message-----
From: Harald Alvestrand [mailto:[email-masked]]
Sent: Tuesday, January 23, 2001 4:58 PM
To: Gwinn, Allen; [email-masked]
Subject: Back-queries?

At 09:31 23/01/2001 -0600, Gwinn, Allen wrote:
>This approach certainly isn't perfect.  But simply opening a connection to
>the sending host and checking RCPT TO:
<[email-masked]>,
>looking for a 250 OK message before rejecting, then failing safe (i.e.
>accepting anything where you can't connect to the host) might tend to slow
>down a large hunk of spam.

hmm....I don't quite get how this would work out.
Let's consider a legitimate case: x@a sending mail to y@b

A->B: MAIL FROM x@a
B: (let's check if this is legit)
B->A: MAIL FROM legit-checker@b (intending to send RCPT TO x@a)
A: (let's check this)
A->B: MAIL FROM .......

it would definitely slow down things, yes.

Using null MAIL FROM when checking is one option.........if everyone allows 
that. But then this is an open hole.

(I recently heard that one guiding principle of the Internet was the 
question "what if EVERYONE did that?"....)

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

Date: Tue, 23 Jan 2001 19:13:43 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Back-queries?
Sender: [email-masked]

At 9:13 PM -0500 1/23/01, Keith Moore wrote:
>I guess the idea isn't to check whether the sending MTA will accept
>mail for the from address, but to check whether the sending MTA is
>an open relay.  The problem with this approach is that you can't
>tell whether an MTA is an open relay by looking at the response to
>RCPT - even a closed relay might return 2xx in response to RCPT
>and then bounce the message.

Such things happen often. See the recently-updated open relay survey 
at <http://www.imc.org/ube-relay.html>.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Keith Moore <[email-masked]>
To: Harald Alvestrand <[email-masked]>
cc: "Gwinn, Allen" <[email-masked]>, [email-masked]
Subject: Re: Back-queries? 
Date: Tue, 23 Jan 2001 21:13:43 -0500
Sender: [email-masked]

I guess the idea isn't to check whether the sending MTA will accept
mail for the from address, but to check whether the sending MTA is
an open relay.  The problem with this approach is that you can't
tell whether an MTA is an open relay by looking at the response to
RCPT - even a closed relay might return 2xx in response to RCPT 
and then bounce the message.

Keith

From: [email-masked]
Date: Tue, 23 Jan 2001 17:02:17 -0800 (PST)
Subject: Re: Statistics of "intelligence" in e-mail spams
To: Keith Moore <[email-masked]>
Cc: "Gwinn, Allen" <[email-masked]>, "'James M Galvin'" <[email-masked]>, Jacob Palme <[email-masked]>, [email-masked]
Sender: [email-masked]

> > One approach that I've thought casually revolves around a feature in
> > Sendmail that would open an SMTP connection back to the sending host
> > (assuming the sender had smtp services) and test it for relaying mail back
> > to you.  You could then accept or reject mail from that host based on the
> > finding.

> won't work.  lots of sites have separate outgoing and incoming MTAs, and
> nothing says that a 'sending host' even has to listen for inbound SMTP
> connections.

In fact for really huge email setups this is the rule, not the exception.

> admittedly, lots of other ideas for filtering spam - some that people
> actually implement, like filtering out source addresses that correspond
> to dialup lines - are no better.

I agree that this sort of filtering is wrong. However, in the overall
scheme of things it doesn't break things nearly as badly as what's proposed
above.

				Ned

Date: Tue, 23 Jan 2001 23:57:50 +0100
To: "Gwinn, Allen" <[email-masked]>, [email-masked]
From: Harald Alvestrand <[email-masked]>
Subject: Back-queries?
Sender: [email-masked]

At 09:31 23/01/2001 -0600, Gwinn, Allen wrote:
>This approach certainly isn't perfect.  But simply opening a connection to
>the sending host and checking RCPT TO: <[email-masked]>,
>looking for a 250 OK message before rejecting, then failing safe (i.e.
>accepting anything where you can't connect to the host) might tend to slow
>down a large hunk of spam.

hmm....I don't quite get how this would work out.
Let's consider a legitimate case: x@a sending mail to y@b

A->B: MAIL FROM x@a
B: (let's check if this is legit)
B->A: MAIL FROM legit-checker@b (intending to send RCPT TO x@a)
A: (let's check this)
A->B: MAIL FROM .......

it would definitely slow down things, yes.

Using null MAIL FROM when checking is one option.........if everyone allows 
that. But then this is an open hole.

(I recently heard that one guiding principle of the Internet was the 
question "what if EVERYONE did that?"....)

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

Date: Tue, 23 Jan 2001 20:30:55 +0100
To: "[email-masked]'" <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: WG: Limitation in bcc-field of emails?
Cc: "Hauss, Volker" <[email-masked]>
Sender: [email-masked]

At 11.56 -0500 01-01-23, Keith Moore wrote:
>  > I read the RFC 822 very carefully but I was not able to read 
>something about
>>  a limitation in the BCC Field. Is there such a thing as a maximum number of
>>  characters that can be written in the BCC field?
>
>no.  and since Bcc processing is done by the submitter's user agent
>(or in some cases the submitter's MTA acting on behalf of the user agent),
>length of Bcc fields matters even less than length of other fields.

Most mailers seem to remove "Bcc" fields from a message before
sending it to the first MTA, or else the first MTA removes
this field. This means that most "Bcc" recipients will receive
messages without their name in any of the recipient fields
in the message header.

I am not sure if this is really correct, according to RFC822
each Bcc recipient should see its own name (and possibly also
other Bcc recipients) in a "Bcc" header in the mail.

The reason why most mailers handles this in this slightly
incorrect way is that they need only send one copy of the
message. If some or all Bcc recipients should have their
name in the header, at least two different messages have
to be sent, one with and one without Bcc recipients, and
preferably N+1 versions of the message if there was N
Bcc recipients, so that each Bcc recipients gets the
message with only him/herself in the Bcc header, and so
that the non-Bcc recipients do not see the Bcc recipients
at all.

This is rather complex processing, which most mailers
skip by just removing the Bcc recipients from the message
header before sending it, and only specifying the Bcc
recipients on the envelope.

---

Below is the text in RFC822 on the Bcc field, and which
explains the procedure which many mailers do not adhere to:

      4.5.3.  BCC / RESENT-BCC

         This field contains the identity of additional  recipients  of
         the  message.   The contents of this field are not included in
         copies of the message sent to the primary and secondary  reci-
         pients.   Some  systems  may choose to include the text of the
         "Bcc" field only in the author(s)'s  copy,  while  others  may
         also include it in the text sent to all those indicated in the
         "Bcc" list.

---

The new msgfmt standard, which soon will replace RFC822,
accepts the existing practice by allowing it as one new
way of handling the "Bcc" header. Below is the text in
the new msgfmt standard:

     The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
     addresses of recipients of the message whose addresses are not to be
     revealed to other recipients of the message. There are three ways in
     which the "Bcc:" field is used. In the first case, when a message
     containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
     removed even though all of the recipients (including those specified in
     the "Bcc:" field) are sent a copy of the message. In the second case,
     recipients specified in the "To:" and "Cc:" lines each are sent a copy
     of the message with the "Bcc:" line removed as above, but the recipients
     on the "Bcc:" line get a separate copy of the message containing a
     "Bcc:" line. (When there are multiple recipient addresses in the "Bcc:"
     field, some implementations actually send a separate copy of the message
     to each recipient with a "Bcc:" containing only the address of that
     particular recipient.) Finally, since a "Bcc:" field may contain no
     addresses, a "Bcc:" field can be sent without any addresses indicating
     to the recipients that blind copies were sent to someone. Which method
     to use with "Bcc:" fields is implementation dependent, but refer to the
     "Security Considerations" section of this document for a discussion of
     each.

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: "Gwinn, Allen" <[email-masked]>
To: [email-masked]
Subject: RE: Statistics of "intelligence" in e-mail spams 
Date: Tue, 23 Jan 2001 11:06:57 -0600
Sender: [email-masked]

Blocking port 25!  Now you're talking!  My life would be so much easier.  I
have a cutting-edge-of-techno-societal-evolution friend who has disabled his
email account opting to instruct people on how to send snail mail, drop by
his office or call him on the phone.  But that is getting off on a tangent!

I guess my point is that if a host opened a connection to you, regardless of
whether or not it is an MX, it might have sendmail or some smtpd running
that could be probed.  If your receiving MTA opened a connection back to it
and tested to see if the originating daemon would blindly accept email for
relay, then you might have a piece of useful information.

We get probed all the time from people attempting to relay through us.  It
is impossible to tell how many of these are spammers looking for an open
relay, but I would guess that the number is non-zero.  If we weren't
proactive, they might for instance find a department's Linux server (that
probably doesn't have an MX associated with it but thats beside the point).
That won't keep it from relaying mail.

If the department server was probed back, on an outgoing message by a
recipient host, the receiving machine might notice this and reject with
something like "550 Sorry, your sendmail daemon appears to be an open mail
relay. Please tell your administrators and we'll start accepting mail from
you again."  If port 25 on the originating host doesn't answer the
connection back, the receiving machine should fail safe and just accept the
message.

So the only time the receiving host rejects the message is when the sending
*host* appears to blindly accept mail for relay.

Naturally there are configuration issues, such as which hosts you want to
probe and which are exempt.  And you're right, you'd probably kill some
legit messages with friendly fire.  But people can always call you in your
office, right? :)

-----Original Message-----
From: Keith Moore [mailto:[email-masked]]
Sent: Tuesday, January 23, 2001 10:34 AM
To: Gwinn, Allen
Cc: [email-masked]
Subject: Re: Statistics of "intelligence" in e-mail spams 

> This approach certainly isn't perfect.  But simply opening a connection to
> the sending host and checking RCPT TO:
<[email-masked]>,
> looking for a 250 OK message before rejecting, then failing safe (i.e.
> accepting anything where you can't connect to the host) might tend to slow
> down a large hunk of spam.

Then blocking incoming traffic to port 25 would be even more effective.

It's simply incorrect to assume that the host that is sending you mail
is an authoritative MX for the domain that is sending you mail.  If you
do this you will be causing a significant number of delivery failures
for legitimate mail.

Keith

From: Keith Moore <[email-masked]>
To: "Hauss, Volker" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: WG: Limitation in bcc-field of emails? 
Date: Tue, 23 Jan 2001 11:56:42 -0500
Sender: [email-masked]

> I read the RFC 822 very carefully but I was not able to read something about
> a limitation in the BCC Field. Is there such a thing as a maximum number of
> characters that can be written in the BCC field? 

no.  and since Bcc processing is done by the submitter's user agent
(or in some cases the submitter's MTA acting on behalf of the user agent), 
length of Bcc fields matters even less than length of other fields.

> Is there a maximum limit of characters for email at all?

no.  there is a suggested maximum length per line (between CRLF pairs), 
but header fields can occupy more than one line.  SMTP servers can 
place a restriction on the size of incoming messages, but there are 
no inherent length restrictions on header fields or body parts.  

Keith

From: Keith Moore <[email-masked]>
To: "Gwinn, Allen" <[email-masked]>
cc: [email-masked]
Subject: Re: Statistics of "intelligence" in e-mail spams 
Date: Tue, 23 Jan 2001 11:33:35 -0500
Sender: [email-masked]

> This approach certainly isn't perfect.  But simply opening a connection to
> the sending host and checking RCPT TO: <[email-masked]>,
> looking for a 250 OK message before rejecting, then failing safe (i.e.
> accepting anything where you can't connect to the host) might tend to slow
> down a large hunk of spam.

Then blocking incoming traffic to port 25 would be even more effective.

It's simply incorrect to assume that the host that is sending you mail
is an authoritative MX for the domain that is sending you mail.  If you
do this you will be causing a significant number of delivery failures
for legitimate mail.

Keith

From: "Hauss, Volker" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: WG: Limitation in bcc-field of emails?
Date: Tue, 23 Jan 2001 17:14:43 +0100
Sender: [email-masked]

Hi,

I read the RFC 822 very carefully but I was not able to read something about
a limitation in the BCC Field. Is there such a thing as a maximum number of
characters that can be written in the BCC field? Is there a maximum limit of
characters for email at all?

Thanks for your time and cooperation
Volker Hauss

-----Ursprüngliche Nachricht-----
Von: Paul Hoffman / IMC [mailto:[email-masked]]
Gesendet: Dienstag, 23. Januar 2001 16:47
An: Hauss, Volker
Betreff: Re: Limitation in bcc-field of emails?

>Mr(s) Hoffman,
>
>I read the RFC 822 very carefully but I was not able to read something
about
>a limitation in the BCC Field. Is there such a thing as a maximum number of
>characters that can be written in the BCC field?
>Excuse me for bothering you but I could not find an email address more
>adequate than yours. It would be very kind if you forward this to someone
>who can help me if you do not know the answer to my question.

Your best bet is to take this to the [email-masked] mailing list. 
See <http://www.imc.org/ietf-822/> for information on the list.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Gwinn, Allen" <[email-masked]>
To: [email-masked]
Subject: RE: Statistics of "intelligence" in e-mail spams 
Date: Tue, 23 Jan 2001 09:31:34 -0600
Sender: [email-masked]

This approach certainly isn't perfect.  But simply opening a connection to
the sending host and checking RCPT TO: <[email-masked]>,
looking for a 250 OK message before rejecting, then failing safe (i.e.
accepting anything where you can't connect to the host) might tend to slow
down a large hunk of spam.  

-----Original Message-----
From: Keith Moore [mailto:[email-masked]]
Sent: Monday, January 22, 2001 3:56 PM
To: Gwinn, Allen
Cc: 'James M Galvin'; Jacob Palme; [email-masked]
Subject: Re: Statistics of "intelligence" in e-mail spams 

> One approach that I've thought casually revolves around a feature in
> Sendmail that would open an SMTP connection back to the sending host
> (assuming the sender had smtp services) and test it for relaying mail back
> to you.  You could then accept or reject mail from that host based on the
> finding. 

won't work.  lots of sites have separate outgoing and incoming MTAs, and
nothing says that a 'sending host' even has to listen for inbound SMTP
connections. 

admittedly, lots of other ideas for filtering spam - some that people
actually implement, like filtering out source addresses that correspond
to dialup lines - are no better.

Keith

Date: Tue, 23 Jan 2001 01:08:04 +0100
To: "Gwinn, Allen" <[email-masked]>
From: Harald Alvestrand <[email-masked]>
Subject: RE: Statistics of "intelligence" in e-mail spams
Cc: [email-masked]
Sender: [email-masked]

At 12:00 22/01/2001 -0600, Gwinn, Allen wrote:
>One approach that I've thought casually revolves around a feature in
>Sendmail that would open an SMTP connection back to the sending host
>(assuming the sender had smtp services) and test it for relaying mail back
>to you.  You could then accept or reject mail from that host based on the
>finding.  Not that I've thought about it in depth, but you could hash status
>for incoming mail hosts after probing them.  But this would encourage people
>to close host relays.

Some people do this now.
And sometimes, they bounce mail because of transient failures; DNS timeouts 
when looking up the sender's domain, for instance.
(Other times, they bounce mail because I forgot to configure the envelope 
sender as a deliverable address; I deserve that :-)

(The Linux Counter Project, http://counter.li.org/, is currently sending 
out mail to all participants who registered two years or more ago, to 
verify that they are still around, and still want to be listed. I learned a 
LOT about how to check for deliverable mails....)

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

Date: Tue, 23 Jan 2001 00:59:44 +0100
To: Jacob Palme <[email-masked]>, [email-masked]
From: Harald Alvestrand <[email-masked]>
Subject: Re: Stopping spam - is it possible?
Sender: [email-masked]

At 20:47 20/01/2001 +0100, Jacob Palme wrote:
>If the goal is limited to stop spammers from using other MTAs
>to multiply their messages, it would be enough to stop multiplication
>of external mail with more than, say 20 RCTP TO:s, possibly also
>noting if the same message is sent several times in 20-at-a-time
>chunks.

this would break large mailing lists where many recipients are on the same 
systems (such as many intra-company mailing lists).

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

From: Keith Moore <[email-masked]>
To: "Gwinn, Allen" <[email-masked]>
cc: "'James M Galvin'" <[email-masked]>, Jacob Palme <[email-masked]>, [email-masked]
Subject: Re: Statistics of "intelligence" in e-mail spams 
Date: Mon, 22 Jan 2001 16:56:22 -0500
Sender: [email-masked]

> One approach that I've thought casually revolves around a feature in
> Sendmail that would open an SMTP connection back to the sending host
> (assuming the sender had smtp services) and test it for relaying mail back
> to you.  You could then accept or reject mail from that host based on the
> finding. 

won't work.  lots of sites have separate outgoing and incoming MTAs, and
nothing says that a 'sending host' even has to listen for inbound SMTP
connections. 

admittedly, lots of other ideas for filtering spam - some that people
actually implement, like filtering out source addresses that correspond
to dialup lines - are no better.

Keith

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: [email-masked]
Subject: Re: Statistics of "intelligence" in e-mail spams 
Date: Mon, 22 Jan 2001 13:56:08 -0500
Sender: [email-masked]

> My statistics thus supports the idea that spammers are getting
> more intelligent.

or at least, the folks who are writing spam software are getting
more intelligent.

Keith

From: "Gwinn, Allen" <[email-masked]>
To: "'James M Galvin'" <[email-masked]>, Jacob Palme <[email-masked]>
Cc: [email-masked]
Subject: RE: Statistics of "intelligence" in e-mail spams
Date: Mon, 22 Jan 2001 12:00:42 -0600
Sender: [email-masked]

One approach that I've thought casually revolves around a feature in
Sendmail that would open an SMTP connection back to the sending host
(assuming the sender had smtp services) and test it for relaying mail back
to you.  You could then accept or reject mail from that host based on the
finding.  Not that I've thought about it in depth, but you could hash status
for incoming mail hosts after probing them.  But this would encourage people
to close host relays.

There are still things it won't address.  Among them are the spammers who
initiate their own SMTP sessions from things like ppp dialups.

Just some thoughts.

Allen

-----Original Message-----
From: James M Galvin [mailto:[email-masked]]
Sent: Monday, January 22, 2001 10:45 AM
To: Jacob Palme
Cc: [email-masked]
Subject: Re: Statistics of "intelligence" in e-mail spams

    Conclusion: Based on my statistics between two time periods
    whose average date was about one year, both these kinds
    of "intelligent" spamming had more than doubled its percentage
    of all spams.
    
    My statistics thus supports the idea that spammers are getting
    more intelligent.

Well, strictly speaking, I suppose I can accept that your data indicates
at least some intellectual improvement in spammers.  I agree with you to
the extent that you want to give credit to spammers just because they
can put your name or email address in the headers or body of the
message.

However, personally, I'm not impressed.  The concept of "mail merging"
existed in the paper world long before it was attempted with email, so
all the spammers have shown is a new application for an old principle,
which I don't consider particularly significant.

What I was really after when I spoke of the intelligence of spammers is
the mechanisms by which they execute delivery.  "Pure spammers" have
exactly one: find an open relay and exploit.  The problem is finding an
open relay is like "shooting fish in a barrel," and this is unlikely to
change in our lifetime.  Adding mail merging to this delivery mechanism
is like putting icing on a stale cake: it looks good and "feels" good on
the outside, but the inside is disgusting.

Beyond this point there is a lot of gray area regarding spam.  There's
some distance between pure spam and marketing using email, and each
person's threshold for what is spam will vary along that continuum.
Email marketing is certainly becoming "smarter" and if you consider that
spam then spammers will look smarter.  I don't.

Jim

Date: Mon, 22 Jan 2001 11:44:46 -0500 (EST)
From: James M Galvin <[email-masked]>
Subject: Re: Statistics of "intelligence" in e-mail spams
To: Jacob Palme <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

    Conclusion: Based on my statistics between two time periods
    whose average date was about one year, both these kinds
    of "intelligent" spamming had more than doubled its percentage
    of all spams.
    
    My statistics thus supports the idea that spammers are getting
    more intelligent.

Well, strictly speaking, I suppose I can accept that your data indicates
at least some intellectual improvement in spammers.  I agree with you to
the extent that you want to give credit to spammers just because they
can put your name or email address in the headers or body of the
message.

However, personally, I'm not impressed.  The concept of "mail merging"
existed in the paper world long before it was attempted with email, so
all the spammers have shown is a new application for an old principle,
which I don't consider particularly significant.

What I was really after when I spoke of the intelligence of spammers is
the mechanisms by which they execute delivery.  "Pure spammers" have
exactly one: find an open relay and exploit.  The problem is finding an
open relay is like "shooting fish in a barrel," and this is unlikely to
change in our lifetime.  Adding mail merging to this delivery mechanism
is like putting icing on a stale cake: it looks good and "feels" good on
the outside, but the inside is disgusting.

Beyond this point there is a lot of gray area regarding spam.  There's
some distance between pure spam and marketing using email, and each
person's threshold for what is spam will vary along that continuum.
Email marketing is certainly becoming "smarter" and if you consider that
spam then spammers will look smarter.  I don't.

Jim

Date: Mon, 22 Jan 2001 10:44:32 +0100
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Statistics of "intelligence" in e-mail spams
Sender: [email-masked]

--============_-1231964363==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 12.22 -0500 01-01-21, James M Galvin wrote:
>In fact, I would assert that spammers are not getting smarter at all and
>characterizing them as "finding other ways around" is giving them way
>too much credit.  The methods used by spammers haven't changed all that
>much in the recent past (say, a year or more).

To check this statement, I have counted the number of spams
containing different kinds of "intelligence" which I have
received since 1 january 1999. My statistics does thus not
show any increase in spammer intelligence before 1 january 1999.

Spam was defined as every message I did not want of a marketing
nature, thus it includes messages from companies to which I
have given my e-mail-address, like for example Amazon. So
probably some of this spam is my own fault, I should have
told the company that I did not want their messages. I also
included as spam any message in Japanese, since I was not
able to read them, some Japanese spammer(?) insists on
sending me mail, possibly because the initials of my
name is "jp" so they think I am Japanese! I have tried
asking them to stop without success.

I excluded spam to mailing lists which I moderate, and where
I stopped the spam, but not other spam which I received
through misuse of mailing lists.

Anyway, with these restrictions, here is my statistics:

                        1-jan-99 to 31-oct-00    1-nov-00 to 21-jan-01

Total no of spams       1000                     451

spams/day                  2.8                     5.6 

Percentage of spams
containing my e-mail
address in any
recipient field          22 %                     45 %

Percentage of spams       9 %                     20 %
containing my name
in the body of the
message (sometimes
hidden in non-
visible HTML code!)

Yes, the figure "1000" is no estimate, the total just happended
to become that even number!

Conclusion: Based on my statistics between two time periods
whose average date was about one year, both these kinds
of "intelligent" spamming had more than doubled its percentage
of all spams.

My statistics thus supports the idea that spammers are getting
more intelligent.

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/
--============_-1231964363==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>Statistics of &quot;intelligence&quot; in e-mail
spams</title></head><body>
<div>At 12.22 -0500 01-01-21, James M Galvin wrote:</div>
<blockquote type="cite" cite>In fact, I would assert that spammers are
not getting smarter at all and<br>
characterizing them as &quot;finding other ways around&quot; is giving
them way<br>
too much credit.&nbsp; The methods used by spammers haven't changed
all that</blockquote>
<blockquote type="cite" cite>much in the recent past (say, a year or
more).</blockquote>
<div><br></div>
<div>To check this statement, I have counted the number of spams</div>
<div>containing different kinds of &quot;intelligence&quot; which I
have</div>
<div>received since 1 january 1999. My statistics does thus not</div>
<div>show any increase in spammer intelligence before 1 january
1999.</div>
<div><br></div>
<div>Spam was defined as every message I did not want of a
marketing</div>
<div>nature, thus it includes messages from companies to which I</div>
<div>have given my e-mail-address, like for example Amazon. So</div>
<div>probably some of this spam is my own fault, I should have</div>
<div>told the company that I did not want their messages. I also</div>
<div>included as spam any message in Japanese, since I was not</div>
<div>able to read them, some Japanese spammer(?) insists on</div>
<div>sending me mail, possibly because the initials of my</div>
<div>name is &quot;jp&quot; so they think I am Japanese! I have
tried</div>
<div>asking them to stop without success.</div>
<div><br></div>
<div>I excluded spam to mailing lists which I moderate, and
where</div>
<div>I stopped the spam, but not other spam which I received</div>
<div>through misuse of mailing lists.</div>
<div><br></div>
<div>Anyway, with these restrictions, here is my statistics:</div>
<div><br></div>
<div><font
face="Courier"
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1-jan-99 to 31-oct-00&nbsp;&nbsp;&nbsp; 1-nov-00 to
21-jan-01</font></div>
<div><font face="Courier"><br></font></div>
<div><font face="Courier">Total no of
spams&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
451</font></div>
<div><font face="Courier"><br></font></div>
<div><font
face="Courier"
>spams/day&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2.8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
5.6&nbsp;</font></div>
<div><font face="Courier"><br></font></div>
<div><font face="Courier">Percentage of spams</font></div>
<div><font face="Courier">containing my e-mail</font></div>
<div><font face="Courier">address in any</font></div>
<div><font face="Courier">recipient
field&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 22
%&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 45
%</font></div>
<div><font face="Courier"><br></font></div>
<div><font face="Courier">Percentage of
spams&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 9
%&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 20
%</font></div>
<div><font face="Courier">containing my name</font></div>
<div><font face="Courier">in the body of the</font></div>
<div><font face="Courier">message (sometimes</font></div>
<div><font face="Courier">hidden in non-</font></div>
<div><font face="Courier">visible HTML code!)</font></div>
<div><br></div>
<div>Yes, the figure &quot;1000&quot; is no estimate, the total just
happended</div>
<div>to become that even number!</div>
<div><br></div>
<div>Conclusion: Based on my statistics between two time periods</div>
<div>whose average date was about one year, both these kinds</div>
<div>of &quot;intelligent&quot; spamming had more than doubled its
percentage</div>
<div>of all spams.</div>
<div><br></div>
<div>My statistics thus supports the idea that spammers are
getting</div>
<div>more intelligent.</div>
<div><br></div>
<div><br></div>

<div>-- <br>
Jacob Palme &lt;[email-masked]&gt; (Stockholm University and
KTH)<br>
for more info see URL: http://www.dsv.su.se/jpalme/</div>
</body>
</html>
--============_-1231964363==_ma============--

Date: Sun, 21 Jan 2001 12:22:27 -0500 (EST)
From: James M Galvin <[email-masked]>
Subject: Re: Stopping spam - is it possible?
To: Jacob Palme <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

    IETF had a BOF discussing spam some years ago, but as I
    remember all or most of what was said would not work simply
    because spammers can find other ways around them.

Depends on your problem space.  If your goal is to ameliorate spam from
the entire global Internet, you're right.  Given the current state of
the Internet email infrastructure and the current probability that it's
likely to change any time soon, spam is here to stay.

However, RFC 2635 has a lot of good advice for how to keep spam off
your system.  It is possible to almost eliminate spam from any one
server.  The "almost" is because spam is in the eye's of the beholder;
one man's spam is another man's lunch.

In fact, I would assert that spammers are not getting smarter at all and
characterizing them as "finding other ways around" is giving them way
too much credit.  The methods used by spammers haven't changed all that
much in the recent past (say, a year or more).  The problem is the email
infrastructure as a whole offers more opportunity than challenge to
spammers.  Sending spam is downright trivial and with the free tools
available you don't even have to understand it!

Jim

From: [email-masked]
Date: Sat, 20 Jan 2001 20:29:28 -0800 (PST)
Subject: Re: Stopping spam - is it possible?
To: Jacob Palme <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> At 10.42 -0700 01-01-19, [email-masked] wrote:
> > But this is beside the point. You claimed to have a better alternative and
> > I asked what it was. You haven't answered my question.

> If the goal is limited to stop spammers from using other MTAs
> to multiply their messages, it would be enough to stop multiplication
> of external mail with more than, say 20 RCTP TO:s,

Been there, done that, doesn't work. Often as not spam isn't sent this way.

> possibly also
> noting if the same message is sent several times in 20-at-a-time
> chunks.

The overhead of keeping these sorts of records is very high. And even if you're
willing to accept the overhead, it doesn't work when the messages are
customized.

> If the goal is to really effectively stop spamming in e-mail,
> this problem is very difficult. The cause of the difficulty
> is that whatever action taken to stop spammers, the spammers
> will find ways to circumwent it.

> IETF had a BOF discussing spam some years ago, but as I
> remember all or most of what was said would not work simply
> because spammers can find other ways around them.

The BOF led to the publication of RFC 2635.

> For example, relaying of foreign mail was not effective
> in stopping spam (even if it was effective in stopping certain
> kids of overloads of MTAs caused by spammers), because spammers
> found other ways.

Again, stopping spam was never the primary goal of relay blocking.

> Similarly, identification of many identical messages will
> probably not work, because spammers have started to personify
> their spams, including "Hello Jacob" in the text of spams
> sent to me. This will make it difficult to identify duplicate
> copies of spams.

Exactly. And you have now refuted your own assertion that relay blocking
isn't necessary.

> What might possibly work would be something similar to
> PICS servers - a database identifying spams. Like with PICS,
> there could be different scales, so that different people
> could have different opinions on what they want and do not
> want. However, because mail is so rapid, such a data base
> must be very rapidly updated, by many people (i.e. all
> ISOC members except those who misuse the data base) allowed
> to update the data base. And it must be able to stop messages,
> which have already arrived at your mailbox, maybe even have
> already been downloaded to your personal computer.

It's been tried. But the products I've seen that implemented this weren't
successful and are no longer available. Maybe there are some others
out there and maybe they will fare better, but I'm not optimistic.

				Ned

Date: Sat, 20 Jan 2001 20:47:54 +0100
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Stopping spam - is it possible?
Sender: [email-masked]

At 10.42 -0700 01-01-19, [email-masked] wrote:
>But this is beside the point. You claimed to have a better alternative and
>I asked what it was. You haven't answered my question.

If the goal is limited to stop spammers from using other MTAs
to multiply their messages, it would be enough to stop multiplication
of external mail with more than, say 20 RCTP TO:s, possibly also
noting if the same message is sent several times in 20-at-a-time
chunks.

If the goal is to really effectively stop spamming in e-mail,
this problem is very difficult. The cause of the difficulty
is that whatever action taken to stop spammers, the spammers
will find ways to circumwent it.

IETF had a BOF discussing spam some years ago, but as I
remember all or most of what was said would not work simply
because spammers can find other ways around them.

For example, relaying of foreign mail was not effective
in stopping spam (even if it was effective in stopping certain
kids of overloads of MTAs caused by spammers), because spammers
found other ways.

Similarly, identification of many identical messages will
probably not work, because spammers have started to personify
their spams, including "Hello Jacob" in the text of spams
sent to me. This will make it difficult to identify duplicate
copies of spams.

Threatening ISPs which allow spammers with expulsion from
the Internet might work, but is somewhat questionable
from a democratic viewpoint.

Also, the opinion on what is a spam can vary, there are some
messages which are in-between. For example, I receive lots
of mail with invitations to various conferences. I do not
regard them as spam, simply because I am interested in their
content, even though from an objective viewpoint they are
certain unsolicited marketing mail.

What might possibly work would be something similar to
PICS servers - a database identifying spams. Like with PICS,
there could be different scales, so that different people
could have different opinions on what they want and do not
want. However, because mail is so rapid, such a data base
must be very rapidly updated, by many people (i.e. all
ISOC members except those who misuse the data base) allowed
to update the data base. And it must be able to stop messages,
which have already arrived at your mailbox, maybe even have
already been downloaded to your personal computer.

It also requires a way of identifying variants of the
same message, which spammers create to circumwent this
kind of data base.

---

What I personally find most disgusting is actually not
spams sent to me, but spams sent to mailing lists which
I manage. My mailing-lists are moderated for messages
from non-members, so none of these spams will ever
reach the members of the list. But since there is
a small chance that non-members will write something
which should be accepted, I have to monitor all
those spams. The spammers gain nothing, since no one
except me sess the messages.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: [email-masked]
Date: Fri, 19 Jan 2001 10:42:49 -0700 (PDT)
Subject: Re: Allowing MTAs to split messages to different recipients
To: Jacob Palme <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > > Spamming could be counteracted more
> > > efficiently using other methods than this.

> > And these methods are what exactly? If there's something more effective than
> > open relay blocking I'd like to hear what it is.

> Relay blocking certainly is not effective. Spamming just increases
> every year.

Actually, it is effective in the sense that it makes spammers easier to track
down.

But this is beside the point. You claimed to have a better alternative and
I asked what it was. You haven't answered my question.

> Of course, you might claim that without relay
> blocking, spamming would have increased even more.

Quite likely, but who's to know? The point is that reasonable actions to
counteract spam relay have led to the loss of open relay functionality. You may
quibble about the details, but unless you're prepared to suggest an viable
alternative it isn't going to matter.

> Relay blocking was in reality not meant to counteract spamming,
> but to reduce the load of spammers taking over MTAs to forward
> their spams. Thus, it was not meant to make life more bearable
> to users, but to make life more bearable to MTA owners. But
> those who introduced relay blocking wrongly claimed that it stop
> spamming.

Nonsense. Try being a user on a system whose management doesn't care and that's
overwhelmed by spam as a result. It isn't a pleasant experience, let me tell
you -- dozens of attempts needed to send mail, incoming messages delayed for
hours or days, etc.

MTA owners provide a service. In most cases they care very little about the
details of that service as long as it works. But spam relay can and does
compromise that service, that impacts users, and that makes it a problem for
users. This isn't a hack performed by lazy MTA owners at the expense of their
users, it is an essential configuration detail MTA owners perform that directly
benefits their users far more than it harms them.

				Ned

From: [email-masked]
Date: Fri, 19 Jan 2001 10:36:09 -0700 (PDT)
Subject: Re: Allowing MTAs to split messages to different recipients
To: Jacob Palme <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> SMTP AUTH or SMTP-after-POP seems like a possible solution to
> the needs of travelling mail users. Are there standards on
> this?

Yes -- SASL and TLS are specified and their use with SMTP is specified.

> Why have they not been accepted?

They have been. Practically all modern clients support it and many
modern MTAs support it. And many sites have deployed it.

> Do they use simple
> passwords, or do they use crypthographic authorisation -
> such authorisation seems to have much difficulty getting
> accepted.

Both are possible and both are used. You'll see simple passwords,
simple passwords over TLS, cram-md5, digest-md5, and various other
schemes.

The primary impediment to their use is that some companies and ISPs simply
don't see any need to support travelling mail users. In my experience once they
believe the need is there getting the service in place is rarely difficult.

				Ned

From: Keith Moore <[email-masked]>
To: Harald Alvestrand <[email-masked]>
cc: Jacob Palme <[email-masked]>, [email-masked]
Subject: Re: Allowing MTAs to split messages to different recipients 
Date: Thu, 18 Jan 2001 10:15:28 -0500
Sender: [email-masked]

> use SSH to login to a machine at home, and to tunnel port 25 to there.
> Configure Eudora to send to "localhost:25".

too bad my palm III's ssh client doesn't support tunneling.
(I'm perfectly serious; this is what keeps me from using Eudora
on my palm - that and the lack of SMTP AUTH support)

Keith

Date: Thu, 18 Jan 2001 09:26:20 -0500
From: John C Klensin <[email-masked]>
Subject: Re: Allowing MTAs to split messages to different recipients
To: Jacob Palme <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

--On Thursday, 18 January, 2001 02:35 +0100 Jacob Palme
<[email-masked]> wrote:

> I guess what I should get is some simple MTA which I can
> run on my personal computer and which does this for me.
> It need not handle incoming mail, only outgoing mail.

Of course, if you do this, you will sooner or later discover the
importance of the "prevent MTA abuse" properties of relay
blocking. I recommend either Harald's model of an SSH tunnel or
SMTP authentication.

> SMTP AUTH or SMTP-after-POP seems like a possible solution to
> the needs of travelling mail users. Are there standards on
> this? Why have they not been accepted? 

There are for SMTP AUTH, and they have been (see RFC 2554).  I
use them every day.

> Do they use simple
> passwords, or do they use crypthographic authorisation -
> such authorisation seems to have much difficulty getting
> accepted.

Either way, although you may not find both in a given
client-server combination.  On the other hand, you need to only
find one pair with which you are satisfied.  I understand that
[even] MS Outlook Express supports the client side, although
there is an implementation error (relative to the standard) in
at least some versions.

    john

Date: Thu, 18 Jan 2001 11:43:29 +0100
To: Jacob Palme <[email-masked]>, [email-masked]
From: Harald Alvestrand <[email-masked]>
Subject: Re: Allowing MTAs to split messages to different recipients
Sender: [email-masked]

At 02:33 18/01/2001 +0100, Jacob Palme wrote:
>Relay blocking certainly is not effective. Spamming just increases
>every year. Of course, you might claim that without relay
>blocking, spamming would have increased even more.
>
>Relay blocking was in reality not meant to counteract spamming,
>but to reduce the load of spammers taking over MTAs to forward
>their spams. Thus, it was not meant to make life more bearable
>to users, but to make life more bearable to MTA owners. But
>those who introduced relay blocking wrongly claimed that it stop
>spamming.

Relay blocking is also effective against trace hiding.
If the spammer has to send mail from his own account, finding it becomes 
easier.

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

Date: Thu, 18 Jan 2001 11:41:54 +0100
To: Jacob Palme <[email-masked]>, [email-masked]
From: Harald Alvestrand <[email-masked]>
Subject: Re: Allowing MTAs to split messages to different recipients
Sender: [email-masked]

At 02:35 18/01/2001 +0100, Jacob Palme wrote:
>It is true that this is the main reason why I get so angry with
>this. Having to find the right acceptable SMTP relayer wherever
>I go is a pain. And having to send my messages one at a time
>directly to the recipient local MTA is a pain with Eudora,
>because Eudora is not able to this automatically. I do not
>know if other mail clients can do this. Earlier this week,
>I was in Bologna and sent my messages in this way, changing
>the receiving SMTP server manually between each message to
>the server indicated by the MX record of the recipient. It
>worked, but was not easy.
>
>I guess what I should get is some simple MTA which I can
>run on my personal computer and which does this for me.
>It need not handle incoming mail, only outgoing mail.

actually there is a far simpler solution that I will continue to use until 
I get SMTP AUTH on my infrastructure:

use SSH to login to a machine at home, and to tunnel port 25 to there.
Configure Eudora to send to "localhost:25".

End of problem.

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: [email-masked]
Subject: Re: Allowing MTAs to split messages to different recipients 
Date: Wed, 17 Jan 2001 22:22:35 -0500
Sender: [email-masked]

> Relay blocking certainly is not effective. Spamming just increases
> every year.

relay blocking doesn't stop spam from getting to recipients.
it does, however, lessen the load on MTAs that were being abused by spammers.

Keith

Date: Thu, 18 Jan 2001 02:35:46 +0100
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: Allowing MTAs to split messages to different recipients
Sender: [email-masked]

At 11.19 -0500 01-01-15, Keith Moore wrote:
>But from my point-of-view the principal damage that was done was
>to thwart the legitimate use of SMTP for submission of messages by mobile
>users to their "home" SMTP servers.  (and no, SMTP-after-POP doesn't
>work reliably, and SMTP AUTH isn't widely enough deployed even now)

It is true that this is the main reason why I get so angry with
this. Having to find the right acceptable SMTP relayer wherever
I go is a pain. And having to send my messages one at a time
directly to the recipient local MTA is a pain with Eudora,
because Eudora is not able to this automatically. I do not
know if other mail clients can do this. Earlier this week,
I was in Bologna and sent my messages in this way, changing
the receiving SMTP server manually between each message to
the server indicated by the MX record of the recipient. It
worked, but was not easy.

I guess what I should get is some simple MTA which I can
run on my personal computer and which does this for me.
It need not handle incoming mail, only outgoing mail.

SMTP AUTH or SMTP-after-POP seems like a possible solution to
the needs of travelling mail users. Are there standards on
this? Why have they not been accepted? Do they use simple
passwords, or do they use crypthographic authorisation -
such authorisation seems to have much difficulty getting
accepted.

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Thu, 18 Jan 2001 02:33:30 +0100
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: Allowing MTAs to split messages to different recipients
Sender: [email-masked]

At 08.15 -0700 01-01-15, [email-masked] wrote:
>  > I am working on a compendium for a course I give at my university.
>>  A controversial text from the compendium is quoted below. If you
>>  think that this is wrong, tell me.
>
>OK, I'll tell you: It's wrong on many points.

I sort of expected this reply, that is why I wrote my message
to get more opinions on this issue. I will rewrite the text
based on the valuable input you and others have given on
my flame.

At 08.15 -0700 01-01-15, [email-masked] wrote:
>  > Spamming could be counteracted more
>>  efficiently using other methods than this.
>
>And these methods are what exactly? If there's something more effective than
>open relay blocking I'd like to hear what it is.

Relay blocking certainly is not effective. Spamming just increases
every year. Of course, you might claim that without relay
blocking, spamming would have increased even more.

Relay blocking was in reality not meant to counteract spamming,
but to reduce the load of spammers taking over MTAs to forward
their spams. Thus, it was not meant to make life more bearable
to users, but to make life more bearable to MTA owners. But
those who introduced relay blocking wrongly claimed that it stop
spamming.

If relay blocking had been effective, it would be equally effective
if it did not stop smaller amounts of relaying, but only massive
amounts of relaying.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: [email-masked]
DATE: 16 Jan 01 6:44:42 PM
SUBJECT: RE; THANK YOU 
Sender: [email-masked]

Dear Friend and Partner, 

Think of all the things you could do if you had more free time and money wasn't an 
object

             What kind of car would you be driving? 

                     Where would you live? 

                           Where would you go on vacation? 

Now, for a limited time, 300+ money making and saving secrets can be yours for less 
than $10.00. 

Click here http://www.300moneysecrets.com/    and ORDER NOW!!!!!!!!!!!!!! 

Get information now, that could make you millions!!!! 

 ** REMOVE ** REMOVE ** REMOVE ** REMOVE ** REMOVE ** 

To be removed from our mailing list, please email [email-masked] All REMOVE requests AUTOMATICALLY honored upon receipt. PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed     from our mailing list as it will be impossible to take anyone off the list if the remove instruction can not be received.

Date: Tue, 16 Jan 2001 00:37:25 +0100
To: Jacob Palme <[email-masked]>, [email-masked]
From: Harald Alvestrand <[email-masked]>
Subject: Re: Allowing MTAs to split messages to different recipients
Sender: [email-masked]

At 10:27 14/01/2001 +0100, Jacob Palme wrote:
>I am working on a compendium for a course I give at my university.
>A controversial text from the compendium is quoted below. If you
>think that this is wrong, tell me.

If it is a course in the politics and psychology of self-regulation of the 
Internet, I think it entirely appropriate, if labelled with "IN THE OPINION 
OF THIS PROFESSOR", and with appropriate representation of alternate views 
given.
As formulated, none of these criteria are fulfilled.

If it is a course in the mechanics of email propagation, I find it 
inaccurate, inappropriate and irrelevant.

It all depends on the context.
--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

Date: 15 Jan 2001 21:24:51 -0000
Mail-Followup-To: [email-masked]
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: Allowing MTAs to split messages to different recipients
Sender: [email-masked]

Jacob Palme writes:
> The reason why this was abolished in the middle of the 1990-s was that
> spammers used this feature to get foreign MTAs to help them split mail
> to millions of recipients.

You have the timeline wrong. As far as I know, there was only one MTA
that turned off relaying by default before 1997. Sendmail didn't do that
until 1998. Open relays were still widespread in 1999.

---Dan

From: [email-masked]
Date: Mon, 15 Jan 2001 08:15:43 -0700 (PDT)
Subject: Re: Allowing MTAs to split messages to different recipients
To: Jacob Palme <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> I am working on a compendium for a course I give at my university.
> A controversial text from the compendium is quoted below. If you
> think that this is wrong, tell me.

OK, I'll tell you: It's wrong on many points.

> If a sender in Europe sends a message to two or more recipients in
> North America, only one copy might be copied across the expensive
> Atlantic cables as shown in the figure below:

> A problem with this, however, is that most MTAs are not willing to
> handle mail, unless either the recipient or the sender is local to
> the MTA.

Or unless the sender has appropriate credentials. These days locality isn't
sufficient, since many users roam and still want to be able to use the MTA at
their home site as a relay.

> Thus, the saving shown above requires an agreement with the
> MTA which splits the message after transport across the Atlantic.

Yes, but such agreements are easily accomodated by present-day infrastructure
(SASL and TLS). Nevertheless, AFAIK there are relatively few such setups.
Possible reasons why this is so include:

(1) This practice, while wasteful, is small beer compared to other uses of
    these links.

(2) The people for whom it is a problem aren't the same as the people who
    are able to set up such arrangements.

(3) People are ignorant of just how easy this problem is to solve. (It would
    only take a few minutes to configure the software I work on to support
    this sort of relay, for example, and I have no reason to believe it is any
    harder in other software.)

> This was not always so. In the beginning of the 1990-s, most MTAs
> were willing to forward mail for any recipient. The reason why this
> was abolished in the middle of the 1990-s was that spammers used this
> feature to get foreign MTAs to help them split mail to millions of
> recipients.

Yes, and this is why the relaying got shut down and continues to be shut down.
Try digging yourself out of having your system used for a massive spam relay
sometime -- once you've done so cries about how this leads to such inefficiency
on high-cost links somehow fail to impress.

> Some so-called experts claimed that spamming could be
> stopped by forbidding splitting of mail by other than the MTA of the
> sender or the recipient. They enforced their view by implementing a
> program which scanned all MTAs everywhere, checking that they did not
> allow foreign splitting, and sending angry letters to non-conforming
> MTA administrators (postmasters) threatening to stop receiving mail
> from them unless they stopped splitting. This is an interesting
> example of how the Internet is regulated in dubious ways by
> pseudo-police-authorities.

While I have little love for the scan-and-ban crowd, you're giving them too
much credit here.

The reason open relays were shut down is because a significant number of them
were exploited to the point where the users of those systems were unable to get
useful work done. Most administrators have no choice but to block open relay,
regardless of its utility. And this situation hasn't changed -- try opening a
system whose name is widely known up to relay sometime and you'll see.

The only reason that the scan-and-ban crowd has been at all successful is
because most systems already blocked open relay and they were able to go after
the few remaining ones that didn't. Had the situation been one where the common
practice was to allow open relay they would have gotten nowhere: Subscribing to
their "don't accept mail from systems that permit open relay" policy would have
resulted in too much mail being blocked to be useful.

Indeed, it isn't entirely clear to me that the real weapon in the scan-and-ban
crowd's arsenal is the number of sites subscribing to their black list. I've
seen several cases where a site that was open to relay was blacklisted and then
almost immediately was used by a spammer for the first time. It is undeniable
that the list of open relays these folks compile could be quite useful to
spammers, and while I presume they take steps to try and prevent their data
from being used by spammers, I find the timing above to be more than a little
suspicious.

> Spamming could be counteracted more
> efficiently using other methods than this.

And these methods are what exactly? If there's something more effective than
open relay blocking I'd like to hear what it is.

				Ned

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: [email-masked]
Subject: Re: Allowing MTAs to split messages to different recipients 
Date: Mon, 15 Jan 2001 11:19:14 -0500
Sender: [email-masked]

> If a sender in Europe sends a message to two or more recipients in 
> North America, only one copy might be copied across the expensive 
> Atlantic cables as shown in the figure below:
> 
> A problem with this, however, is that most MTAs are not willing to
> handle mail, unless either the recipient or the sender is local to
> the MTA. 

There are more fundamental problems than this, namely, that the
sending MTA has no idea where its recipients are located with
respect to expensive links, so it has no basis with which to optimize. 

> Thus, the saving shown above requires an agreement with the
> MTA which splits the message after transport across the Atlantic.
> This was not always so. 

True, but probably not relevant.

> In the beginning of the 1990-s, most MTAs
> were willing to forward mail for any recipient. The reason why this
> was abolished in the middle of the 1990-s was that spammers used this
> feature to get foreign MTAs to help them split mail to millions of
> recipients. Some so-called experts claimed that spamming could be
> stopped by forbidding splitting of mail by other than the MTA of the
> sender or the recipient. They enforced their view by implementing a
> program which scanned all MTAs everywhere, checking that they did not
> allow foreign splitting, and sending angry letters to non-conforming
> MTA administrators (postmasters) threatening to stop receiving mail
> from them unless they stopped splitting. This is an interesting
> example of how the Internet is regulated in dubious ways by
> pseudo-police-authorities. Spamming could be counteracted more
> efficiently using other methods than this.

While your history is reasonably accurate, I think you're mixing
two fairly unrelated things. And I don't think you've supported 
your last statement.  

In general it doesn't seem reasonable to expect an MTA to handle 
inbound traffic for other recipients than those for whom it's agreed 
to exchange mail.  Regardless of whether or not the traffic is spam, 
it's still taking up their resources.  To expect a remote MTA to
forward third party traffic, in the absence of explicit agreement
and permission to do so, strikes me as naive.  Even though at one
time it was a common practice, it's never been required by the 
SMTP protocol, and it was therefore never safe from the point-of-view
of application design to depend on this happening.  On the other
hand, if you get explicit agreement from remote MTAs to forward
your list mail (with either authentication or narrowly tailored
filtering for your list traffic), you can still do this.

To my way of thinking, the blacklists were indeed abusive.  They 
were mounting a distributed denial-of-service attack, using
propaganda and disinformation to entice gullible MTA administrators
into filtering using their criteria.  To me this is little better
than putting a virus in an executable attachment of an email message 
and labelling it in such a way that the recipient is likely to click
on it.  Perhaps they had good intentions, but some virus writers have
good intentions also.  In this case the attackers were naive 
about the likely good that it would do and about the harm that would
result.  But from my point-of-view the principal damage that was done was 
to thwart the legitimate use of SMTP for submission of messages by mobile 
users to their "home" SMTP servers.  (and no, SMTP-after-POP doesn't 
work reliably, and SMTP AUTH isn't widely enough deployed even now)

Keith

From: [email-masked]
Date: Mon, 15 Jan 2001 10:42:02 -0500 (EST)
To: Jacob Palme <[email-masked]>
cc: [email-masked]
Subject: Re: Allowing MTAs to split messages to different recipients
Organization: Flamingo Internet Navigators
Sender: [email-masked]

This is from a text?  It sounds more like a spammers diatribe.  The spin
to the whole piece is way overdone even if you disagree with what various
people did.  Mentioning the word "relay" and defining it would seem to be
a good idea.  Providing some links to the well-reasoned opposing opinions
would help add some balance.  But the tone of the whole thing is way off.

-- 
</chris>

Those who cannot remember the past are doomed to buy Microsoft products.

Date: Sun, 14 Jan 2001 10:27:36 +0100
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Allowing MTAs to split messages to different recipients
Sender: [email-masked]

--============_-1232576516==_mr============
Content-Type: multipart/alternative; boundary="============_-1232576516==_ma============"

--============_-1232576516==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

I am working on a compendium for a course I give at my university.
A controversial text from the compendium is quoted below. If you
think that this is wrong, tell me.

--- --- start quote --- ---

If a sender in Europe sends a message to two or more recipients in 
North America, only one copy might be copied across the expensive 
Atlantic cables as shown in the figure below:

A problem with this, however, is that most MTAs are not willing to
handle mail, unless either the recipient or the sender is local to
the MTA. Thus, the saving shown above requires an agreement with the
MTA which splits the message after transport across the Atlantic.
This was not always so. In the beginning of the 1990-s, most MTAs
were willing to forward mail for any recipient. The reason why this
was abolished in the middle of the 1990-s was that spammers used this
feature to get foreign MTAs to help them split mail to millions of
recipients. Some so-called experts claimed that spamming could be
stopped by forbidding splitting of mail by other than the MTA of the
sender or the recipient. They enforced their view by implementing a
program which scanned all MTAs everywhere, checking that they did not
allow foreign splitting, and sending angry letters to non-conforming
MTA administrators (postmasters) threatening to stop receiving mail
from them unless they stopped splitting. This is an interesting
example of how the Internet is regulated in dubious ways by
pseudo-police-authorities. Spamming could be counteracted more
efficiently using other methods than this.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/
--============_-1232576516==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>Allowing MTAs to split messages to different
recipient</title></head><body>
<div>I am working on a compendium for a course I give at my
university.</div>
<div>A controversial text from the compendium is quoted below. If
you</div>
<div>think that this is wrong, tell me.<br>
<br>
--- --- start quote --- ---<br>
</div>
<div><font face="Times" size="+2">If a sender in Europe sends a
message to two or more recipients in North America, only one copy
might be copied across the expensive Atlantic cables as shown in the
figure below:</font></div>
<div><font face="Times" size="+2"><br></font></div>
<div><img src="cid:p05010400b6871d7c6799@[130.237.150.141].1.0"></div>
<div><font face="Times" size="+2"><br></font></div>
<div><font face="Times" size="+2">A problem with this, however, is
that most MTAs are not willing to<br>
handle mail, unless either the recipient or the sender is local to<br>
the MTA. Thus, the saving shown above requires an agreement with
the<br>
MTA which splits the message after transport across the Atlantic.<br>
This was not always so. In the beginning of the 1990-s, most MTAs<br>
were willing to forward mail for any recipient. The reason why
this<br>
was abolished in the middle of the 1990-s was that spammers used
this<br>
feature to get foreign MTAs to help them split mail to millions of<br>
recipients. Some so-called experts claimed that spamming could be<br>
stopped by forbidding splitting of mail by other than the MTA of
the<br>
sender or the recipient. They enforced their view by implementing
a<br>
program which scanned all MTAs everywhere, checking that they did
not<br>
allow foreign splitting, and sending angry letters to
non-conforming<br>
MTA administrators (postmasters) threatening to stop receiving
mail<br>
from them unless they stopped splitting. This is an interesting<br>
example of how the Internet is regulated in dubious ways by<br>
pseudo-police-authorities. Spamming could be counteracted more<br>
efficiently using other methods than this.</font></div>

<div>-- <br>
Jacob Palme &lt;[email-masked]&gt; (Stockholm University and
KTH)<br>
for more info see URL: http://www.dsv.su.se/jpalme/</div>
</body>
</html>
--============_-1232576516==_ma============--
--============_-1232576516==_mr============
Content-Id: <p05010400b6871d7c6799@[130.237.150.141].1.0>
Content-Type: image/gif; name="010114-mail-splitting-two.gif"
 ; x-mac-type="47494666"
 ; x-mac-creator="3842494D"
Content-Disposition: attachment; filename="010114-mail-splitting-two.gif"
Content-Transfer-Encoding: base64

--============_-1232576516==_mr============--