[milters] Archive

Lists Index Date Thread Search

Article: 1210
From: Anthony Howe
Date: 2006-10-23 18:54:38 -0400
Subject: Re: Repost: Milter-sender and unavailable MX behavior

Removal...........: milters-request@milter.info?subject=remove
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
> off.

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

Lists Index Date Thread Search