Re: master mail problems -- help needed
* Jeroen van Wolffelaar:
>> I tried to debug it myself, using the information I could access on
>> master, but I couldn't gather enough evidence to present to the
>> postmasters so far.
>
> But other DD's can also only do a limited amount of research, the only
> way to really find out is asking a postmaster -- this isn't a
> prosecution, so 'evidence' is not needed, I'd say (though, a copy of one
> bounce message with full headers would be the minimum I'd expect,
> because otherwise debugging is close to impossible).
The trouble is that I lack a recent bounce message because I thought
the problem was on my side (my .procmailrc script). The PTS
unsubscription told me that I was wrong.
> In general, this failure means that for 4 consecutive days the
> a connection attempt that happens roughly every 8 hours fails
> (connection refused, a timeout, HELO refused, stuff like that). Are you
> sure that this condition can never have happened?
Yes, some mail went through smoothly during about the same time. This
should clear the hint in Exim's retry database.
> I see you only have one MX, for increased reliability and for cases
> when for example there's a routing problem somewhere between master
> and that one single MX, add a backup MX.
Hmm, speaking of MXes, mail delivery over IPv6 seems to be enabled on
master:
router = dnslookup, transport = remote_smtp
host mail.enyo.de [2001:14b0:202:1::a7] MX=10
host mail.enyo.de [212.9.189.167] MX=10
But master does not seem to have IPv6 connectivity. Maybe this is
causing the problems, but this would also mean that Exim itself is
buggy.
It probably makes sense to disable IPv6 support in Exim on master,
independently of my current problem. I'm going to suggest this to
postmaster@ once I figured out a good way to implement this.
> When an exim mailserver is really bogged down under mail load, attempts
> can be made even less often.
As far as I know, the mail server still responds with the RFC limits,
which are also obeyed by Exim.
> I'd really look into a secondary MX,
Or more powerful hardware on the primary MX, or more efficient
software, I know.
> but if it's indeed only there two problems at the frequency you say,
> it shouldn't really be possible that this is the cause.
Exactly my line of thought.
>> This problem has gained some unexpected urgency because I was kicked
>> off the PTS due to these bounces (I think so, I haven't been shown one
>> of the PTS bounces). On the other hand, it rules out my .procmailrc
>> on master as an error source (because PTS mail gets sent to
>> <fw@deneb.enyo.de> directly).
>
> There is no automatic bounce handling for the PTS, that's still on the
> TODO...
The removal wasn't automatic.
Reply to: