Mailing List Archive: qmail not trying backup MX's?

qmail not trying backup MX's?

Mar 12, 1997, 12:44 AM

Post #1 of 7 (1245 views)

Right this instant mail is not getting from here to well.com. A typical
failure looks like

Mar 11 23:33:56 taz qmail: 858152036.635964 starting delivery 27092: msg
23483 to remote leftjab@well.com

Mar 11 23:33:56 taz qmail: 858152036.677759 delivery 27091: deferral:
Connected_to_206.15.64.22_but_greeting_failed./

well.com has three MX records:

well.com preference = 40, mail exchanger = smtp.well.com
well.com preference = 10, mail exchanger = mail.well.com
well.com preference = 50, mail exchanger = mailhost.hooked.net

"mail.well.com", which is 206.15.64.22, is doing as the above suggests -
connecting and then closing. However, "smtp.well.com" is capable of
receiving mail fine (a telnet to port 25 and a spoof SMTP conversation I
had with it suggests, anyways). It doesn't appear that qmail is attempting
to deliver to it. Is there something more going on? I also just upgraded
to the new version 8 of named, and I can't say whether this happens with
the old version 4 I was using before. Is there something funky with
well.com's particular DNS tables, maybe? Restarting qmail completely
doesn't change things.

Oh yeah, I'm using qmail 0.96, haven't upgraded to 1.0 because Dan said
there were no code changes.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hyperreal.com http://www.apache.org http://www.organic.com/jobs

Re: qmail not trying backup MX's? [ In reply to ]

hanche at imf

Mar 12, 1997, 2:13 AM

Post #2 of 7 (1226 views)

Permalink

[ Brian Behlendorf <brian@hyperreal.com> 1997-3 -11 23:44 -0800 ]
|---
|
| Right this instant mail is not getting from here to well.com. A
| typical failure looks like
|
| Mar 11 23:33:56 taz qmail: 858152036.635964 starting delivery
| 27092: msg 23483 to remote leftjab@well.com
|
| Mar 11 23:33:56 taz qmail: 858152036.677759 delivery 27091:
| deferral: Connected_to_206.15.64.22_but_greeting_failed./
|
| well.com has three MX records:
|
| well.com preference = 40, mail exchanger = smtp.well.com
| well.com preference = 10, mail exchanger = mail.well.com
| well.com preference = 50, mail exchanger = mailhost.hooked.net
|
| "mail.well.com", which is 206.15.64.22, is doing as the above
| suggests - connecting and then closing. However, "smtp.well.com" is
| capable of receiving mail fine

Maybe, but qmail is designed to not go on in the list of MXs once it
gets a connection. The code that tries MXs in turn is at the bottom
of qmail-remote.c. Once a connection attempt has succeeded, it
branches off to smtp() and never returns.

This sounds like reasonable behaviour to me, but others may disagree.
If you decide to go to the next MX for an error during the SMTP phase,
the question becomes for which kind of SMTP errors should you do this?

- Harald

Re: qmail not trying backup MX's? [ In reply to ]

olaf at bigred

Mar 12, 1997, 2:48 AM

Post #3 of 7 (1226 views)

Permalink

> This sounds like reasonable behaviour to me, but others may disagree.
> If you decide to go to the next MX for an error during the SMTP phase,
> the question becomes for which kind of SMTP errors should you do this?

Another case of "beautiful design vs. the Real World". Likely the
first MX is refusing connections by means of TCP wrapper. Yes, such a
host should not be listed as MX and all that, but it's more important
to get mail through than explaining to every other postmaster in the
world what's exactly broken at _their_ site (I've long given up about
educating people about not routing mail via A records...)

IMHO, a connection that doesn't respond 220 is just as good an no
connection at all.

olaf

Re: qmail not trying backup MX's? [ In reply to ]

chexum at shadow

Mar 12, 1997, 6:01 AM

Post #4 of 7 (1233 views)

Permalink

Olaf Titz writes:
> > This sounds like reasonable behaviour to me, but others may disagree.
> > If you decide to go to the next MX for an error during the SMTP phase,
> > the question becomes for which kind of SMTP errors should you do this?

> Another case of "beautiful design vs. the Real World". Likely the
> first MX is refusing connections by means of TCP wrapper. Yes, such a
> host should not be listed as MX and all that [..]

