On Tue, 26 Jun 2001, Adam M. Costello wrote:
> Oops, I'm sorry, I just realized that there was no simple way for exim
> to detect the loop, because it involved another machine. Here's exactly
> what was happening:
Ha! It's the two machines that are causing the problem.
> exim is running on machine1. A message to user1@machine1 gets
> frozen, so a notification is sent to postmaster, which expands to
> user2@machine2, which expands to multiple addresses, including
> user1@machine1, so another message gets frozen, repeat ad infinitum.
>
> For regular forwarding loops, MTAs usually detect loops by noticing that
> the list of Received: fields gets too long. But that doesn't work in
> this case because it's a brand new message being created each time.
Yup. Most infinite mailing loops nowadays seem to be of this kind -
where each message provokes a new message. Plain forwarding usually gets
caught somehow.
> Bounce messages usually cannot loop because the envelope sender of a
> bounce message is <>, so a bounce message has nowhere to bounce back to.
> But in this case it's not a bounce message, but a notification message.
Hmm, but Exim should send notification messages with envelope sender set
to <>, just like bounce messages. (It uses the same code in each case.)
So there's something odd going on.
> Maybe there should be a rule that failure to deliver a message whose
> envelope sender is <> should never generate a notification.
Exim tries. Here's what one of its comments says.
/* If delivery was frozen, and the mailmaster wants to be told, generate an
appropriate message, unless the message is a local error message - to prevent
loops - or any message that is addressed to the local mailmaster. Then
log the freezing. */
Note that word "local". The check happens only for its own bounce
messages. I thought it was probably correct to send the notification if
a bounce message from an outside source got frozen. In your case, the
combination of two machines and alias expansions defeat this check.
> Or maybe
> MTAs should put a counter in the header of a notification, and if
> failure to deliver a notification causes another notification, the
> latter should have a counter value one greater, and the notification
> should be suppressed if the counter gets too large.
I could certainly put something even simpler, such as
X-Exim-Notification-From: host.name
in all messages generated by Exim. Then, if it received a bounce message
containing this header that matched its own host name, it could refrain
from generating a "message was frozen" notification.
Come to think of it, perhaps it should just test for
From: <mailer-daemon@???>
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
