Strange Transport Problem
Michael Katz
server on CentOS5. The server is an SMTP relay. The problem is that we
have a single default transport, yet some email is relayed properly and
other email fails with mail transport unavailable. It is about 50/50 of
successful email and failed email. There are 300 SMTP sessions
configured in main.cf and they are always pegged. Reducing from 400 to
300 did not help as we thought it was an issue related too many files or
something like this. I am happy to provide information to help in this
issue as requested. The server has been fine for months, this problem
began about a day ago after an RBL server had problems and became
unresponsive.
There is only one transport
* smtp:[other.server]
All email should be relayed to the other server, but you can see here
that some gets transport=none others is successful:
Oct 17 09:37:43 smtp01 postfix/qmgr[29868]: 92E7E9FDACA:
from=<Bea_ka...@xx.com>, size=1985, nrcpt=1 (queue active)
Oct 17 09:37:43 smtp01 postfix/smtp[6450]: 17143A0945B:
to=<sub...@yyy.com>, relay=smtp02.wder.com[10.10.10.41]:25, conn_use=2,
delay=9508, delays=9508/0.15/0/0.05, dsn=2.0.0, status=sent (250 2.0.0
Ok: queued as 2A2BB65C518)
and other email is not:
Oct 17 09:37:43 smtp01 postfix/qmgr[29868]: 92E7E9FDACA:
to=<ae...@zz.com>, relay=none, delay=11871, delays=11871/0.07/0/0,
dsn=4.3.0, status=deferred (mail transport unavailable)
It is mysterious and quite frustrating at the same time.
Load is reasonable: load average: 5.44, 5.48, 5.25
Any pointers are appreciated.
Victor Duchovni
Find the content_filter that has a bogus transport name in it. Also
check for earlier warnings in the log. Use "postcat -q 92E7E9FDACA"
to find the content_filter for the message in question.
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majo...@postfix.org?body=unsubscribe%20postfix-users>
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Michael Katz
I did this, which did point to the problem. Thank you. What I don't
understand is how the filter came into play since it was not configured
for over 2 weeks. Furthermore, I can't see why some messages would be
delivered and others would take the transport of a filter that is not
configured. I have a lot of research to do on my end, but I appreciate
your guidance as your suggestion instantly pointed to the issue.
>
Victor Duchovni
> >Find the content_filter that has a bogus transport name in it. Also
> >check for earlier warnings in the log. Use "postcat -q 92E7E9FDACA"
> >to find the content_filter for the message in question.
>
> I did this, which did point to the problem. Thank you. What I don't
> understand is how the filter came into play since it was not configured
> for over 2 weeks.
Unless your queue lifetime exceeds 2 weeks, the filter was configured
*somewhere* when the message arrived. The arrival time is recorded in
the message.
If the content_filter record appears *before* the message content,
the filter was added by "smtpd" or "pickup" (you can tell which by
checking the top-most Received: header) either via "content_filter =
..." in main.cf or master.cf, or via a FILTER action in an access table.
If the "content_filter" record appears after the message content in the
"HEADER EXTRACTED" section, the filter was added by cleanup(8) via a
FILTER action in header/body checks.
> Furthermore, I can't see why some messages would be
> delivered and others would take the transport of a filter that is not
> configured. I have a lot of research to do on my end, but I appreciate
> your guidance as your suggestion instantly pointed to the issue.
Either the filter is applied selectively, or the setting was removed
only recently and some queue files provide an archeological record of
near-past configuration settings.