Your message dated: Wed, 07 May 1997 23:54:11 +0200
> *sigh* All right. How much SMTP mail did AOL deliver yesterday? L-Soft
> made 4,143,362 deliveries yesterday (below average). I imagine that AOL
> delivered well over 41,433,620 SMTP messages in that time frame, or you
> would not have applied this remark to me.
I've discovered over the years that it's not recipient deliveries
that are important, since large numbers of deliveries typically
get sent to the same MXes (so what you would need to count instead
would be number of separate envelopes delivered). Instead, what
separates the wheat from the chaff is the total number of messages
*received*, or for which delivery attempts were made.
We received over five million messages yesterday (and rejected
another seven million delivery attempts), to a total of almost 23
million recipients. The Internet side is typically about half the
total volume of the AOL mail system as a whole.
If you want to count individual recipients, then guess what
-- that's about 45 million, which is even slightly higher than the
number you'd quoted.
Now, how many million messages did you receive yesterday?
> As a matter of fact, yes, I do think I could do better than your
> sendmail-based setup!
Then put your money where your mouth is. Give up your day
job and come over here to learn how the big boys play the game.
Until you think in terms like terabyte and petabyte the way
everyone else talks about kilobytes and megabytes, you won't be
thinking on the right kind of scale as to where we are today, much
less where we have to plan to be tomorrow.
I know that sounds crass, and in a way it's supposed to.
However, it's been my experience that *no* one has been prepared
for the scale of the operation we run here, the first day they walk
in the door (heck, even three to six months later).
Until you can think in the right scale, and invent solutions
out of wholecloth for the unique types of problems that presents,
there are just some things you can't talk intelligently about.
> What is
> going to happen though is that the spammers will get a clue, if not
> tomorrow then next week or next month, and they will stop sending mail
> with source routed MAIL FROM:, since it does not get there, and instead
> use a % hack, the hostname of some random cisco somewhere in the net
> (that would work wonders on your sendmail queues!), or why bother, just
> MAIL FROM:<>.
If we see an excessive number of messages that threaten the
AOL mail system using the "% hack", then we'll turn that off too.
I'd really hate to have to do it (since I've used that myself to help
debug mail problems in the past), but we'll do what we have to do.
As for null envelope senders, that actually doesn't do much to
threaten the AOL mail system, since we'd never attempt to generate
a bounce in that case anyway.
> I still don't agree with the approach, but
> this at least makes some measure of sense. Definitely more than just
> stating that source routes are intrinsically evil and need to be
You obviously don't understand. This is not a discussion about
how things should be done, it's a simple statement of fact about
how the AOL mail system works. Period.
If you want to debate the technical issues with me in private,
I'll be willing to discuss them so long as there appears to be a
valid reason for continuing to do so.
> We do this as well, and frankly I don't know where you got the notion
> that I do not have to deal with spammers on a daily basis and have no
> idea how mean they can be and so on.
I know quite well that you have to deal with junkmailers on a
daily basis, and from what I've seen, you've done a pretty good job.
However, no other site on the *planet* has to deal with them on
the scale that we do. This is a case where a difference in size
has created a difference in kind.
> I am only disputing the wisdom of
> rejecting perfectly legitimate messages (which have 2-3 recipients and
> are thus clearly not spam) on the basis that the MAIL FROM: field looks
> like what the current version of a popular spam program generates,
> especially since there will be a new version of the spam program soon to
> correct this "problem".
Unfortunately, we are required by law to take whatever technical
means are possible to prevent "abuse" of our systems, and only when
all possible avenues of technical methods are exhausted, will the
courts (or lawmakers) then listen to our complaints.
Such is the legal system we have to live with.
Brad Knowles MIME/PGP: KnowlesB @
Senior Unix Administrator <http://www.his.com/~brad/>