Subject: Asinine anti-spam mechanisms

From: "D. J. Bernstein" <[email-masked]>
Date: 6 Jun 1999 06:09:20 -0000

Context: DRUMS is an IETF working group dealing with Internet mail. The
DRUMS mailing list, [email-masked], has a history of mail loss and
other reliability problems.

In the latest episode, some messages to the mailing list---including at
least two of mine---were placed into a holding area pending review by a
cs.utk.edu postmaster.

Keith Moore, list administrator and former DRUMS chair, writes:
> it appears that dns queries to the domain cr.yp.to often time out

Other people don't have this problem, Keith. Perhaps your homegrown
``anti-spam'' software is flaky. Perhaps your network is flaky.

But this is beside the point. The correct response to temporary problems
is to TRY AGAIN LATER. Where did you get the idiotic idea that it would
be better to put the message on hold and wait for human intervention?

If retries are too complicated for your software, you shouldn't accept
the mail in the first place. The remote SMTP client will try again later
if you send it a 4xx code.

> it's not a bug, it's a feature!

I can't believe that someone who deliberately runs such a fragile mail
system would have the nerve to tell other people how mail should work.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 6 Jun 1999 06:09:20 -0000

---Dan

---

From: Keith Moore <[email-masked]>
Date: Sun, 06 Jun 1999 03:05:20 -0400

Dan,

your messages to the drums list were presumably sent to the
moderator because the spam filter could not immediately verify 
the validity of your return address.

we have found this to be an incredibly effective heuristic for
detecting spam sent to our mailing lists, and the inconvenience
to senders of having their messages delayed (usually only a few
hours) until the moderator can read them is far outweighed
by the benefit of virtually eliminating spam from the lists.

we considered having the spam filter report tempfail to the 
MTA in cases where the sender's address could not be immediately
verified, so that the MTA could retry delivery later.  but 
when we analyzed the traffic we realized that such a policy 
would invite denial-of-service attack from spammers (who, 
experience indicates, will stoop to anything).  especially given the 
low ratio of false positives, it made more sense to have a human 
moderate the list.

so we concluded that having an effective spam filter was more 
important than having absolutely immediate delivery of messages.

Keith

p.s. we could make the filter even better by having it moderate all
messages containing the word 'asinine'  since such messages
are highly unlikely to be appropriate for ietf mailing lists.

---

From: Keith Moore <[email-masked]>
Date: Sun, 06 Jun 1999 03:05:20 -0400

Dan,

Keith

---

From: "Dick St.Peters" <[email-masked]>
Date: Sun, 6 Jun 1999 22:02:59 -0400

> if you send it a 4xx code.

If the remote client is an NT server running Microsoft SMTP without an
update Microsoft issued in March, it will try again immediately if you
send it a 4xx code.  "Immediately" means up to 6 times per second for
the cases that we've logged here.  The first report of this on bugtraq
was of a case of an NT server attempting to deliver a message 200,000
times in one day.

We had cases involving tens of thousands of attempts in our own logs
but had attributed them to intentional denial of service attacks on
our mail servers.  They stopped happening when we began returning 5xx
error codes.

That, BTW, was Microsoft's suggestion too.

(To Microsoft's credit, they promptly acknowledged the problem and
fixed it - but there are lots of NT systems out there that have not
had the update applied.)

--
Dick St.Peters, [email-masked] 
Gatekeeper, NetHeaven, Saratoga Springs, NY, 1-800-910-6671 (voice)
Saratoga/Albany/Amsterdam/BoltonLanding/Cobleskill/Greenwich/
GlensFalls/LakePlacid/NorthCreek/Plattsburgh/...
	  Oldest Internet service based in the 518 area code

---

From: "Dick St.Peters" <[email-masked]>
Date: Sun, 6 Jun 1999 22:02:59 -0400

---

From: "D. J. Bernstein" <[email-masked]>
Date: 7 Jun 1999 21:35:02 -0000

Dick St.Peters writes:
> send it a 4xx code.

As if common sense weren't enough: RFC 1123 specifically requires that
SMTP clients delay before trying again. I wonder how Microsoft managed
to screw this up.

