[milters] Archive

Lists Index Date Thread Search

Article: 943
From: Anthony Howe
Date: 2006-05-25 08:11:31 -0400
Subject: Re: Milter-ahead & "no acceptable MX server" log message

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support
--------------------------------------------------------

Quentin Campbell wrote:
> ... sendmail[3384]: k4PAAKX4003384: Milter: to=<recip-1@XXX.AC.UK>,
> reject=450 4.7.1 server xxx-local.xxx.ac.uk for <bloggs@XXX.AC.UK> not
> answering 

I really HATE it when people munge emails in the supposed name of 
security. It removes part of the information stream available to me that 
  might help me diagnose issues and it introduce other errors in finding 
the problem.

Please enable more debug logging in milter-ahead:

	-v info,trace,dialog

(make sure syslog logs mail.debug level messages). The send me a proper 
unmodified log fragment to me off-list or create a trouble ticket and 
submit the log extract there.

> ... milter-ahead[25120]: 01239 k4PAAKX4003384: no acceptable MX server
> ... sendmail[3384]: k4PAAKX4003384: Milter: to=<recip-2@XXX.AC.UK>,
> reject=450 4.7.1 server xxx-local.xxx.ac.uk for <fred@XXX.AC.UK> not
> answering 
> ... cheviot53 sendmail[3384]: k4PAAKX4003384: milter_read(milter-ahead):
> cmd read returned 0, expecting 5
> ... sendmail[3384]: k4PAAKX4003384: Milter (milter-ahead): to error
> state
> ... sendmail[3384]: k4PAAKX4003384: Milter (spf-milter): write(D)
> returned -1, expected 92: Broken pipe
> ... sendmail[3384]: k4PAAKX4003384: Milter (spf-milter): to error state
> ... sendmail[3384]: k4PAAKX4003384: Milter: to=<recip-3@XXX.AC.UK>,
> reject=451 4.3.2 Please try again later
> ... sendmail[3384]: k4PAAKX4003384: Milter: to=<recip-4@XXX.AC.UK>,
> reject=451 4.3.2 Please try again later
> ... sendmail[3384]: k4PAAKX4003384: from=<owner-ami@JISCMAIL.AC.UK>,
> size=4256, class=0, nrcpts=0, bodytype=8BITMIME, proto=ESMTP,
> daemon=MTA, relay=ictmailer1.itd.rl.ac.uk [130.246.192.56]
> 
> This is the site referred to in my previous postings. The 'mailertable'
> entry is:
> 
> xxx.ac.uk      esmtp:xxx-local.xxx.ac.uk
> 
> and 'xxx-local.xxx.ac.uk' resolves to:
> 
> xxx-local.xxx.ac.uk.    364     IN      MX      10 nyota.xxx.ac.uk.
> xxx-local.xxx.ac.uk.    364     IN      MX      10 uhura.xxx.ac.uk.

And the A records for these mail hosts? What sort of MTA is being used 
by these hosts?

> In the above log extract I see a message for 4 recipients but two get
> treated one way by 'milter-ahead' and two another way.
> 
> There has been one reference to 'no acceptable MX server' in your mail
> list archive (for 'milter-sender') but no response to the query that I
> could find.

'no acceptable MX server' can be returned when the MX list is pruned of 
unacceptable host names (RFC 2606) or A records (RFC 3330). But since 
the log extract is munged I can't do my own DNS lookups to check for the 
obvious things.

> When I look at the code for 'milter-ahead' it appears that the "no
> acceptable MX server" message arises because neither of the MX hosts
> above respond within an acceptable time. It this correct?

No.

> If so is it reasonable to extend the timeout (120 units of what?) for a

The units are specified in the manual for the -T option.

-T timeout:

Specify the socket timeout in _*seconds*_ to wait for SMTP responses 
during the call ahead. A zero (0) value will set the timeout to 
indefinite. The default is 120 *_seconds_*.

> wait to get a response from an MX host? I assume you have chosen your
> current timeout value for a good reason.

RFC 2821 section 4.5.3.2 Timeouts says I have up to 5 minutes supposedly 
before a typical client connection timeouts. I have to perform several 
DNS lookups (each could in theory take 87s to timeout) and call-ahead to 
the mail store, in your case two different machines. This of course 
assumes I'm the only milter doing lengthy operations. When you have more 
milters involved, it can get tricky sometimes. Normally timeouts on the 
LAN are not an issue: the machine is either up and answers quickly or is 
down.

If anything, I'd probably shorten the -T timeout from 120 to 90 or 60, 
but I can't be sure what to recommend because you stripped off the mail 
log timestamps when you munged the log extract and so I can't see the 
whole picture.

-- 
Anthony C Howe          Skype: SirWumpus                    SnertSoft
+33 6 11 89 73 78         AIM: SirWumpus    Sendmail Milter Solutions
http://www.snert.com/     ICQ: 7116561
     http://www.snertsoft.com/

Lists Index Date Thread Search