Stuck in the greylist

John R Levine
Tue Dec 23 19:10:39 UTC 2003

> I see greylisting as "embargo all messages with a {sender,IP,target}
> triple until a message has been persistently retransmitted.  Variations
> like "embargo until the spammer has reused a {sender,IP,target} triple"
> are weaker.

It's certainly weaker, but the question is whether it's catching more spam
or more legit mail.  Having gone through the logs in more detail, I see
quite a few other places doing the same thing, regenerating the message
rather than saving and retransmitting, and as best I can tell (pretty
well, since I know most of my users personally) it's all legit list mail.

RFC 2821 is ambiguous.  It says that after a 451 the sender should resend
the message later, but it doesn't insist that the message be the exact
same bits.  I realize you can read it that way, but I think you can
equally well read it to mean that the "message" is the semantic content
rather than the bits, and if you're sending large numbers of similar
messages, the operational advantages for saving the info to regenerate the
message rather than whole messages is compelling.

In any event, I realize that not using body checksums makes it more likely
that a spammer will deliberately or accidentally spoof a resend by making
another spam run a day later with the same envelopes, but it's hard for me
to consider a design that's known to reject legit mail as much of a

It appears that the semantic resends all keep the same fuz2.  How about
(optionally at least) using that rather than the body checksum in the
greylist?  That'll let through the semantic resends while still being
resilient against multiple spam runs.

John Levine,, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be,, Sewer Commissioner
"I dropped the toothpaste", said Tom, crestfallenly.

More information about the DCC mailing list

Contact by mail or use the form.