Anyway, this doesn't justify Keith's asinine ``put the message on hold
and wait for human intervention'' method of handling temporary failures.
If Keith has a problem with a Microsoft host, then he can deal with it
without setting up a fragile mail system that screws up other people's
messages.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 7 Jun 1999 21:35:02 -0000

---Dan

---

From: [email-masked]
Date: Mon, 07 Jun 1999 19:01:02 -0400

> SMTP clients delay before trying again. I wonder how Microsoft managed

And screw up it did.  One of my machines got pounded 123,000+ times in 36
hours over the weekend.

> without setting up a fragile mail system that screws up other people's

Oh pray tell, wonderful wise guru of SMTP, how does one determine remotely
that the remote host is Microsoft, and should be handled differently, instead
of simply saying "this looks suspicious, have it checked out"?  Remember -
it's contacting YOU , so you can't intuit based off the 220 header you're sending
to them on each connection.

I'd also be interested in knowing just how bulletproof you want a mail system
to be - how many hundreds of thousands of bounces/errors should it be overdesigned
to handle so it doesn't count as 'fragile'?  Remember that such levels of
excess capacity *cost money*, and sometimes it *is* cheaper to let a human sort
it out.

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: [email-masked]
Date: Mon, 07 Jun 1999 19:01:02 -0400

---

From: [email-masked]
Date: Mon, 07 Jun 1999 19:45:50 -0400

> without setting up a fragile mail system that screws up other people's

I really hate rubbing salt in things, but..  RFC1891 through RFC1894 are
for building less fragile mail systems, providing machine-parsable replies
that the software can act on without human intervention.  The following notice
I got *requires* human intervention.

> Hi. This is the qmail-send program at koobera.math.uic.edu.
> I'm afraid I wasn't able to deliver your message to the following addresses.
> This is a permanent error; I've given up. Sorry it didn't work out.

This *after* qmail had added a 'Delivered-To: [email-masked]' to the original
body, and leaving no other hint what address failed.

I'm sorry Dan.  I really can't have much sympathy for your position.
As postmaster for a large Listserv site, I see literally 200 to 300 bounces
a day - and the one from my previous posting ranks very high up the list of
'least likely to be machine parseable'.

And that's not the way to build non-fragile, robust mail systems.

---

From: [email-masked]
Date: Mon, 07 Jun 1999 19:45:50 -0400

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Jun 1999 03:19:56 -0000

[email-masked] writes:
> One of my machines got pounded 123,000+ times in 36 hours over the weekend.

I understand your annoyance at the waste of log space, but you must have
an incredibly slow SMTP server if one connection per second constitutes
``pounding.''

> Oh pray tell, wonderful wise guru of SMTP, how does one determine
> remotely that the remote host is Microsoft, and should be handled
> differently,

Dumb question. What's annoying you is not that the SMTP client is from
Microsoft. What's annoying you is that the SMTP client is making lots of
SMTP connections where it isn't getting anything done. You can check for
that, and take appropriate action, without hurting other clients.

> I'd also be interested in knowing just how bulletproof you want a mail
> system to be

As stated in http://pobox.com/~djb/proto/im/responsibility.html, under
``Quality issues'':

   Sometimes the first attempt to deliver a message is stymied by a
   temporary problem such as a network outage or a full disk.
   High-quality mailers do not give up on delivery after a single
   temporary failure; they wait for a while and then try again. They
   give up only if the ``temporary'' problem persists for several days.

I'm astounded that you could refer to such a fundamental feature of the
Internet mail system as ``overdesign.'' The overall costs are minor, and
the reliability benefits are tremendous.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Jun 1999 03:19:56 -0000

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Jun 1999 04:34:52 -0000

See http://pobox.com/~djb/docs/copies.html if you're curious about the
bounce message that has gotten Kletnieks so upset.

[email-masked] writes:
> RFC1891 through RFC1894 are for building less fragile mail systems,

That's what they were _intended_ to do, but intent isn't enough when it
isn't backed up by solid engineering.

RFC 1891 is an absurdly complicated link-level protocol, unsupported by
most MTA authors and useless for standard multidrop POP mailboxes. Its
misguided notification guarantee, which is what forced the complexity in
the first place, appears to have been destroyed by sendmail.

