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 - http://scifi.squawk.com/
--- stop by and light up the world...
References:
|
|
