Great Circle Associates List-Managers
(July 2002)

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: e-mail spamming
From: Nick Simicich <njs @ scifi . squawk . com>
Date: Mon, 22 Jul 2002 22:21:32 -0400
To: "list-managers" <list-managers @ greatcircle . com>
In-reply-to: <NFBBLLDJILDCFMHPEFPHGENKCFAA . jwzumwalt @ neatinfo . com>
References: <5 . 1 . 0 . 14 . 2 . 20020719201443 . 22944b30 @ 127 . 0 . 0 . 1>

At 03:29 PM 2002-07-22 -0800, Jan Zumwalt wrote:

I am having a unique problem with an e-mail list run under Majordomo. I have
a list of about 50 people subscribed to it.

About 3 weeks ago, 2 of the users reported that they started receiving about
100 e-mails a day from the list server. The odd thing is the rest of the
group does not receive these e-mails.

What are the domains of those two users?  Do they share a server?

Is there a known bug or attack for Majordomo that would give these results?

Jan Zumwalt

This is a common problem, frankly. What is likely to be happening is that the mail delivery process to someone, somewhere, goes almost to completion, and then it times out for some reason. Now the receiving host has a copy of the mail and it tried to send the final ack, (the pause after the '.' and the reply to that is what usually times out) and, in fact, it has no way of knowing that the 2xx response to the '.' did not get through so it thinks it is obligated to deliver the mail, and the sending host did not get what it thinks is a positive acknowledgement that the mail was actually delivered. So the sender queues the mail and sends it on again later.

The first thing to do is to look at the mail log for the system that is running majordomo. This is the log for sendmail, postfix, qmail, or whatever that system uses as a MTA (mail transfer agent). Make sure that the system is sending the mail once and not many times. If it is sending the mail many times, I'd bet that all but the last delivery shows a failure.

Of course, the more likely issue will be that your system is not delivering the mail more than once - that the problem is elsewhere.

You need to see the headers for one of the multiply delivered pieces of mail, 5 or 6 should be enough, you probably do not need an entire set of 100. You need full headers, especially (only?) the received lines, date/time stamp and message-ID.

Look at the timestamps in the Received lines, read from the bottom up. Some of them will be common -- up to a point. One will change from one instance to another.

That Received line indicates which interaction is actually broken. Firewalls, especially those which do stateful tracking are likely. Take a common setup: The outside MTA for a corporation is a simple grabber and it passes the mail to an "inside MTA" which just had, say, spamassassin or a virus scanner installed.

So the mail is sent inside. The whole MAIL FROM:<> RCPT TO:<> DATA thing goes along, and the "." is sent. The receiving system starts a long, asyncronous process of vetting the mail and finally decides to return a "2xx OK", but the connection is long gone because the firewall times out. The Receiving system sends the mail down the line, but the sender can't ever get that 2xx so it presumes a failure.

If you can figure out which interaction is timing out, then you can notify the sysadmins in the receiving domain, or, more likely, explain it to your users so they can complain to their own sysadmins. Chances are it is as simple as extending a timeout by a significant amount. If it is shown in your system's mail log, then it may be a timeout issue in your MTA---some can have timeouts adjusted and some systems take a very long time to return that 2xx to the end of data indicator, the stand alone '.', so you have to be patient.

    "The BeOS takes the best features from the major
    operating systems. It's got the power and flexibility
    of Unix, the interface and ease of use of the MacOS,
    and Minesweeper from Windows." --Tyler Riti
Nick Simicich - njs @
scifi .
squawk .
com -
 --- stop by and light up the world...

Indexed By Date Previous: Re: e-mail spamming
From: "Jan Zumwalt" <jwzumwalt @ neatinfo . com>
Next: Re: Surveying list users.
From: Jim Osborn <jimo @ eskimo . com>
Indexed By Thread Previous: Re: e-mail spamming
From: "Jan Zumwalt" <jwzumwalt @ neatinfo . com>
Next: Another AOL issue
From: Sharon Tucci <Sharon @ listhost . net>

Search Internet Search