RFC 1892 and RFC 1894 aren't as ludicrous as RFC 1891, but they're still
unnecessarily difficult to parse.

Fortunately, all of these RFCs have been rendered obsolete. The big
problem that motivated them---namely, the difficulty of identifying the
subscriber for each mailing-list bounce---has been eliminated by VERPs.

> 'least likely to be machine parseable'

In fact, qmail's bounce messages follow a documented, easy-to-parse
format that has around just as long as RFC 1894. Several independent
parsers have been deployed. See http://pobox.com/~djb/proto/qsbmf.txt
for a description of the format and a comparison with 1892/1894.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Jun 1999 04:34:52 -0000

---Dan

---

From: Brad Knowles <[email-masked]>
Date: Tue, 8 Jun 1999 09:55:34 +0200

> an incredibly slow SMTP server if one connection per second constitutes

	Well, when one copy of that message is delivered to all 
recipients (save those that have full mailboxes, etc...) each and 
every second, I can understand why there would be a problem.

	Even you must admit that you are limited by your local delivery 
agent, and if you were to deliver a thousand copies of the same 
message (or even just a hundred) for each and every second of hours 
upon hours on end, your mail system would probably slow down to that 
of a scum sucking snail -- that's assuming that it stays running at 
all.

> that, and take appropriate action, without hurting other clients.

	What's annoying is that the same message is being successfully 
delivered time after time after time after time to all the other 
recipients that aren't currently having any problems, until such time 
as all recipients have full mailboxes, and then the message as a 
whole bounces.

	I think I've decided that we should all run nmap and queso on our 
mail servers, and if the connecting machine is a Windows NT box, we 
should refuse to talk to it.

-- 
   These are my opinions -- not to be taken as official Skynet policy
  ____________________________________________________________________
|o| Brad Knowles, <[email-masked]>            Belgacom Skynet NV/SA |o|
|o| Systems Architect, News & FTP Admin      Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.11.11/12.49         B-1140 Brussels       |o|
|o| http://www.skynet.be                     Belgium               |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.
   Unix is very user-friendly.  It's just picky who its friends are.

---

From: Brad Knowles <[email-masked]>
Date: Tue, 8 Jun 1999 09:55:34 +0200

---

From: Brad Knowles <[email-masked]>
Date: Tue, 8 Jun 1999 10:11:01 +0200

> subscriber for each mailing-list bounce---has been eliminated by VERPs.

	Yes, everyone must bow to the one and only SMTP God; the one and 
only person who actually understands impossibly complex things like 
RFCs, systems engineering, communications, and the entire Universe.

	Everyone, please turn to your King Dan Bible, in the Book of Dan, 
Chapter Dan VI, Verse 21.3.

---

From: Brad Knowles <[email-masked]>
Date: Tue, 8 Jun 1999 10:11:01 +0200

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 8 Jun 1999 12:50:17 +0100 (BST)

> the reliability benefits are tremendous.

Is there any sort of standard algorithm for determining waits between
subsequent attempts? (thinking of a poor analogy with TCP backoff
here.)

Tying in some sort of intelligent calendar function ('it's Friday
night there, it's hosed, I may not be able to send to Monday at the
earliest - hang on, Monday is Memorial day, better make that Tuesday,
so I'll spread x attempts over that time') strikes me as a possibly
neat optimisation, speaking from recent experience.

L.

'they wait for a while and then try again' is always a good research area.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 8 Jun 1999 12:50:17 +0100 (BST)

L.

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 Jun 1999 11:12:37 -0400

poor analogy.  when we suspect that a message may be spam we don't want 
to handle it in the same way as a network outage or full disk.  
in particular:

- we aren't willing to tolerate the same amount of max delay before
  deciding whether to send the message to the recipients.  we wait
  three days before giving up attempting to relay a message when the
  relay attempt fails for temporary reasons. suspected spam, on the 
  other hand, typically gets reviewed within a few hours.

- if we do decide that the message is spam, we want to discard it
  silently.  we don't want to return the message to the sender.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 Jun 1999 11:12:37 -0400

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Jun 1999 15:44:20 -0000