Not necessarily. This host here over has gone mad some days ago, and
the smtp server ran, but closed all connections immediately. And..
it's qmail.. :) I did not try to chase, what happened, possibly
the memory was a bit short; just killed and restarted qmail.

> IMHO, a connection that doesn't respond 220 is just as good an no
> connection at all.

Yeah, I would like if I got all those mails from my backup servers,
but how useful would this feature for us, if we can't change the
*sender*..? :) And also, if everyone works the way "we" don't
like, why bother? Maybe it's really in the standard.. :)

However, I agree that *in the presence of backup mx-es*, trying
the next one could be better, but who am I to decide that? :)

Janos

Re: qmail not trying backup MX's? [ In reply to ]

andi at vipe

Mar 12, 1997, 6:11 AM

Post #5 of 7 (1226 views)

Permalink

On Wed, 12 Mar 1997, Harald Hanche-Olsen wrote:
> If you decide to go to the next MX for an error during the SMTP phase,
> the question becomes for which kind of SMTP errors should you do this?

I think for failed SMTP greetings would be good. What if the remote
administrator wants all mail from *.edu to go to one machine and all the
rest to go to another inorder to balance load. He might want to put *.edu
in hosts.deny on one host and hosts.allow in the other. i think it's wrong
behaviour not to try the next MX record if no real "chat" has been started
by the two MTA's? Except for this situation it is probably fair not to try
the other MX's.

Andi

P.S- Don't quote me on the hosts.allow thingy. i'm not saying the
destination sys admins knows the best ways. he could of course refuse
packages but assume he doesn't know that.

Re: qmail not trying backup MX's? [ In reply to ]

richard at illuin

Mar 12, 1997, 1:46 PM

Post #6 of 7 (1233 views)

Permalink

On Wed, 12 Mar 1997, Olaf Titz wrote:

> > This sounds like reasonable behaviour to me, but others may disagree.
> > If you decide to go to the next MX for an error during the SMTP phase,
> > the question becomes for which kind of SMTP errors should you do this?
>
> Another case of "beautiful design vs. the Real World". Likely the
> first MX is refusing connections by means of TCP wrapper. Yes, such a
> host should not be listed as MX and all that, but it's more important
> to get mail through than explaining to every other postmaster in the
> world what's exactly broken at _their_ site (I've long given up about
> educating people about not routing mail via A records...)
>
> IMHO, a connection that doesn't respond 220 is just as good an no
> connection at all.

I disagree; if one of the machines at work rejects a connection from a
remote host it is for a very good reason and i don't particulary want that
machine to try the other MX records in the hope of getting around some
administartive restriction.

if you're not supposed to be sending mail to a machine where I work it
just doesn't appear in the list of MX RR's external systems see.

If admins are doing this because they cannot figure out how to setup their
systems to avoid the DNS locally then the need some training, and missing
mail will act as some incentive.

RjL
+----------------------------+
| richard@illuin.demon.co.uk | Aut viam inveniam aut faciam
+----------------------------+

Re: qmail not trying backup MX's? [ In reply to ]

olaf at bigred

Mar 13, 1997, 3:16 AM

Post #7 of 7 (1225 views)

Permalink

> I disagree; if one of the machines at work rejects a connection from a
> remote host it is for a very good reason and i don't particulary want that

If it wants to reject _a message_, it should do so explicitly (by
answering 550 to MAIL FROM or RCPT TO). If it wants to reject
connections, fine, but then it should (a) not be listed as MX(*) and
(b) it should accept messages from its MXs.

(*) And this is the sort of errors I, as postmaster of a sending site,
don't want to fix for a huge number of recipient sites. I have better
things to do...

> machine to try the other MX records in the hope of getting around some
> administartive restriction.

All listed MXs for one destination should agree on what
sender/recipient address they accept. Otherwise it would depend on
random factors (e.g. network outage) whether a given message reaches
its destination. Bad Thing.

> If admins are doing this because they cannot figure out how to setup their
> systems to avoid the DNS locally then the need some training, and missing
> mail will act as some incentive.

Perhaps. But as long as people are clueless enough to not read the
comments in the smail routers file and putting machines on the
Internet which route mail via A records (just one thing of many that
can go wrong), I don't want to explain that to them every other day :-(

olaf