Subject: Re: Last Call: Anti-Spam Requirements on an SMTP MTA to BCP

From: Gunnar Lindberg <[email-masked]>
Date: Wed, 4 Mar 1998 08:11:27 +0100 (MET)

>Date: Tue,  3 Mar 1998 21:18:47 -0800 (PST)
>From: Randy Bush <[email-masked]>

>is it indeed current practice, or is it a specification of what
>we think
>should be practiced?

My time zone is "+0100 (MET)"; yours is "-0800 (PST)" i.e. 9h behind.
Maybe that's the difference :-).

	Gunnar

PS
    Then, it would be appreciated if you tried to give *your* view.
								    DS

---

From: Randy Bush <[email-masked]>
Date: Tue, 3 Mar 1998 23:15:38 -0800 (PST)

> Then, it would be appreciated if you tried to give *your* view.

i meant my question very literally.  is it current practice?  if so, and it
is the best of which we are aware, then it should be a BCP.  if not, ...

randy

---

From: Ned Freed <[email-masked]>
Date: Wed, 04 Mar 1998 00:55:13 -0800 (PST)

> is the best of which we are aware, then it should be a BCP.  if not, ...

Randy, I think you're missing the point of what this document specifies. This
document specifies a set of facilities MTAs should provide. And in this sense
the answer is yes, these are the facilities modern MTAs provide that have been
found to be of some use in combatting spam, and hence this document is a good
candidate for BCP.

However, this document is not a set of recommendations as to what specific
sorts of blocking policies should be implemented using these facilities.
Frankly, I doubt very much that we'd be able to reach consensus on what
policies are generally appropriate. This trick of avoiding specification of
specific policies is actually pretty clever IMHO.

I have argued (and will continue to to argue if need be) that this document
also needs to include information about what MUST NOT be done with these
facilities. I think this is also noncontroversial. But this still falls far
short of saying what SHOULD or MUST be done with them.

				Ned

---

From: Jacob Palme <[email-masked]>
Date: Wed, 4 Mar 1998 11:23:41 +0100

We started implementing anti-spam features which check the
correctness of the domains of senders of incoming messages a few
weeks ago. This did reduce the amount of spamming temporarily, but it
is growing again, obviously the spammers have found ways to work
around such measures. I believe these kind of anti-spam features are
tools for MTA-owners who do not want their MTAs misused, but they are
not, except for a short time, much help for end users who want to
avoid spams.

When considering a new anti-spam meausere, one should always consider
how easy it is for the spammers to work around it. Otherwise the
effect will be very limited.

In computer conferencing systems, we have had a good way of getting
rid of spams for many years. This is a method which could be named
"post-moderating". The traditional way of handling moderated
discussion groups is pre-moderating, every message must be approved
by the moderator before being sent out. Pre-moderating has many
disadvantages: Long delay times, need for a co-ordinated group of
moderators since all may not be available all the time.
Post-moderating means that one or more moderators can remove messages
after they have been sent. It has some similarity to the cancelbots
in Usenet news, except that only approved moderators are allowed to
use them. Approved moderators can be a few people, or many people, in
small closed groups where all trust each other, every member can be a
post-moderator.

Another way of detecting spams which might be efficient is to detect
if lots of people get similar or almost similar messages at almost
the same time. This can be detected automatically. This technique is
already used in Usenet News to control cancelbots, but it could be
applied also to e-mail as well, even to personal e-mail.

In cases you are not sure if a message is a spam or not, it could be
accepted but marked in your incoming mailbox. I am marking all
messages which do not have my name in the mail header with a blue
instead of black entry in the listings of messages in my mailer. Most
of these messages are spams, not all, but the blue colour is a good
help in getting rid of spams.

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

---

From: Randy Bush <[email-masked]>
Date: Wed, 4 Mar 1998 07:55:20 -0800 (PST)

>> i meant my question very literally.  is it current practice?  if so, and
>> it is the best of which we are aware, then it should be a BCP.  if not,
>> ...
> Randy, I think you're missing the point of what this document specifies.
> This document specifies a set of facilities MTAs should provide.  And in
> this sense the answer is yes, these are the facilities modern MTAs provide
> that have been found to be of some use in combatting spam, and hence this
> document is a good candidate for BCP.