Lloyd Wood writes:
> subsequent attempts?

Not really. RFC 1123, section 5.3.1.1, points out some of the issues for
SMTP clients to consider, but it doesn't go into much detail, and it's
missing some features that are now considered essential for large sites.

qmail normally tries a message after 0 minutes, 7 minutes, half an hour,
an hour, etc., slowing down to a total of about 40 attempts in one week.
The precise algorithm for remote hosts is as follows:

   * Each message has an independent quadratic retry schedule, measured
     in seconds from when the message was queued: 0, 1, 4, 9, 16, etc.

   * When a message delivery begins, the next attempt is scheduled for
     20 spaces in the retry schedule after the current time. Note that
     this is not ``when a message delivery ends,'' nor is it ``after the
     previously scheduled time''; those don't work as well under load.

   * If a message delivery begins after more than one week (by default),
     temporary failure is treated as permanent failure. Note that each
     delivery will be tried at least once, even if the load is so
     extreme that the first try is delayed for more than a week.

If two connection attempts to an IP address time out, separated by at
least two minutes, with no intervening successful connections, then
connection attempts to that address are skipped during the next 60-90
minutes.

(What actually happens is that connection attempts are skipped with
probability 31/32 after 3840 seconds, probability 30/32 after 3904
seconds, etc. This gradual change works much better than a sudden cutoff
under high loads.)

Some mailers opportunistically bombard a host with deferred messages as
soon as the host comes back online. qmail doesn't; each message waits
until the appropriate retry time.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Jun 1999 15:44:20 -0000

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Jun 1999 19:45:57 -0000

People who say things like ``the spam filter copied each message to /tmp
... insufficient resources ... you will need to resend'' should not be
running IETF mailing lists.

There are other people who are perfectly happy to run the lists---people
who are using reliable mail software that deals with temporary failures
properly.

Keith Moore writes:
> we wait three days before giving up attempting to relay a message when
> the relay attempt fails for temporary reasons.

Keith claims here that he ``isn't willing to tolerate'' such delays from
his anti-spam system. He claims that a message ``typically gets reviewed
within a few hours.''

But that's simply not true. Out of 1000 recent DRUMS messages:

   * DRUMS message 5724 was delayed for seven days.
   * DRUMS message 5726 was delayed for two days.
   * DRUMS message 5790 was delayed for two hours.
   * DRUMS message 5795 was delayed for a day.
   * DRUMS message 5796 was delayed for seven minutes.
   * DRUMS message 5819 was delayed for a day.

Two of those were from eng.sun.com. I suppose Keith thinks we should
blame the DNS service at eng.sun.com? Sorry, Keith, but the problem is
YOUR UNRELIABLE MAIL SYSTEM!

(Note that three days isn't enough to handle long weekend outages. RFC
1123 says ``the give-up time generally needs to be at least 4-5 days.'')

> when we suspect that a message may be spam we don't want 

It is idiotic to respond to a single temporary failure by diverting
messages to a sysadmin.

I don't care what Keith does to messages that really _are_ spam. But I
am not willing to accept collateral damage from his anti-spam software.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Jun 1999 19:45:57 -0000

---Dan

---

From: Keith Moore <[email-masked]>
Date: Thu, 10 Jun 1999 17:49:24 -0400

Dan,

I'll change the spam filtering software so that if the 
From address is a list subscriber, it will bypass the 
portion of the spam filter that tries to check the address.
Perhaps that will alleviate your concerns.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 10 Jun 1999 17:49:24 -0400

Dan,

Keith

---

From: Matt Curtin <[email-masked]>
Date: 10 Jun 1999 23:32:39 -0400

>>>>> On 10 Jun 1999 19:45:57 -0000, "D. J. Bernstein" <[email-masked]> said:

I'm not going to get sucked into a debate here.  But this is far too
silly to let go completely unanswered.

Dan> Two of those were from eng.sun.com. I suppose Keith thinks we
Dan> should blame the DNS service at eng.sun.com? Sorry, Keith, but
Dan> the problem is YOUR UNRELIABLE MAIL SYSTEM!

