From: Anthony Howe
Date: 2006-10-23 18:54:38 -0400
Subject: Re: Repost: Milter-sender and unavailable MX behavior
More information..: http://www.milter.info/#Support
Rose, Bobby wrote:
> I'm seeing responses to other questions but not mine (either this one or
> the support request submitted). Maybe the subject line threw things
I've been away in England and answering the simpler questions first.
> If during a milter-sender callback, if there is an smtp reset that
> occurs on the connection, should milter-sender treat it as a temp
> failure and force the sending relay to retry or should it refuse stating
> that the senders MX is unresponsive?
If during the call-back following the false-address portion of the test,
the MX drops the connection on RSET (ovh.net) or on the next MAIL FROM:
(mxlabs.com??) then milter-sender reconnects to complete the 2nd half of
the test to verify the sender's address.
Based on the results of the false address and sender address tests it
will either accept, reject, or grey-list the address.
> I have two examples: gm.com has 2 MX records and each is set to the
> same 8 A records for a round robin setup. If one of those a records are
If a domain uses one MX that is multi homed, the milter only tests the
MX with the first A record given. If the domain has multiple MXes each
multi homed (aol.com), it will test the first A record given for each MX
from low-to-high within MxCallBackMaxAttempts. RFC 2821 discusses this
issue of multi homed MXes and appears to leave open this issue to
> unresponsive and happens to be the one that milter-sender uses during
> callback, it fails and goes to the second MX which happens to end up
> resolving to the same A record/IP. After that milter-sender treats it
> as an MX that doesn't respond and 550's the inbound transaction. Now
> one question we're trying to figure out is if milter-sender/sendmail
> should be trying all the IP's assigned to the A record? When we do some
This issue has been brought up before in the trouble ticket system and
is mentioned in RFC 2821. Since RFC 2821 appears inconclusive as to what
is expected (granted I need to refresh my memory on this section again)
it can be argued both ways that my interpretation is both wrong or right.
Sites like aol.com that have multiple multi-homed MXes hedge their bets
with respect to this issue and tend to work just fine. Those that have
one multi-homed MX, can result in this behaviour where one failing MX
fails the test, despite there being additional A records. It begs the
question if you have one multi homed MX, why not simply specify multiple
MXes of equal weight for each IP instead of relying on multi home?
> In another example, mc.duke.edu domain has 5 equal preference MX
> records. I've telnet'd to port 25 on them and sometimes it connects and
> sometimes it doesn't. When it doesn't, I get "Unable to connect to
> remote host: Connection refused" and in snooping the traffic, I see an
> smtp rset sent back. I'm not sure what is occurring on their system
> that generates the smtp reset so I'm wondering if it's a load issue but
> I thought mail systems tended to 450 under heavy load. Here's a log
> excerpt for the duke.edu session.
Typically under heavy load, a system will issue 421 instead of a 220
welcome message. Or it might 421 any time during the connection to
indicate it might "reboot", internal error, or some other resource
isssue that requires that the client quit and try again later.
450 or 550 tend to be security/filtering policy issues.
You could increase MxCallBackMaxAttempts from 3 to 6 maybe, but RFC 2821
(and RFC 974) does not require that all the MXes be tested; only that
more than one MX be tried starting with the lowest (best) MX. If after
try 3 there is no answer, will 4, 5, or more be any better? Since this
happens during an SMTP session at the MAIL FROM: command, a response
must be determined within five minutes before a normal client MTA times
out; call-backs do not have the luxury to try all MXes - max. 87 seconds
for a DNS lookup, 120 (default) seconds for a milter/SMTP socket time
out, it gets a little tight if each connection "goes slow".
If you continue to have trouble with specific sites, I suggest
contacting they postmaster and/or white listing them if you think
they're legit and/or not infected by a mass-mailer.
Anthony C Howe Skype: SirWumpus SnertSoft
+33 6 11 89 73 78 AIM: SirWumpus Sendmail Milter Solutions
http://www.snert.com/ ICQ: 7116561
Copyright 2009, 2012 by SnertSoft. All rights reserved.