On 6/7/05, Matthew Byng-Maddick <exim@???> wrote:
> [OP cc-ed in as I'm assuming he's not on the list]
> On Tue, Jun 07, 2005 at 10:40:19AM -0700, Tony Marques wrote:
> > I don't operate or have experience with Exim, but I've have noticed a
> > problem with several different exim mail servers (one 4.50 several
> > 4.41 and probably other versions). Perhaps someone can look at this
> > and determine if it is a bug in Exim.
> >
> > A virus spoofing my domain will send an Exim server a message which
> > will initially accept the message but later tries to bounce the
> > message because it finds the illicit .scr/.pif/.exe attachment, the
> > mailbox is full, no such user or some other problem. So now the Exim
> > server generates and sends a bounce to my server which detects the
> > illicit attachment or forgery and responds with either a
> >
> > after DATA "."
> > 554 5.7.1 Message cannot be accepted, virus found
> >
> > after RCPT TO: fake@???
> > 550 5.1.1 fake@??? User unknown; rejecting
> >
> > Here is the problem, the Exim servers will retry to resend the message
> > (ignoring the 55x errors) every two hours for 2 or 3 days. The
> > bounce's message-id, date, other headers, and the quoted forgery all
> > demonstrate that the multiple bounces are caused by a single message
> > and the multiples are a result of a problem with Exim not
> > acknowledging my server's 55x responses. Normally this problem
> > wouldn't be noticed as bounces aren't normally seen.
>
> Ok, first off exim doesn't do this. If it gets a 550, this means the
> message will be bounced, if it gets a 550 on a bounce, it will "freeze"
> the message.
>
> Obviously, in the case you've suggested above, you know that the "single
> message" that has the multiples you're talking about is rejected after
> DATA (you wouldn't see it at all if rejected after RCPT), so, my first
> question is: have you timed how long it takes to do the virus scanning,
> and in particular, what is the time delay between the sender-SMTP sending
> a final "." and your receiver saying "554 5.7.1"? Is it possible that the
> sender-SMTP has timed out?
No, I'm also talking about 550 after the RCPT and 550 after DATA is recieved.
So for your first question, the total time is only a couple of seconds
at most to do the virus scanning and in the case of the 550 after the
RCPT, there is no virus scanning (dns lookups or anything) and as you
may see in the log of the sample I setup both transactions took less
than a second. There isn't a time out.
Actually it's been another two hours so lets look at the new log entry
from my test of a foreign Exim server...
2005-06-07 23:09:26 69.72.225.186 bob.xstreamhost.com SMTPSVC1 BBOX
142.179.66.95 EHLO - +bob.xstreamhost.com 250 0 182 24 0 SMTP - - - -
2005-06-07 23:09:26 69.72.225.186 bob.xstreamhost.com SMTPSVC1 BBOX
142.179.66.95 MAIL - +FROM:<> 250 0 27 22 0 SMTP - - - -
2005-06-07 23:09:26 69.72.225.186 bob.xstreamhost.com SMTPSVC1 BBOX
142.179.66.95 RCPT - +TO:<exim-sucks@???> 550 0 57 35 SMTP
- - - -
2005-06-07 23:09:26 69.72.225.186 bob.xstreamhost.com 142.179.66.95
DATA - - 554 0 0 4 0 SMTP - - - -
2005-06-07 23:09:26 69.72.225.186 bob.xstreamhost.com 142.179.66.95
QUIT - bob.xstreamhost.com 240 375 53 4 0 SMTP - - - -
Again all happend in the same second. I don't like this log, that
DATA command is confusing (MS junk). Here is a example from my
regular server...
69.72.225.186 [00001B84] Tue, 07 Jun 2005 08:48:46 -0700 Connected
69.72.225.186 [00001B84] Tue, 07 Jun 2005 08:48:46 -0700 >>> 220
mail.agate.ca ESMTP mmmMail; Tue, 07 Jun 2005 08:48:46 -0700
69.72.225.186 [00001B84] Tue, 07 Jun 2005 08:48:46 -0700 <<< EHLO
bob.xstreamhost.com
69.72.225.186 [00001B84] Tue, 07 Jun 2005 08:48:46 -0700 >>>
250-mail.agate.ca Hello bob.xstreamhost.com [69.72.225.186], pleased
to meet you.
69.72.225.186 [00001B84] Tue, 07 Jun 2005 08:48:46 -0700 <<< STARTTLS
69.72.225.186 [00001B84] Tue, 07 Jun 2005 08:48:46 -0700 >>> 220
2.0.0 Ready to start TLS
69.72.225.186 [00001B84] Tue, 07 Jun 2005 08:48:46 -0700 <<< EHLO
bob.xstreamhost.com
69.72.225.186 [00001B84] Tue, 07 Jun 2005 08:48:46 -0700 >>>
250-mail.agate.ca Hello bob.xstreamhost.com [69.72.225.186], pleased
to meet you.
69.72.225.186 [00001B84] Tue, 07 Jun 2005 08:48:46 -0700 <<< MAIL
FROM:<> SIZE=3681
69.72.225.186 [00001B84] Tue, 07 Jun 2005 08:48:46 -0700 >>> 250
2.1.0 <>... Sender ok
69.72.225.186 [00001B84] Tue, 07 Jun 2005 08:48:46 -0700 <<< RCPT
TO:<fake@xxxxxxxxxxxx>
69.72.225.186 [00001B84] Tue, 07 Jun 2005 08:48:46 -0700 >>> 550
5.1.1 <fake@xxxxxxxxxxxx> User unknown; rejecting
69.72.225.186 [00001B84] Tue, 07 Jun 2005 08:48:46 -0700 <<< QUIT
69.72.225.186 [00001B84] Tue, 07 Jun 2005 08:48:46 -0700 >>> 221
2.0.0 mail.agate.ca closing connection
SYSTEM [00001B84] Tue, 07 Jun 2005 08:48:46 -0700 Disconnected
Multiply that log entry 25 over two days and tell me if you would
notice it. If it's accepted (by a backup MX for instance) Exim gets
a 250 and is done.
>
> > Can someone determine if this is a current bug or when it was fixed
>
> Such a bug does not exist. If it did, we would be in much deeper water.
You've saying there is a special case for <> messages, they are frozen
and aren't treated as regular messages. A special case is all the
more reason for a bug and all the more reason it may not have been
noticed in the past.
The truth is, what I'm describing usually occurs between an
unmonitored account and another non-monitored sometimes non-existant
account. The sending Exim side lists these bad/frozen and after two
days when it actually stops the result is the same. The destination
may only be noticed as 5 line log entires saying User not found or <>
illegal sender or something. Many recipients may also accept the mail
and eventually have to handle the bounce themselves. This could have
been happening for years -- I've just found some messages from Exim
3.33 which also seemed to have ignored 550 errors.
> > and under what condition this exists? I presume all MAIL FROM: <>
> > SHOULD be deleted or forwarded to a badmail mailbox after rejected
> > with a 55x error and not remain in the outgoing queue.
>
> "badmail mailbox" ? ugh! No, exim has the concept of "freezing" a message,
> which means that it doesn't get processed in a normal queue run. This has
> roughly the effect that you describe, however.
>
> It is possible (given that you've used the same host as an example
> several times), that someone has a cronjob which unfreezes messages. This
> would be considered bad practice, but it wouldn't be the first time that
> bad practice existed on the internet.
Like I've said, I've seen this over and over again where Exim servers
are the culprits. And I wouldn't suspect a cron job unless it's
runing ever hour or some other short time period so can unfreeze
messages so they are sent every two hours window when it retries.
Relay a message through your server from <exim-rulez@???>
to <exim-rulez@???> and we'll see if this problem exists.