Problems in the middle could well cause this sort of behavior (DNS
lookup failure).  Last time I checked, eng.sun.com isn't getting any
special treatment that would cause its DNS to be 100% reliable from
every host on the Internet.  Or perhaps I missed something...

I think that you're jumping to conclusions a little too hastily.  The
only data you have is the amount of time it takes for Keith's system
to accept a message from remote.  That isn't enough data to debug the
problem.  I know you know that, and I'm amazed that you're willing to
go out on that limb, knowing that almost every one of us here is quite
adept at handling a chainsaw.

I fail to understand why you feel the need to shout, to question the
competence of the area director, and to complain to IETF because your
comment to the DRUMS list was delayed a little bit.  And to do so all
at once seems, well, asinine.

Dan, we all want the Internet to work reliably.  That's why we're
here.  Screaming won't fix what's broken.  The world will continue to
work if we have to wait a few precious moments for your words of
wisdom.

One one hand, I'm actually sorry to see that Keith is modifying his
system because of your tantrum.  That certainly isn't a good idea from
the perspective of behavior modification...  On the other hand, I too
would have chosen (and in fact have chosen) another method of handling
spam and do not want to see spam handling techniques degrade the
quality of service.

But behaving in a more silly manner than Keith's spamtrap strikes me
as a strange way to encourage him to find a better solution.

-- 
Matt Curtin [email-masked] http://www.interhack.net/people/cmcurtin/

---

From: Matt Curtin <[email-masked]>
Date: 10 Jun 1999 23:32:39 -0400

---

From: "D. J. Bernstein" <[email-masked]>
Date: 11 Jun 1999 05:45:05 -0000

Matt Curtin writes:
> to accept a message from remote.

Wrong. Far more information is available. Message 5795, for example, was

   * received from playground.sun.com by cs.utk.edu one Thursday at
     14:29:07 -0500;

   * diverted by Keith's anti-spam system into a holding area, where it
     sat, waiting for human attention, without being retried; and

   * reinjected by moore@localhost the next day at 14:10:17 -0500.

This is one of several messages I pointed out before. You could have
looked in the archive rather than making a fool of yourself.

Keith admits that this is how his system reacts to a momentary network
outage. How can he not understand that this behavior is wrong?

> comment to the DRUMS list was delayed a little bit.

At least fourteen messages from several people have been delayed, in one
case by an entire week. At least two messages have been lost. If Keith
had pulled these stunts at an ISP, he would have been fired long ago.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 11 Jun 1999 05:45:05 -0000

---Dan

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Jun 1999 00:29:19 -0700

>and wait for human intervention'' method of handling temporary failures.

In fact, placing a message in a queue for human review is a common, 
accepted, and very useful technique.  One should note that the particular 
case being reported is not just a random, temporary error, but an error 
occurring during a vetting mechanism.

ANY failure (other than local machine crash or network access error) during 
such vetting is suspicious, so that it in fact makes sense to move the mail 
out of regular processing.

d/

ps.  While one is discussing peculiar ways to run mail systems, it might be 
worth noting that a peculiar way to participate in open discussions is to 
have your SMTP server reject (bounce, i.e., return) mail from one or 
another of the participants.  That, of course, is not a theoretical 
example, since Dan has configured his server to reject my mail; he won't 
see this comment.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Crocker                                         Tel: +1 408 246 8253
Brandenburg Consulting                               Fax: +1 408 273 6464
675 Spruce Drive                             <http://www.brandenburg.com>
Sunnyvale, CA 94086 USA                 <mailto:[email-masked]>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Jun 1999 00:29:19 -0700

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Jun 1999 00:32:12 -0700

At 10:11 AM 6/8/99 +0200, Brad Knowles wrote:
	Everyone, please turn to your King Dan Bible, in the Book of Dan, Chapter 
Dan VI, Verse 21.3.