Ned, I suspect you are missing my point, such as it is.  I have no bones
about whether this particular document is fish or fowl (though I did cheat
and read it:-).  I merely care about the process.  My concern is a tendency
(not saying in this case) to call untried practices best current, protocols
practices or vice versa, etc.

So I am simply trying to get folk to think about the process and criteria,
and act appropriately.  I am not arguing either side of the particular case.

If, as you seem to say, this documents current existing practice, it's the
best practice we have, and it is practice not protocol, then I support your
contention that "This document is a good candidate for BCP."

> sorts of blocking policies should be implemented using these facilities.

Not a problem to me.

randy

---

From: "Perry E. Metzger" <[email-masked]>
Date: Wed, 04 Mar 1998 11:00:28 -0500

Jacob Palme writes:
> around such measures.

True enough, but this has a very salutory effect.

It means that anyone spamming now has to steal someone's domain name
-- that is, to commit a kind of fraud. That generally means there is
someone who can sue them for damages, which is happening more and more
often (and which usually succeeds).

Perry

---

From: "Marcus Leech" <[email-masked]>
Date: Wed, 04 Mar 1998 11:38:31 -0500

> often (and which usually succeeds).
We're starting to implement inbound spam filtering based on content
  "signature", rather than just headers.  Even filtering on headers
  will reduce our inbound spam by about 70%.  Each of the spam
  packages has a distinct "fingerprint". The fingerprints corresponding
  to the "STEALTH" e-mail spam software constitute about 50% or more of
  our inbound spam.

-- 
----------------------------------------------------------------------
Marcus Leech                             Mail:   Dept 8M86, MS 012, FITZ
Systems Security Architect               Phone: (ESN) 393-9145  +1 613
763 9145
Messaging and Security Infrastructure    Fax:   (ESN) 395-1407  +1 613
765 1407
Nortel Technology              [email-masked]
-----------------Expressed opinions are my own, not my employer's------

---

From: Ned Freed <[email-masked]>
Date: Wed, 04 Mar 1998 09:45:16 -0800 (PST)

> and act appropriately.  I am not arguing either side of the particular case.

Again I'm going to quibble with your unspecific use of the word "practice".
Yes, we're talking about a BCP, which has the word "practice" embedded in it.
But it is absolutely vital to distinguish between "MTA implementation practice"
and "use of MTA facilities practice". One is a rathole for sure, the other
hopefully isn't.

Operationally we have tons of experience with both of these things, so in this
sense there's nothing untried about any of it. I also think we also have a
pretty good idea what facilities an MTA can provide that may prove to be
useful. But I don't think we have any real idea what the best uses of these
facilities are and stand no chance of reaching any sort of agreement on matters
of usage policy.

I guess what I'm saying is that the "tried or not" yardstick isn't an
especially useful one in this particular case. All of this stuff has been been
widely implemented and has been widely used. And your concern that we might be
calling something that warrants a BCP label untried and untested frankly
doesn't concern me at all. The fact of the matter is that various advocates of
different approaches believe most passionately in the choices they have made,
and there is precious little chance of reaching any sort of consensus on what
polices are best. This is why it is so vital to avoid the policy discussion and
instead focus on something we can agree on -- a broad set of facilities that do
make sense to have in MTAs. And if that means leaving various thing unsaid, so
be it. Reaching concensus requires compromise more often than not.

The followup messages posted to this thread today are a case in point. We have
talk of how certain usage of these facilities used to work but doesn't any
more, rebuttal of the form that these facilities are useful in that they force
spammers into acts of fraud which can then be prosecuted, and surrebuttal that
the costs of legal action are such that most companies will never pursue the
legal route, and so on. (My apologies if some of the posters to this thread
feel I've glossed over their points or stated them incorrected -- I've
attempted to at most sketch the outline of the discussion, not capture the
essensce of it.) The problem is that this sort of discussion revolves around
policy matters, and while it can be very useful and informative and so on I
have not observed that it ever leads to the sort of consensus necessary to
write standards documents.

> contention that "This document is a good candidate for BCP."

It certainly isn't protocol. And it has been implemented.

> Not a problem to me.

Good.

				Ned