Tsk. Tsk, Brad.  Surely you meant King David...  (Just so long as no one 
says it's a crock.)

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Jun 1999 00:32:12 -0700

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Jun 1999 00:34:52 -0700

>Perhaps that will alleviate your concerns.

Keith,

Given the ease of spoofing From fields, why would you want to open that 
large a door for spamming to come through?

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Jun 1999 00:34:52 -0700

Keith,

d/

---

From: Dave Sill <[email-masked]>
Date: Fri, 11 Jun 1999 07:59:07 -0400 (EDT)

Dave Crocker <[email-masked]> wrote:
>another of the participants.

That *would* be peculiar if Dan did that, but he doesn't. If a message
is sent both to a list he's on *and* directly to him, he bounces the
copy that was sent directly. I, too, find it annoying to receive
multiple copies of messages unnecessarily. I've just been too lazy to
implement Dan's approach. Some people complain about problems, others
fix them.

>That, of course, is not a theoretical example, since Dan has
>configured his server to reject my mail; he won't see this comment.

He saw it. You apparently didn't bother to read the bounce
message. Could this be another knee-jerk anti-djb reaction?

-Dave

---

From: Dave Sill <[email-masked]>
Date: Fri, 11 Jun 1999 07:59:07 -0400 (EDT)

-Dave

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 11 Jun 1999 14:34:02 +0100 (BST)

On Fri, 11 Jun 1999, Dave Sill wrote:

> multiple copies of messages unnecessarily.

I find it interesting that Dan bounces the direct copies, while only
accepting the possibly-delayed copies which go through someone else's
listserver he grumbles about.

Using the quicker-to-arrive (usually direct) copies and silently
discarding the later-to-arrive (usually listserver) copies as
duplicates (based on message-ID) strikes me as the preferable strategy
leading to more robust and timely mail for the user, but then I don't
have an agenda.

> I've just been too lazy to

and some people fix what they see as problems just to give them an
opportunity to complain about other things they see as problems.

L.

has always been amazed by qmail's _polite_ messages. Who wrote those?

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 11 Jun 1999 14:34:02 +0100 (BST)

L.

---

From: "Perry E. Metzger" <[email-masked]>
Date: 11 Jun 1999 10:06:00 -0400

> example, since Dan has configured his server to reject my mail; he won't 

I'm also on the list of people Dan has put into the "reject in SMTP"
list. Among other things, it makes it impossible to try to send a
comment in private to him.

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 11 Jun 1999 10:06:00 -0400

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 11 Jun 1999 10:09:56 -0400

Dave Sill <[email-masked]> writes:
> copy that was sent directly.

No, that isn't what happens. If I send a private comment to Dan OR a
comment cc'ed to the list, I get bounced. I'm on his "special people"
list. Presumably he still sees the copy sent to the public mailing
list, but I have no way to know that.

> message. Could this be another knee-jerk anti-djb reaction?

It is difficult, I must admit, not to have automatic anti-djb
reactions. Given his rather poor public behavior on a number of
occasions (everyone remember his recording "off the record" telephone 
conversations during the lovely IDENT discussion some years back?),
his immediate resorts to name calling, his transparent attempts to
derail IETF process, and his overall demeanor towards anyone who has
the temerity to disagree with him in public, this tendency on the part 
of many must be understandable.

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 11 Jun 1999 10:09:56 -0400

Perry

---

From: Martin Hamilton <[email-masked]>
Date: Mon, 14 Jun 1999 12:05:56 +0100

-----BEGIN PGP SIGNED MESSAGE-----

Lloyd Wood writes:

| Using the quicker-to-arrive (usually direct) copies and silently
| discarding the later-to-arrive (usually listserver) copies as
| duplicates (based on message-ID) strikes me as the preferable strategy
| leading to more robust and timely mail for the user, but then I don't
| have an agenda.

I used to do this (using procmail's duplicate message ID filtering),
but discovered that message IDs that start out the same sometimes end
up different when relayed through broken gateways or list managers.

So, I hacked some code up to stamp each message with the MD5 of its
contents - as per draft-hamilton-content-md5-origin-01.txt - and
tweaked procmail to add an MD5 cache/filtering option in tandem to 
the message ID one.  Used extensively with Exim, lightly tested with 
sendmail.  Caveat emptor :-)

Grab it from: <URL:http://www.net.lut.ac.uk/~martin/antispam/>

Martin

---

From: Martin Hamilton <[email-masked]>
Date: Mon, 14 Jun 1999 12:05:56 +0100

-----BEGIN PGP SIGNED MESSAGE-----

Lloyd Wood writes:

Martin