When will qmail back off to the next MX?
When will qmail decide to back off the primary MX and try to use lower priority MX hosts? In particular, if the primary MX allows a connection and immediately drops it, will qmail ever decide to try the next MX? I'm seeing this problem right now with two systems: wb.xerox.com and snet.net. The primary MX (pmdf.cinops.xerox.com and pop.snet.net) in each case accepts and drops connections to port 25, like such: # telnet pmdf.cinops.xerox.com 25 Trying 13.250.20.175... Connected to pmdf.cinops.xerox.com. Escape character is '^]'. Connection closed by foreign host. Now, in Xerox's case, their normal method is to have two MX records: one for the internal mail server, and one for the internet-accessible mail relay (in this case, mailer-east.xerox.com). When attempts to reach the pmdf.cinops machine fail, the remote MTA should drop back to mailer-east, which can relay it inside the firewall. But it seems that qmail isn't backing off, probably because it gets a connect rather than getting a refusal. Should qmail be backing off? Is accepting+dropping connections documentably wrong, that I should complain to them about it? What's the deal? -- gowen -- Greg Owen -- [EMAIL PROTECTED]
Re: When will qmail back off to the next MX?
Greg Owen <[EMAIL PROTECTED]> wrote: > When will qmail decide to back off the primary MX and try to use >lower priority MX hosts? When it decides that the primary is permanently down. > In particular, if the primary MX allows a connection and immediately >drops it, will qmail ever decide to try the next MX? No. > But it seems that qmail isn't backing off, probably because it gets >a connect rather than getting a refusal. Correct. > Should qmail be backing off? Is accepting+dropping connections >documentably wrong, that I should complain to them about it? What's the >deal? RFC 974 is unclear on this. It says: If the list of MX RRs is not empty, the mailer should try to deliver the message to the MXs in order (lowest preference value tried first). The mailer is required to attempt delivery to the lowest valued MX. Implementors are encouraged to write mailers so that they try the MXs in order until one of the MXs accepts the message, or all the MXs have been tried. A somewhat less demanding system, in which a fixed number of MXs is tried, is also reasonable. It doesn't say mailers MUST try alternative MX's, but it does encourage trying others when one fails to accept a message. See also: http://www.ietf.org/rfc/rfc0974.txt -Dave
RE: When will qmail back off to the next MX?
> But it seems that qmail isn't backing off, probably > because it gets a connect rather than getting a refusal. > > Should qmail be backing off? Is accepting+dropping connections > documentably wrong, that I should complain to them about it? > What's the deal? Part of the problem cleared up - the accept+drop behavior appears to be what you get when you turn off the SMTP proxy capabilities of Raptor firewall. I'm guessing that the "connect" is accepted by the firewall, which then drops it when it figures out the actual target isn't available. Are there gauntlet/raptor users out there who are familiar with qmail through the firewall? We had our ISP turn off the SMTP proxy capabilities because they were making it hard for me to figure out why some mail wasn't delivering well, so maybe it does the same with or without SMTP proxy enabled... -- gowen -- Greg Owen -- [EMAIL PROTECTED]
Re: When will qmail back off to the next MX?
Greg Owen writes: > When will qmail decide to back off the primary MX and try to use > lower priority MX hosts? When it cannot contact the primary MX. > In particular, if the primary MX allows a connection and immediately > drops it, will qmail ever decide to try the next MX? No, never. > Should qmail be backing off? Is accepting+dropping connections > documentably wrong, that I should complain to them about it? What's the > deal? Yes, it's wrong. Why are they advertising an MX if they never intend to allow connections to it? -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
RE: When will qmail back off to the next MX?
> >Should qmail be backing off? Is accepting+dropping connections > > documentably wrong, that I should complain to them about > > it? What's the deal? > > Yes, it's wrong. Why are they advertising an MX if they never intend > to allow connections to it? It looks like my firewall is the one "accepting" and then dropping connections; the remote primary MXs simply refuse connection, so if the firewall isn't in place it works fine. Xerox, and some other sites I've seen, use MX records to make mail routing administration easier. The mail store machine is the top priority, but only Xerox machines can reach it. All internet hosts fail to reach it and must back off to the Internet-accessible corporate mail relays. By controlling this via DNS, control over mail delivery is in the hands of the individual organization rather than having a central mail authority need to know about every server in the company. It's arguably unfriendly and arguably stupid, but I've never seen an argument that claimed it wasn't legal. Two other sites which seem to be doing it are snet.net and viewlogic.com. -- gowen -- Greg Owen -- [EMAIL PROTECTED]
RE: When will qmail back off to the next MX?
Greg,
I have encountered this problem before with a couple of different 'proxy'
based firewalls.
I discussed the problem with the firewall developers, who appreciated my
dilemma, but pointed out that it is not a fault, but a characteristic of a
proxy based firewall. The only solution on the firewall side of things, was
to install a SMTP server on the firewall to act as a relay, which in
depending on the circumstances may not be suitable.
I then discussed the problem with a couple of different developers who have
written SMTP implementations, and the general consensus was that although
the RFC guidelines are quite vague, Dan has put a bit too much thought in to
the MTA, and shouldn't differentiate between a connection timeout or drop,
and just step to the next MX record.
Don't get me wrong, I love Qmail, but this is just one thing that has
frustrated me.
I was provided some information on how to modify the Qmail code to address
this issue, but being a non-programmer, I decided not to go butchering the
code. Here's the details...
>
> modify the routine smtp() to close the smtpfd socket and return if the
> connection is dropped?
>
> if (smtpcode() != 220) { close(&smtpto); return; };
>
> near the top should probably do the trick.
>
> notes... because of the way your firewall works you can't rely on qmail's
> tcpto mechanism to prevent excessive connections to the firewall if its
> demarc/internet connection fails -- qmail can't tell if it;s a problem
> with the firewall or the remote end of the smtp connection. otherwise I'd
> have re-ordered the code around the call to smtp() not to mark the mta as
> 'up'.
Anyway, that's my 2c worth, I hope I haven't offended anyone (Dan
especially).
Karl Lellman
Systems Consultant
Extranet Technologies Limited
Level 3, 60 Cook Street, Auckland, New Zealand
P.O. Box 7726, Wellesley Street, Auckland, New Zealand
Phone +64 9 3771122, Fax +64 9 3771109, Mobile +64 21 771188
e-mail: [EMAIL PROTECTED]
-Original Message-
From: Greg Owen [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 16 September 1999 08:31
To: 'Qmail List'
Subject: RE: When will qmail back off to the next MX?
> But it seems that qmail isn't backing off, probably
> because it gets a connect rather than getting a refusal.
>
> Should qmail be backing off? Is accepting+dropping connections
> documentably wrong, that I should complain to them about it?
> What's the deal?
Part of the problem cleared up - the accept+drop behavior appears to
be what you get when you turn off the SMTP proxy capabilities of Raptor
firewall. I'm guessing that the "connect" is accepted by the firewall,
which then drops it when it figures out the actual target isn't available.
Are there gauntlet/raptor users out there who are familiar with
qmail through the firewall? We had our ISP turn off the SMTP proxy
capabilities because they were making it hard for me to figure out why some
mail wasn't delivering well, so maybe it does the same with or without SMTP
proxy enabled...
--
gowen -- Greg Owen -- [EMAIL PROTECTED]
Re: When will qmail back off to the next MX?
Russell Nelson writes: > >Should qmail be backing off? Is accepting+dropping connections > > documentably wrong, that I should complain to them about it? What's the > > deal? > > Yes, it's wrong. Why are they advertising an MX if they never intend > to allow connections to it? They have a double whammy: 1) They don't have anyone with enough brains to set up split DNS. 2) They don't have anyone with enough brains to set up a mail relay with hardcoded paths. This is basically the idiot's solution to the issue of how to set up an E-mail firewall -- with bogus DNS records. -- Sam
RE: When will qmail back off to the next MX?
On Wed, 15 Sep 1999, Greg Owen wrote: > Xerox, and some other sites I've seen, use MX records to make mail > routing administration easier. The mail store machine is the top priority, > but only Xerox machines can reach it. Well, then they've screwed up or they're lazy. If only Xerox machines can reach it, only Xerox machines should see the MX -- certainly only Xerox machines should see a TCP connect complete. They need a split DNS. Xerox is a tech company. I work for a media/entertainment company which has had split DNS for about 8 years. You'd think Xerox could figure it out. > All internet hosts fail to reach it and must back off to the > Internet-accessible corporate mail relays. By controlling this via DNS, > control over mail delivery is in the hands of the individual > organization rather than having a central mail authority need to know > about every server in the company. Cough. *BALONEY* Cough. You can delegate subdomains, have multiple top domains, and delegate portions of the internal DNS to other internal DNS authorities. > It's arguably unfriendly and arguably stupid, but I've never seen an > argument that claimed it wasn't legal. Two other sites which seem to be > doing it are snet.net and viewlogic.com. Hmm. What's more interesting is that a lot of the problem is Raptor (and not proxy) specific. Gauntlet will refuse the connection, period, if the connecting host is not allowed. Raptor, which seems to want to run its proxies on *all* interfaces, has to use post-connect rules; that or the admin has to use packet filtering to avoid the connect-and-drop behavior (and most don't bother, more's the shame). -M Michael Brian Scher (MS683/MS3213) Anthropologist, Attorney, Policy Analyst Mainlining Internet Connectivity for Fun and Profit [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Give me a compiler and a box to run it, and I can move the mail.
RE: When will qmail back off to the next MX?
> 2) They don't have anyone with enough brains to set up a mail > relay with hardcoded paths. Not that its my job to defend them, but I don't think its a lack of brains. Their system allows the actual end mail host owners, who are often a hop, skip, division and organizational unit away, to control mail delivery for their own domain without requiring a centralized authority to "know" about all those edge servers. And in Xerox, anything that saves an edge admin from having to convince centralized Xerox that they should listen to him is an absolute blessing... -- gowen -- Greg Owen -- [EMAIL PROTECTED]
Re: When will qmail back off to the next MX?
On Thu, Sep 16, 1999 at 08:38:25AM -0400, Greg Owen wrote: > Not that its my job to defend them, but I don't think its a lack of > brains. Their system allows the actual end mail host owners, who are often Not only that - but I recall seeing this exact strategy mentioned in a book on Security and Firewalls... Let's face it, as far as I'm aware, qmail is the only MTA that doesn't do "goto next MX if first MX timesout/fails". Put another way - over 80% of the MTAs on the Internet today handle MX issues differently that Qmail - which is right? [Boy, I must be full of shi... - erm - beans - this morning!] [donning flame-proof underpants] -- Cheers Jason Haar Unix/Network Specialist, Trimble NZ Phone: +64 3 3391 377 Fax: +64 3 3391 417
Re: When will qmail back off to the next MX?
Jason Haar writes: > On Thu, Sep 16, 1999 at 08:38:25AM -0400, Greg Owen wrote: > >Not that its my job to defend them, but I don't think its a lack of > > brains. Their system allows the actual end mail host owners, who are often > > Not only that - but I recall seeing this exact strategy mentioned in a book > on Security and Firewalls... It's still wrong. At *very* least it's a violation of the SMTP protocol. Where's the SMTP banner? -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: When will qmail back off to the next MX?
On Thu, Sep 16, 1999 at 05:14:57PM -0400, Russell Nelson wrote: > It's still wrong. At *very* least it's a violation of the SMTP > protocol. Where's the SMTP banner? Sorry? Did I miss an earlier message? Where does it say it's a violation? I thought this entire matter was due to it being an area not formally mentioned in the RFCs - as it isn't mentioned, neither Qmail or Sendmail/et al are right or wrong. My point was that "everyone else" does it a different way than Qmail. If Qmail did it "the same way", it would make Qmail more acceptable to users. I've always got some mail queued up trying to get through to sites affected by Qmail's ruling on how to handle MX sites that drop after a connect. Screwing around with /var/qmail/control/smtproutes all the time is not my idea of fun... -- Cheers Jason Haar Unix/Network Specialist, Trimble NZ Phone: +64 3 3391 377 Fax: +64 3 3391 417
Re: When will qmail back off to the next MX?
Jason Haar writes: > On Thu, Sep 16, 1999 at 05:14:57PM -0400, Russell Nelson wrote: > > > It's still wrong. At *very* least it's a violation of the SMTP > > protocol. Where's the SMTP banner? > > Sorry? Did I miss an earlier message? Where does it say it's a violation? Quoting RFC821: One important reply is the connection greeting. Normally, a receiver will send a 220 "Service ready" reply when the connection is completed. The sender should wait for this greeting message before sending any commands. The table below lists alternative success and failure replies for each command. These must be strictly adhered to; a receiver may substitute text in the replies, but the meaning and action implied by the code numbers and by the specific command reply sequence cannot be altered. A host that persistently refuses to run the SMTP protocol on the SMTP port cannot be said to be running SMTP. > I've always got some mail queued up trying to get through to sites affected > by Qmail's ruling on how to handle MX sites that drop after a connect. > Screwing around with /var/qmail/control/smtproutes all the time is not my > idea of fun... Tell them to fix their SMTP servers, don't work around their breakage. -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: When will qmail back off to the next MX?
> Sorry? Did I miss an earlier message? Where does it say it's a violation? I > thought this entire matter was due to it being an area not formally > mentioned in the RFCs - as it isn't mentioned, neither Qmail or Sendmail/et > al are right or wrong. My point was that "everyone else" does it a different > way than Qmail. If Qmail did it "the same way", it would make Qmail more > acceptable to users. i just did a quick search of some relevant RFC's, and all they seem to say is that MTA's may, but are not required to, try any fall back MX hosts. the only thing they seem to say is that the most preferred MX must be tried first. so qmail is within its "legal" boundaries in the way it handles MX records. without an RFC that specifies different behaviors for different situations, MX handling will always be a gray area. for instance: * if the primary host gives you a temporary error, should you fall back to the next MX? how fast, immediately or wait a while? if you wait a while, maybe the temporary error will go away? * what if a fallback gives you a temp error? should you reset your MX preference to the primary? how soon? * if any host gives you a permanent error, should you try all other hosts? (this may be answered in some rfc, i dunno) * there's clearly a difference between a "connect refused", "host not responding", "host answers but disconnects without notice", all these kind of error conditions. how should they be handled wrt MX? * how often do you check for an updated MX list? every time you send the mail? if so, should you keep track of what the preferences used to be? an RFC would be the ideal way to answer these. doing it "like everyone else does" isn't valid. doing it "the way sendmail does" is even worse. btw, in case you weren't aware, your "make qmail more acceptable to users" argument isn't going to impress people around here. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
Re: When will qmail back off to the next MX?
>Quoting RFC821: > > One important reply is the connection greeting. Normally, a > receiver will send a 220 "Service ready" reply when the connection > is completed. The sender should wait for this greeting message > before sending any commands. > > The table below lists alternative success and failure replies for > each command. These must be strictly adhered to; a receiver may > substitute text in the replies, but the meaning and action implied > by the code numbers and by the specific command reply sequence > cannot be altered. > >A host that persistently refuses to run the SMTP protocol on the SMTP >port cannot be said to be running SMTP. Since qmail never receives said greeting, and can therefore assume the remote host is not running SMTP, it seems obvious to me that it should move on to the next MX record in the list. Jon _ |Jon Rust | VCNet, Inc |(805) 383-3500| |[EMAIL PROTECTED] || www.vcnet.com| |---| | Failure is not an option | | It comes bundled with your Microsoft product| |___|
RE: When will qmail back off to the next MX?
> > Sorry? Did I miss an earlier message? Where does it say > > it's a violation? > > Quoting RFC821: > > One important reply is the connection greeting. Normally, a > receiver will send a 220 "Service ready" reply when the > connection is completed. But the Xerox servers aren't accepting a connection. The apparent accepted connection is a side effect of the Raptor proxy firewall. If that firewall wasn't in the way, they'd just refuse connection and qmail would back off to the next MX immediately. > Tell them to fix their SMTP servers, don't work around their > breakage. If anyone is broken here, its my firewall, not their mail setup. No one here LIKES their mail setup, but that doesn't make it broken; it conforms with all relevant RFCs that I'm aware of. -- gowen -- Greg Owen -- [EMAIL PROTECTED]
RE: When will qmail back off to the next MX?
> If Qmail did it "the same way", it would make Qmail more > acceptable to users. Ouch - even that one is beyond me ;) If qmail did anything the same way as other MTA's --- well, I'm not so sure I can express it. We're here because qmail doesn't do anything like other MTA's - it's one of qmail's most redeeming qualities. <:) Lyndon Grifin
RE: When will qmail back off to the next MX?
> I was provided some information on how to modify the Qmail > code to address this issue, but being a non-programmer, I > decided not to go butchering the code. Here's the details... Karl, I've looked through qmail-remote.c and, the long and short of it is, the design makes it extremely difficult to modify the behavior of qmail to accomodate this combination of problems. The code snippet you listed won't do it; if the connection is dropped, smtpcode() will never return to allow that snippet to execute. I guess I'm off to natter at the firewall people to see if they can modify the behavior of the firewall. -- gowen -- Greg Owen -- [EMAIL PROTECTED]
Re: When will qmail back off to the next MX?
Russell Nelson wrote: > A host that persistently refuses to run the SMTP protocol on the SMTP > port cannot be said to be running SMTP. So why not fall back to another one that does? > Tell them to fix their SMTP servers, don't work around their > breakage. Isn't the design philosophy of the Internet supposed to be one where it is desireable to work around breakage? -- Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] at| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] dot| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: When will qmail back off to the next MX?
Racer X wrote: > so qmail is within its "legal" boundaries in the way it handles MX records. > without an RFC that specifies different behaviors for different situations, > MX handling will always be a gray area. for instance: Would it be within its "legal" boundaries to handle it differently in ways some have suggested? > * if the primary host gives you a temporary error, should you fall back to > the next MX? how fast, immediately or wait a while? if you wait a while, > maybe the temporary error will go away? Make it configurable. > * what if a fallback gives you a temp error? should you reset your MX > preference to the primary? how soon? Make it configurable. > * if any host gives you a permanent error, should you try all other hosts? > (this may be answered in some rfc, i dunno) Make it configurable. > * there's clearly a difference between a "connect refused", "host not > responding", "host answers but disconnects without notice", all these kind > of error conditions. how should they be handled wrt MX? Make it configurable. > * how often do you check for an updated MX list? every time you send the > mail? if so, should you keep track of what the preferences used to be? Make it configurable. > an RFC would be the ideal way to answer these. doing it "like everyone else > does" isn't valid. doing it "the way sendmail does" is even worse. Agreed. But in some cases I have found things can work better by violating RFCs. I don't like to distribute software that violates the RFCs, unless it would do so only if the administrator gets to choose to do so, and is aware that such a choice is a violation. I have no qualms about distributing or using any software that works that way. > btw, in case you weren't aware, your "make qmail more acceptable to users" > argument isn't going to impress people around here. Sounds like the debate I have with the FreeBSD people over their refusal to support ATAPI devices attaced as master on an IDE channel just because the specifications described it as a slave device ... at a time before secondary IDE was common place (Linux and MS Windows work fine with master ATAPI). Sticking to standards does have an important purpose. Deviating from them should never be done lightly. But it should not be ruled out, either. In many cases, such deviations have to be done to fully evaluate a proposed change in the standards. And sometimes, old standards are not re-visited because de-factor standards born out of deviant usage have established themselves and there is no pressure to formalize them when other standards work is more pressing. There is also another saying common in computers and networking, especially in regard to conformance to standards: Be conservative in what you produce and be liberal in what you accept. I have interpreted that to mean that if something does not conform to the standard, but I also don't have to go out of my way to detect and understand what is meant, I _may_ (and some would like this to be _should_) go ahead and accept it with the obvious semantics. I don't know of any protocol that specifically says that accepting a connection and then summarily dropping it with no output has any particular meaning in that standard. But I would readily classify this as a failure not unlike a connection refusal. I recognize this because I happen to know that there are cases where this is unavoidable. One example is that the UNIX socket API is a deficient standard for lacking the ability to allow user space processes to act on an incoming connection in a way that is seen as a connection refusal. If you can write a "bounce/relay" type of program that listens on a port and for each connection coming in, connects to another specified host and port, and passes all traffic both ways, but in the case of a connection refusal by the target host, gives a connection refusal to the incoming connection it gets, then I am proven wrong (and will have use for your code). People want things that work well and work right. Unfortunately there is disagreement on what both of those things mean. I see both sendmail and qmail as fitting neither, but qmail is closer. In choosing which mail server I will run on the new servers I am working on, I have to evaulate how easy or difficult it will be to make things work as I need them to work. I've probably ruled out FreeBSD (but I will see if 4.0 fixes things). I have not ruled out qmail at all because qmail is probably easy to hack. But indeed, this issue has added to what I will need to do with qmail to make it "workable" (as I define it). -- Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] at| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] dot| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] net | [EMAIL PROTEC
Re: When will qmail back off to the next MX?
[EMAIL PROTECTED] writes: > Russell Nelson wrote: > > > A host that persistently refuses to run the SMTP protocol on the SMTP > > port cannot be said to be running SMTP. > > So why not fall back to another one that does? Because you claimed that it was speaking SMTP. Upon examination, it isn't. Your MX records are false. Why should I send your server any mail at all, since it may not be the right server at all? > > Tell them to fix their SMTP servers, don't work around their > > breakage. > > Isn't the design philosophy of the Internet supposed to be one where it is > desireable to work around breakage? Nope, because if you do that, people never notice the breakage. If something is working (even if it takes special efforts to keep it working, e.g. contacting the wrong host first), they quite reasonably conclude that it isn't broken, and they don't fix it. -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: When will qmail back off to the next MX?
Russell Nelson wrote: > [EMAIL PROTECTED] writes: > > Russell Nelson wrote: > > > > > A host that persistently refuses to run the SMTP protocol on the SMTP > > > port cannot be said to be running SMTP. > > > > So why not fall back to another one that does? > > Because you claimed that it was speaking SMTP. Upon examination, it > isn't. Your MX records are false. Why should I send your server any > mail at all, since it may not be the right server at all? If it isn't speaking SMTP right then, it's BROKEN right then. But that's no different than if it isn't accepting connections right then, which is also a case of it's BROKEN right then. Either way it's BROKEN right then. Now you can just requeue the mail and try again later. If you do, then you are presuming that perhaps it will be fixed later on, but before the expiration of the mail. So why not send the mail on to at least the WORKING secondary MX? That at least gets it out of your queue, putting the storage burden on whoever is supposedly doing queueing service for the crappy server. > > > Tell them to fix their SMTP servers, don't work around their > > > breakage. > > > > Isn't the design philosophy of the Internet supposed to be one where it is > > desireable to work around breakage? > > Nope, because if you do that, people never notice the breakage. If > something is working (even if it takes special efforts to keep it > working, e.g. contacting the wrong host first), they quite reasonably > conclude that it isn't broken, and they don't fix it. How is it that people won't notice the breakage if the primary mail server isn't accepting mail? If the server accepts connections, and then keeps closing them, it's not going to get its mail even from then secondary MX. I think they will eventually notice they are not getting their mail if it disconnects just the same as if it was refusing connections. Doesn't this really come down to a difference between the WAY a mail server is broken? But I'm not seeing any argument about why the WAY it is broken is more important than merely the fact that it is broken. -- Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] at| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] dot| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: When will qmail back off to the next MX?
On Fri, 17 Sep 1999, Greg Owen wrote: > But the Xerox servers aren't accepting a connection. The apparent > accepted connection is a side effect of the Raptor proxy firewall. If that > firewall wasn't in the way, they'd just refuse connection and qmail would > back off to the next MX immediately. What is an "apparent accepted connection?" The connection is accepted when the TCP handshake completes -- what has not happened is an SMTP session. The Raptor is then slamming the door post-connection, in the same manner as a TCP wrapper might. The correct behavior would be to return a RST rather than do the handshake at all. That the Raptor is accepting the connect for the MX's IP address is no excuse -- indeed, it's the problem. I have verified that Gauntlet does not show this behavior. It's a Raptor thing (and possibly one of other proxy firewalls that launch each proxy on all interfaces as if using inetd). Moreover, it could be looked at as a misconfigured Raptor thing, since Raptor has IP-level packet filters that could easily be used to drop the inbound packets before they reach the Raptor's listening application on the "wrong" interface, or (perhaps - I don't know how fancy that filtering is) RST on the attempted connect. The Raptor tech we talked with said one has to use the filters to prevent listening ports from being reached on untrusted interfaces. > > Tell them to fix their SMTP servers, don't work around their > > breakage. > > If anyone is broken here, its my firewall, not their mail setup. No > one here LIKES their mail setup, but that doesn't make it broken; it > conforms with all relevant RFCs that I'm aware of. Now, THAT I will agree with, mostly. What is broken is the aggregate setup - one side or the other should be adjusted. If you want an unreachable MX, then the firewall should not act like a broken mail server. OTOH, as is often done with Gauntlet, you can have the firewall accept, proxy the mail service, accept as if it were the primary MX and then move it along to the real primary. -M Michael Brian Scher (MS683/MS3213) Anthropologist, Attorney, Policy Analyst Mainlining Internet Connectivity for Fun and Profit [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Give me a compiler and a box to run it, and I can move the mail.
Re: When will qmail back off to the next MX?
> Make it configurable. ok, i get the point. i would say that it IS configurable in that different MTA's can handle it however they want. making it configurable at an even lower level would seem to be a rather difficult project and not something you could do without at least patching and rebuilding. that is, i don't think you could just have a simple qmail control file that detailed MX handling unless all the policies were already built into the source anyway. i do agree that fallback MX handling is an issue of policy and not function. > > an RFC would be the ideal way to answer these. doing it "like everyone else > > does" isn't valid. doing it "the way sendmail does" is even worse. > > Agreed. But in some cases I have found things can work better by violating > RFCs. I don't like to distribute software that violates the RFCs, unless it > would do so only if the administrator gets to choose to do so, and is aware > that such a choice is a violation. I have no qualms about distributing or > using any software that works that way. that's fine except in this case there IS no rfc to provide a baseline. there's "the way sendmail does it", which is in a sense a de facto standard, but it's only a standard because way back when, Eric Allman made some decisions about MX handling and for better or worse we're stuck with his decisions. > Sticking to standards does have an important purpose. Deviating from them > should never be done lightly. But it should not be ruled out, either. In > many cases, such deviations have to be done to fully evaluate a proposed > change in the standards. And sometimes, old standards are not re-visited > because de-factor standards born out of deviant usage have established > themselves and there is no pressure to formalize them when other standards > work is more pressing. qmail is deviating from the established standard and handling things its own way. is it better or right? i don't know, there really hasn't been enough discussion. > There is also another saying common in computers and networking, especially > in regard to conformance to standards: Be conservative in what you produce > and be liberal in what you accept. > > I have interpreted that to mean that if something does not conform to the > standard, but I also don't have to go out of my way to detect and understand > what is meant, I _may_ (and some would like this to be _should_) go ahead > and accept it with the obvious semantics. the first part i agree with. the second part i'm not so sure about. my take on it is that programs should be prepared to handle any input. "handle" does not mean process necessarily, it just means that for any input, the program should have defined behavior. this means that the program has a very limited set of inputs and very well defined behaviors. if the inputs are bad, the program refuses the input. i do NOT believe that "liberal" means "should attempt to rectify problems automatically." report the problem, sure, and don't crash because the input is too big or malformed, but don't attempt to fix the problem. GIGO. > I don't know of any protocol that specifically says that accepting a > connection and then summarily dropping it with no output has any particular > meaning in that standard. But I would readily classify this as a failure > not unlike a connection refusal. I recognize this because I happen to know > that there are cases where this is unavoidable. One example is that the > UNIX socket API is a deficient standard for lacking the ability to allow > user space processes to act on an incoming connection in a way that is seen > as a connection refusal. how fast does it have to be dropped to be "summarily" dropped? 1 second? 5? 30? at what point does the connection become "established, but timed out, will try later" instead of "connection refused or immediately dropped?" shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
Re: When will qmail back off to the next MX?
> Now you can just requeue the mail and try again later. If you do, then > you are presuming that perhaps it will be fixed later on, but before the > expiration of the mail. > > So why not send the mail on to at least the WORKING secondary MX? That > at least gets it out of your queue, putting the storage burden on whoever > is supposedly doing queueing service for the crappy server. part of the problem, for me at least, is that it is impossible to guarantee that secondary MX's will, in fact, accept mail for the domain they are supposed to be MX'ing for. i'd rather hold the mail for a couple days in my queue and deliver it directly to the host than pass it off to a secondary that may or may not handle it correctly. at least if i pass it directly to the host i can guarantee that it's his fault if he loses it then, as opposed to getting a third party involved. the more i think about this, the more i think that fallback MX records aren't really necessary anymore. having 3 or 4 fallback MX hosts was nice 10 years ago when mail could be passed in pony express format, eventually making its way across the country by store-and-forward, when everyone ran open relays and cooperated to help the mail get through. that really just isn't the case anymore for a large part of the world. there is very little reason for most MTAs to pass mail to a secondary MX host. if it can't be delivered to the primary, it's fairly likely that it can't be delivered to the secondary either. moreover, today anyway, it's likely that the secondary will be improperly configured and will refuse to accept mail for a domain it's supposed to be MX'ing for. further, it's quite possible that the secondary won't be able to deliver any sooner and may ultimately take longer to deliver. > How is it that people won't notice the breakage if the primary mail server > isn't accepting mail? If the server accepts connections, and then keeps > closing them, it's not going to get its mail even from then secondary MX. so why even attempt to pass the mail to the secondary in that case? ignoring the firewall issue, to qmail it looks like the primary host accepted a connection and then dropped it abruptly. why should qmail think the secondary MX will have better luck? shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
Re: When will qmail back off to the next MX?
On Sat, Sep 18, 1999 at 11:45:23AM -0700, Racer X wrote: > part of the problem, for me at least, is that it is impossible to guarantee > that secondary MX's will, in fact, accept mail for the domain they are > supposed to be MX'ing for. i'd rather hold the mail for a couple days in my > queue and deliver it directly to the host than pass it off to a secondary > that may or may not handle it correctly. at least if i pass it directly to > the host i can guarantee that it's his fault if he loses it then, as opposed > to getting a third party involved. That's not your problem though. If they advertise a secondary MX, it should be configured properly to accept mail. The problem here is really teh behavior of the raptor firewall. Connections that should be refused or dropped are being accepted. Raptor should either change this policy or proxy MX correctly. --Adam
Re: When will qmail back off to the next MX?
Racer X wrote: > ok, i get the point. i would say that it IS configurable in that different > MTA's can handle it however they want. making it configurable at an even > lower level would seem to be a rather difficult project and not something > you could do without at least patching and rebuilding. that is, i don't > think you could just have a simple qmail control file that detailed MX > handling unless all the policies were already built into the source anyway. It really wouldn't be that hard to implement a configurable way to fallback. One simple boolean would cover a lot of cases, that being whether or not a dropped connection is to be treated just like a connect that was not made. More involved configuration would allow choosing discrete behaviour over the different failure cases, but that may be a bit extreme. > that's fine except in this case there IS no rfc to provide a baseline. > there's "the way sendmail does it", which is in a sense a de facto standard, > but it's only a standard because way back when, Eric Allman made some > decisions about MX handling and for better or worse we're stuck with his > decisions. Then Dan gets to do it however he wants, and for whatever reason he wants. Which is probably the case as it stands. It just bugs me when people say a connection refused is a broken server and a connectiond dropped is not. > qmail is deviating from the established standard and handling things its own > way. is it better or right? i don't know, there really hasn't been enough > discussion. Well, if we do discuss it, I'd prefer to move the discussion forward to how the decision will really affect the proper delivery of mail, rather that why such and such server is a bad server. > > There is also another saying common in computers and networking, > especially > > in regard to conformance to standards: Be conservative in what you > produce > > and be liberal in what you accept. > > > > I have interpreted that to mean that if something does not conform to the > > standard, but I also don't have to go out of my way to detect and > understand > > what is meant, I _may_ (and some would like this to be _should_) go ahead > > and accept it with the obvious semantics. > > the first part i agree with. the second part i'm not so sure about. my > take on it is that programs should be prepared to handle any input. > "handle" does not mean process necessarily, it just means that for any > input, the program should have defined behavior. this means that the > program has a very limited set of inputs and very well defined behaviors. > if the inputs are bad, the program refuses the input. There should be a defined behaviour for different kinds of failures on the part of servers being connected to for mail delivery. Most certainly it should not crash if the connection just gets dropped. The question is what should be the reasonable range of choices for things it may do. > i do NOT believe that "liberal" means "should attempt to rectify problems > automatically." report the problem, sure, and don't crash because the input > is too big or malformed, but don't attempt to fix the problem. GIGO. Is a connection refused a problem to be rectified? Is a connection dropped a problem to be rectified? > how fast does it have to be dropped to be "summarily" dropped? 1 second? > 5? 30? at what point does the connection become "established, but timed > out, will try later" instead of "connection refused or immediately dropped?" What was in my mind by "summarily dropped" was the receiving server closing the TCP connection before outputting anything at all. I didn't consider time to be a factor unless the drop occurs after the point in time in which the sending server times out due to an idle connection. But the sender will be doing the connection dropping, so it won't see anything else. There are a lot of failure scenarios that can occur. Connection refused. Connection timed out. Various network failures (no route, no interface). Communications timed out. Communications severed (peer dropped, network failures, etc). In general I would tend to prefer to treat them all the same unless there is some compelling reason to do otherwise. Such reasons can be protocol standards or just a reasonable argument in favor of some other way to do it. -- Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] at| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] dot| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: When will qmail back off to the next MX?
Racer X wrote: > part of the problem, for me at least, is that it is impossible to guarantee > that secondary MX's will, in fact, accept mail for the domain they are > supposed to be MX'ing for. i'd rather hold the mail for a couple days in my > queue and deliver it directly to the host than pass it off to a secondary > that may or may not handle it correctly. at least if i pass it directly to > the host i can guarantee that it's his fault if he loses it then, as opposed > to getting a third party involved. So in all scenarios, you'd prefer to ignore all MX entries but the lowest? Wouldn't your argument apply equally to every failure scenario? I see the merit in your argument. I don't see how it distiguishes between differnet failure scenarios that need to be acted on differently. > the more i think about this, the more i think that fallback MX records > aren't really necessary anymore. having 3 or 4 fallback MX hosts was nice > 10 years ago when mail could be passed in pony express format, eventually > making its way across the country by store-and-forward, when everyone ran > open relays and cooperated to help the mail get through. that really just > isn't the case anymore for a large part of the world. This is a good point for most servers. Many people are still running servers on dialups that don't get connected all the time. I do MX-ing for a couple of them. When they are connected, it's for a few hours or more at a time, so they will soon get their mail. It can be argued that they should pick up their mail from my server instead. But the way it works now works just fine and is the least administrative burden (I don't have to add all their userids and worry about collisions). Probably the best counter argument is that the world should see my server for their domain as the only one, and my server should see their server as the one. It's a fair argument. I just haven't put it up like that as I am still thinking about what is the best way to manage more than one DNS server with different data for the "same" zones. > there is very little reason for most MTAs to pass mail to a secondary MX > host. if it can't be delivered to the primary, it's fairly likely that it > can't be delivered to the secondary either. moreover, today anyway, it's > likely that the secondary will be improperly configured and will refuse to > accept mail for a domain it's supposed to be MX'ing for. further, it's > quite possible that the secondary won't be able to deliver any sooner and > may ultimately take longer to deliver. I also find it quite likely these days that the _primary_ is also misconfigured. It is a fair argument to suggest that an effort be made to ensure reliable delivery even in the face of the recipient's server's being misconfigured. I would also suggest that they should remove their secondary MX record if they don't have a procedure in place to verify that the secondary host is correctly configured. OTOH, if we always skip the primary and go only to the last secondary, then they will be forced to be sure all their servers are up to snuff. > > How is it that people won't notice the breakage if the primary mail server > > isn't accepting mail? If the server accepts connections, and then keeps > > closing them, it's not going to get its mail even from then secondary MX. > > so why even attempt to pass the mail to the secondary in that case? > ignoring the firewall issue, to qmail it looks like the primary host > accepted a connection and then dropped it abruptly. why should qmail think > the secondary MX will have better luck? In some situations, the secondary may have a means to ensure that it can get connected. Maybe the source IP address is used by the primary to decide. In other situations, the secondary may not be able to do any better right now, but it might be able to later on at a time when you cannot even reach either (for perhaps unrelated reasons). The set of possibilities is at least large. I just tend to favor the notion of getting the mail as close to its destination as soon as possible. -- Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] at| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] dot| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: When will qmail back off to the next MX?
> The Raptor tech we talked with said one has to use the > filters to prevent listening ports from being reached > on untrusted interfaces. I believe I've found the info required to fix the problem at my firewall. http://www.raptor.com/cs/FAQ/entv5basictrafficmethods.html is a description of the different ways that Raptor can pass traffic. The summary of the fix is Raptor "local tunnels" which are packet filtering. It'll have to wait until I get back from vacation, but once that's in place things should be back to normal. But before I go, in response to Racer X: >> the more i think about this, the more i think that >> fallback MX records aren't really necessary anymore. There are several reasons I think they are still useful: 1) Redundancy. All machines die at some time or other. I'd rather not have the added pressure of knowing that mail will start bouncing if it isn't fixed in X amount of time while I'm trying to fix it. 2) Maintenance. You can take your mail server down for maintenance and not worry about where the mail sits in the meantime - I'd rather it sit and wait on my server than on someone elses! 3) Upgrades. You can test upgrades on a fallback MX before moving them on up. On that note, I'm leaving for the caribbean. Have a good week, all! -- gowen -- Greg Owen -- [EMAIL PROTECTED]
Re: When will qmail back off to the next MX?
On Fri, 17 Sep 1999, Russell Nelson wrote: > Because you claimed that it was speaking SMTP. Upon examination, it > isn't. Your MX records are false. Why should I send your server any > mail at all, since it may not be the right server at all? 1. The host is dead => it does not send any datagrams => it does not speak SMTP. 2. The host is alive but no process listens on SMTP port => it refuses TCP connections => it does not speak SMTP. 3. The host is alive, some process listens on SMTP port but something gets screwed up when a connection is open, and the connection is closed immediately (e.g. qmail-smtpd binary is corrupted and dies immediately) => it does not say SMTP hello => it does not speak SMTP. Summary: the server fails to speak SMTP in all cases. Ergo, if the server is listed as an MX record for some domain name, "I claimed it was speaking SMTP but upon examination, it isn't, therefore MX records are false." In ALL cases 1, 2, and 3. Why does qmail fall back to other MXes in cases 1 and 2 but not in case 3? Why does it fall back at all? It should always ignore the other MXes because the records are always incorrect according to your reasoning!? Let's have a private network having two gateways: a primary one and a backup one. The gateways accept e-mail traffic from the Internet and forward messages to some system running on the private network (that is not visible to the outer world). Any gateway is able to do this but the primary one is listed as the first MX because its performance is better. If the primary gateway breaks, the messages from qmail will be delivered through the backup one in failure cases 1 and 2 but not in case 3. This is strange, isn't it? Why is case 3 special? Is there anything wrong with this setup? If yes, enlighten me, please. :) BTW: I have omitted a case when the server accepts connections, starts SMTP conversations but it always (as far as the client knows) dies in the middle of the conversation. It depends on Russell's definition of "speaking SMTP" whether such a host speaks SMTP or not. Your Advocatus Diaboli, :) --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] "Resistance is futile. Open your source code and prepare for assimilation."
Re: When will qmail back off to the next MX?
Pavel Kankovsky wrote: > 1. The host is dead => it does not send any datagrams => >it does not speak SMTP. > 2. The host is alive but no process listens on SMTP port => it refuses >TCP connections => it does not speak SMTP. > 3. The host is alive, some process listens on SMTP port but something >gets screwed up when a connection is open, and the connection is closed >immediately (e.g. qmail-smtpd binary is corrupted and dies immediately) >=> it does not say SMTP hello => it does not speak SMTP. Described another way, there are many failure scenarios where the actual cause is not a misconfiguration of the mail: 1. The server is out of memory and is unable to copy a datagram containing a SYN packet from the device interface layer to the IP network layer. The packet is discarded and no ACK or RST is ever sent. 2. The server is out of memory and is unable to allocate structures for completing a connection. A RST might be sent back to the source. 3. The server is out of memory and is unable to sbrk() more memory for the process that accepted the incoming connection. The process faults before conducting protocol, and a RST is sent to close the connection. We may well fault the server for not having enough RAM, or enough swap space, or having hosted an IRC bot and invited DoS attacks, or whatever. But the mail implementation (it could be qmail) and configuration may well be entirely correct. In any such failure scenario, there may be reasons for a mail server to chose some action, such as: 1. Immediately try the same server again. 2. Immediately try the next higher MX server. If all MX servers fail, choose an action from 3 or 4. 3. Requeue the message to be tried again later. If a certain time period has expired, return the message to the sender. 4. Return the message to the sender immediately even though the time period for expiration has not lapsed. Whatever the choice of action, why would that choice not be consistent across the 3 failure modes? All 3 failure modes represent a situation which may be corrected any time between the next delivery attempt, and the final delivery attempt (hence making action #4 a bad choice, IMHO). I can understand (but not entirely agree with) arguments against going to the next higher MX. What I cannot understand is why some of the failure scenarios would justify that choice while others would not. > Summary: the server fails to speak SMTP in all cases. > > Ergo, if the server is listed as an MX record for some domain name, "I > claimed it was speaking SMTP but upon examination, it isn't, therefore MX > records are false." In ALL cases 1, 2, and 3. Why does qmail fall back to > other MXes in cases 1 and 2 but not in case 3? Why does it fall back at > all? It should always ignore the other MXes because the records are > always incorrect according to your reasoning!? The server may well be configured to speak SMTP in all 3 cases were it not muffled by a transient error condition that could be corrected by things between a sysadmin cleaning up runaway processes, or a netadmin blocking a DoS attack at the router, or a nervous operator pushing the reset button. -- Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] at| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] dot| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: When will qmail back off to the next MX?
Greg Owen <[EMAIL PROTECTED]> writes on 19 September 1999 at 09:18:55 -0400 > But before I go, in response to Racer X: > > >> the more i think about this, the more i think that > >> fallback MX records aren't really necessary anymore. > > There are several reasons I think they are still useful: > > 1) Redundancy. All machines die at some time or other. I'd rather > not have the added pressure of knowing that mail will start bouncing if it > isn't fixed in X amount of time while I'm trying to fix it. > > 2) Maintenance. You can take your mail server down for maintenance > and not worry about where the mail sits in the meantime - I'd rather it sit > and wait on my server than on someone elses! > > 3) Upgrades. You can test upgrades on a fallback MX before moving > them on up. This is amusing to me; you're both essentially saying that you trust your *own* servers more than you trust other people's servers, so it's better for the mail to do its waiting on *your* servers. If all sysadmins were like that (and good enough to make it a *reasonable* preference), we wouldn't have a lot of these discussions about misconfigured systems :-) . -- David Dyer-Bennet ***NOTE ADDRESS CHANGES*** [EMAIL PROTECTED] http://dd-b.lighthunters.net/ (photos) Minicon: http://www.mnstf.org/minicon http://www.dd-b.net/dd-b (sf) http://ouroboros.demesne.com/ Ouroboros Bookworms Join the 20th century before it's too late!
Re: When will qmail back off to the next MX?
David Dyer-Bennet wrote: > Greg Owen <[EMAIL PROTECTED]> writes on 19 September 1999 at 09:18:55 -0400 > > >But before I go, in response to Racer X: > > > > >> the more i think about this, the more i think that > > >> fallback MX records aren't really necessary anymore. > > > >There are several reasons I think they are still useful: > > > >1) Redundancy. All machines die at some time or other. I'd rather > > not have the added pressure of knowing that mail will start bouncing if it > > isn't fixed in X amount of time while I'm trying to fix it. > > > >2) Maintenance. You can take your mail server down for maintenance > > and not worry about where the mail sits in the meantime - I'd rather it sit > > and wait on my server than on someone elses! > > > >3) Upgrades. You can test upgrades on a fallback MX before moving > > them on up. > > This is amusing to me; you're both essentially saying that you trust > your *own* servers more than you trust other people's servers, so it's > better for the mail to do its waiting on *your* servers. Yes we do, but, the reason I (I cannot speak for others) prefer the mail to be queued to my secondary is that I know it will come over to the primary a whole lot faster. The secondary can do retries every minute and is connected to the primary at 100 mbps ethernet. And that's only my top reason. There are also lesser reasons (including that, yes, I do trust my server more than some arbitrary server I have no idea about). I can also up the expiration time on my secondary so I give myself more time to correct the primary. And how do you know that the secondary works from the same MX list as the sender has? I may well have the real primary unlisted at all. There may be a perfectly good reason to do that. It could be on a private LAN, for one example. Or it might be on a slow link where I want to serialize the mail delivery. The apparent primary would then be in the public MX list as primary because it is the faster machine, and the apparent secondary being slower, gets listed next, even though it can deliver to the real primary without the apparent primary being functional for SMTP. Sure, I could list the public MX machines as equals in the list. If they were indeed equal, that might be a good idea. Or I could list one machine with multiple A records for each separate real machine (some people do have a problem with this in their talk, but it has worked for me before). But if the machines are unequal, I would list them unequally. -- Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] at| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] dot| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: When will qmail back off to the next MX?
Pavel Kankovsky writes: > On Fri, 17 Sep 1999, Russell Nelson wrote: > > > Because you claimed that it was speaking SMTP. Upon examination, it > > isn't. Your MX records are false. Why should I send your server any > > mail at all, since it may not be the right server at all? > > 1. The host is dead => it does not send any datagrams => >it does not speak SMTP. > 2. The host is alive but no process listens on SMTP port => it refuses >TCP connections => it does not speak SMTP. > 3. The host is alive, some process listens on SMTP port but something >gets screwed up when a connection is open, and the connection is closed >immediately (e.g. qmail-smtpd binary is corrupted and dies immediately) >=> it does not say SMTP hello => it does not speak SMTP. > Why does qmail fall back to other MXes in cases 1 and 2 but not in > case 3? Why does it fall back at all? It should always ignore the > other MXes because the records are always incorrect according to > your reasoning!? Because it's reasonable to expect that other MX records will work for 1+2, but not for 3. If the lowest priority MX record is screwed up, why aren't the others as well? Essentially what we're dancing around is the issue of deliberate misconfiguration in an effort to save sysadmin time: "It's hard work to set up split DNS. Why not just have a low numbered MX record for internal hosts, and a higher numbered record for external hosts? It works for sendmail, so it should work for everything, right?" -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: When will qmail back off to the next MX?
On Thu, Sep 23, 1999 at 11:09:08PM -0400, Russell Nelson wrote: > Because it's reasonable to expect that other MX records will work for > 1+2, but not for 3. If the lowest priority MX record is screwed up, > why aren't the others as well? If one MX has a screwed up binary, it is likely that other MX's have a corrupted binary too? I fail to see the reasoning behind that. By the way, the *lowest* prefence is used first. If the host is down, the higher MX's are tried. -- Ruben -- Eat more memory!
Re: When will qmail back off to the next MX?
On Thu, 23 Sep 1999, Russell Nelson wrote: > Because it's reasonable to expect that other MX records will work for > 1+2, but not for 3. If the lowest priority MX record is screwed up, > why aren't the others as well? How does the way the 1st MX fails to accept the message affect the working of other MXes (in a general case)? > Essentially what we're dancing around is the issue of deliberate > misconfiguration in an effort to save sysadmin time: "It's hard work to > set up split DNS. Why not just have a low numbered MX record for > internal hosts, and a higher numbered record for external hosts? It > works for sendmail, so it should work for everything, right?" This is irrelevant. Qmail has no problem with this particular product of ignorancy unless it can somehow connect to the internal host and get disconnected (or get a temporary error during the conversation). --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] "Resistance is futile. Open your source code and prepare for assimilation."
Re: When will qmail back off to the next MX?
>> Essentially what we're dancing around is the issue of deliberate >> misconfiguration in an effort to save sysadmin time: "It's hard work to >> set up split DNS. Why not just have a low numbered MX record for >> internal hosts, and a higher numbered record for external hosts? It >> works for sendmail, so it should work for everything, right?" > >This is irrelevant. Qmail has no problem with this particular product of >ignorancy unless it can somehow connect to the internal host and get >disconnected (or get a temporary error during the conversation). Agreed. In this case, all it was getting (correct me if I'm wrong) was a TCP ack for the establishment, not an SMTP greeting. no "conversation" ever happened. Hence qmail should not assume an SMTP server is successfully running, and should drop back to secondary MX record(s). If it got an SMTP greeting, maybe queuing the message would be more correct, but it isn't. >--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] >"Resistance is futile. Open your source code and prepare for assimilation." Hey, cool link! (Maintained by one of my customers :-) Jon
Re: When will qmail back off to the next MX?
> How does the way the 1st MX fails to accept the message affect the working > of other MXes (in a general case)? if the first MX allows a connection to port 25, there is an implied assumption that there is a program listening on port 25 that speaks SMTP. therefore, the sender should attempt delivery. the connection is never disconnected "immediately." assuming the connection succeeds it must stay connected for some minimum length of time. it could drop after 1 second with no traffic, or the SMTP transaction could get halfway done and then the connection times out. let's say you send EHLO, MAIL FROM, RCPT TO, and all is well, and you start your DATA but you never get an ok from the remote. does that mean you should fall back to the next MX? anyway, until an RFC or something clarifies exactly different situations should be handled i don't think it's particularly worthwhile to pick on qmail for 1) "not doing it like sendmail does," and 2) not handling a broken configuration in the way the breakers expect it to. say what you will about qmail, the DNS configuration IS broken (and no i don't care how many people do it that way - "everyone speeds" but that doesn't make it legal). until we can agree that, yes, someone was lazy and should fix the DNS first, i don't see the point in changing qmail's behavior. shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
Re: When will qmail back off to the next MX?
Racer X wrote: > > How does the way the 1st MX fails to accept the message affect the working > > of other MXes (in a general case)? > > if the first MX allows a connection to port 25, there is an implied > assumption that there is a program listening on port 25 that speaks SMTP. > therefore, the sender should attempt delivery. Given that port 25 is established to be the standard port for SMTP, and is shared for any other protocol, it is very reasonable to assume that the protocol that should be conducted is SMTP. It would then follow that if a connection was in fact achievable, then the destination host apparently does intend to converse SMTP. A configuration of firewalls that causes the connection to happen even though the destination is not willing (perhaps at this time) to converse SMTP, is misleading at best. The firewall is certainly badly implemented, and I would consider it to be broken. > the connection is never disconnected "immediately." assuming the connection > succeeds it must stay connected for some minimum length of time. it could > drop after 1 second with no traffic, or the SMTP transaction could get > halfway done and then the connection times out. let's say you send EHLO, > MAIL FROM, RCPT TO, and all is well, and you start your DATA but you never > get an ok from the remote. does that mean you should fall back to the next > MX? Does it mean you should not? There are legitimate scenarios NOT involving broken firewalls, in which a server could be trying to converse SMTP, but failing to do so for reasons that may persist for an undetermined length of time. The internet protocols were designed under a philosophy of making reasonable attempts to work around failures. The host that fails to converse SMTP (despite the intent to do so in the configuration, as view by the MX records in the DNS) is a failure in the network. A way to work around that failure is to try another MX host, if more than one is present, guided by the priority information given. It may not be mandatory to do so, but doing so is a way to work around failure. An implementation that does not fall back to another MX is an implementation that is not attempting to work around failure. > anyway, until an RFC or something clarifies exactly different situations > should be handled i don't think it's particularly worthwhile to pick on > qmail for 1) "not doing it like sendmail does," and 2) not handling a broken > configuration in the way the breakers expect it to. say what you will about > qmail, the DNS configuration IS broken (and no i don't care how many people > do it that way - "everyone speeds" but that doesn't make it legal). until > we can agree that, yes, someone was lazy and should fix the DNS first, i > don't see the point in changing qmail's behavior. Doing things a certain way because sendmail does it that way is certainly not a reasonable guide. Indeed, doing things a different way may well be preferrable. Which scenario are you referring to when you say "the DNS configuration IS broken"? Are you referring to the scenario where the firewall is broken, and just tossing this in to confuse the issue? Since when is having more than one MX record for a host to be considered "broken" when one of the hosts might be down? Just because one scenario which Qmail could "work around" happens to be a scenario which is either configured or implemented broken, does not mean that no other scenarios can exist which would involve the same issue. Just because one scenario represents a case which is not an interim failure does not mean that every scenario is likewise. Hosts do sometimes go down. They do sometimes fail. They do sometimes have problems which, while not entirely crashing, do prevent the completion of a protocol at ANY step along its defined path, including before and immediately after the TCP connection is established. Even Qmail could fail in such a way when running on a machine which has an interim problem providing Qmail with the resources to complete execution (e.g. memory exhausted). It's a failure. You might call it "broken" if you want. The issue is whether or not it is worthwhile to attempt to work around the failure. -- Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] at| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] dot| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: When will qmail back off to the next MX?
Jon Rust wrote: > >> Essentially what we're dancing around is the issue of deliberate > >> misconfiguration in an effort to save sysadmin time: "It's hard work to > >> set up split DNS. Why not just have a low numbered MX record for > >> internal hosts, and a higher numbered record for external hosts? It > >> works for sendmail, so it should work for everything, right?" > > > >This is irrelevant. Qmail has no problem with this particular product of > >ignorancy unless it can somehow connect to the internal host and get > >disconnected (or get a temporary error during the conversation). > > Agreed. In this case, all it was getting (correct me if I'm wrong) > was a TCP ack for the establishment, not an SMTP greeting. no > "conversation" ever happened. Hence qmail should not assume an SMTP > server is successfully running, and should drop back to secondary MX > record(s). If it got an SMTP greeting, maybe queuing the message > would be more correct, but it isn't. Why should a failure at any point in the connection and conversation bias the behaviour of deciding to, or not to, try another MX host? Why is that a situation where an SMTP server is indeed running, but failure in mid course, be any different than a connection refused, with regard to deciding if another MX would be reasonable to attempt to communication with? -- Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] at| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] dot| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: When will qmail back off to the next MX?
Pavel Kankovsky wrote: > > Because it's reasonable to expect that other MX records will work for > > 1+2, but not for 3. If the lowest priority MX record is screwed up, > > why aren't the others as well? > > How does the way the 1st MX fails to accept the message affect the working > of other MXes (in a general case)? I think this is a good question. Some believe that if the 1st MX is failing, that the mail to the 2nd or 3rd MX will not reach the destination any sooner. I believe this is due to a mistaken belief that the 1st MX is the same as the ultimate destination host when in fact it may not be. > > Essentially what we're dancing around is the issue of deliberate > > misconfiguration in an effort to save sysadmin time: "It's hard work to > > set up split DNS. Why not just have a low numbered MX record for > > internal hosts, and a higher numbered record for external hosts? It > > works for sendmail, so it should work for everything, right?" > > This is irrelevant. Qmail has no problem with this particular product of > ignorancy unless it can somehow connect to the internal host and get > disconnected (or get a temporary error during the conversation). Even if the split DNS setup were done, the situation is still problematic for Qmail if it won't backoff to the 2nd MX. If the ultimate destination is behind a correctly configured firewall (you can't get there directly at all) and the DNS has no MX record pointing direct, but both the 1st and 2nd MX hosts can get there (special tunnel), then in the case of a failure of the 1st MX host, the 2nd MX host would mean a successful delivery ... missed by Qmail if it doesn't want to try it. -- Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] at| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] dot| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: When will qmail back off to the next MX?
[EMAIL PROTECTED] writes: > Now you can just requeue the mail and try again later. If you do, then > you are presuming that perhaps it will be fixed later on, but before the > expiration of the mail. It's reasonable to retry a host if you can make a connection to it, but cannot talk SMTP to it. > Doesn't this really come down to a difference between the WAY a mail server > is broken? No, it comes down to the weight you put on the importance of sending mail to the primary vs the secondary MX. If you think it's important to talk to the primary, then you'll retry successful connections to the primary. Since you seem to think that any temporary failure means that the secondary MX should be retried, what about a 4XX failure? Should that cause the secondary MX to be used? -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: When will qmail back off to the next MX?
Russell Nelson wrote: > [EMAIL PROTECTED] writes: > > Now you can just requeue the mail and try again later. If you do, then > > you are presuming that perhaps it will be fixed later on, but before the > > expiration of the mail. > > It's reasonable to retry a host if you can make a connection to it, > but cannot talk SMTP to it. To the perpetual exclusion of all else? > > Doesn't this really come down to a difference between the WAY a mail server > > is broken? > > No, it comes down to the weight you put on the importance of sending > mail to the primary vs the secondary MX. If you think it's important > to talk to the primary, then you'll retry successful connections to the > primary. How do you make a determination if it's important or not? > Since you seem to think that any temporary failure means that the > secondary MX should be retried, what about a 4XX failure? Should that > cause the secondary MX to be used? For 450, perhaps. For 421, 451, 452, eventually the 2nd MX should be tried, IMHO. I would think 450 would mean the server thinks it is the local machine for that domain, and hence _probably_ has to be used by the secondary to delivery the mail anyway (there may be more than one "local" server when the mailboxes are shared over NFS ... something that maildir would make more reliable). And "local" delivery could mean injection into some other kind of server (I've done 2 SMTP servers running Lotus Notes injection before they implemented SMTP in Notes itself). The others give no real clue as to the (un)viability of the 2nd MX. If the protocol is not carried out to even get an error code, though, then you really know very little about the server from that attempt. You don't know if the mailboxes are local. You don't know if the 2nd can or cannot deliver without the 1st. I'm not saying that the 2nd MX needs to be tried immediately, but if the problem persists, it should be eventually tried. Perhaps a study of how frequently certain kinds of errors do occur, over what proportion of sites (classified by server software type, too), and how long until those kinds of errors are corrected, could lead to an optimal estimate of how many failures to the primary should justify trying the secondaries. My first thought would be to attempt delivery in some kind of proportion that is inverse to the MX level, perhaps proportional to 1/(2^(mx/N)) where N is a configurable value I would start at 50. -- Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] at| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] dot| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: When will qmail back off to the next MX?
ok real quick let me say that i think we've beat this horse good and dead into the ground. that said, however, i think there's been a lot of useful discussion about an issue that really hasn't been researched in the light of modern SMTP systems. that is, the whole notion of MX records started about 15 or so years ago, and maybe it's time to clarify some of the behaviors we've been talking about. i would suggest that we form another list and attempt to draft some sort of standard or RFC - not necessarily to decide on fixed behaviors that are really issues of policy, but to better define the various possible situations so that MTA developers can easily compare what their MTA does in a certain situation. no, i'm not going to be the one to lead that effort, but i'll gladly participate :) > intend to converse SMTP. A configuration of firewalls that causes the > connection to happen even though the destination is not willing (perhaps at > this time) to converse SMTP, is misleading at best. The firewall is > certainly badly implemented, and I would consider it to be broken. yes, in this particular case, the firewall is the issue - it's pretty broken. but the discussion is over what qmail should do. qmail has no idea that there's a firewall in between. > > halfway done and then the connection times out. let's say you send EHLO, > > MAIL FROM, RCPT TO, and all is well, and you start your DATA but you never > > get an ok from the remote. does that mean you should fall back to the next > > MX? > > Does it mean you should not? it would be nice to have a state diagram that shows what paths the program might take depending on how far the SMTP transaction gets. at least then you'd know what the program does and (i guess) you could modify its behavior appropriately. > A way to work around that failure is to try another MX host, if more than > one is present, guided by the priority information given. It may not be > mandatory to do so, but doing so is a way to work around failure. An > implementation that does not fall back to another MX is an implementation > that is not attempting to work around failure. "failure" is a subjective term. > Which scenario are you referring to when you say "the DNS configuration IS > broken"? Are you referring to the scenario where the firewall is broken, > and just tossing this in to confuse the issue? Since when is having more > than one MX record for a host to be considered "broken" when one of the > hosts might be down? publishing an MX host that is never reachable seems pretty broken to me. it may be technically permitted, i suppose it's not explicitly forbidden anywhere, but publishing the record is like saying "what if 2 plus 2 equals 5?" interesting concept but pointless to bother with it. the firewall is clouding the issue. > Just because one scenario which Qmail could "work around" happens to be a > scenario which is either configured or implemented broken, does not mean > that no other scenarios can exist which would involve the same issue. Just > because one scenario represents a case which is not an interim failure does > not mean that every scenario is likewise. agreed. > Hosts do sometimes go down. They do sometimes fail. They do sometimes have > problems which, while not entirely crashing, do prevent the completion of a > protocol at ANY step along its defined path, including before and > immediately after the TCP connection is established. Even Qmail could fail > in such a way when running on a machine which has an interim problem > providing Qmail with the resources to complete execution (e.g. memory > exhausted). It's a failure. You might call it "broken" if you want. The > issue is whether or not it is worthwhile to attempt to work around the > failure. the issue is more than that - it's "to what lengths should qmail go to work around the failure?" shag = Judd Bourgeois| CNM Network +1 (805) 520-7170 Software Architect| 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 Quidquid latine dictum sit, altum viditur.
Re: When will qmail back off to the next MX?
Racer X wrote: > publishing an MX host that is never reachable seems pretty broken to me. it > may be technically permitted, i suppose it's not explicitly forbidden > anywhere, but publishing the record is like saying "what if 2 plus 2 equals > 5?" interesting concept but pointless to bother with it. the firewall is > clouding the issue. If a server was broken, and I had no intent to fix it, but published an MX pointing to it anyway, I would agree that is broken. OTOH, servers break, and DNS servers don't know to withdraw the MX, and MTAs don't know if the time frame is "never" or "for a while". > the issue is more than that - it's "to what lengths should qmail go to work > around the failure?" ... and what are the costs of doing so versus the benefits. Choosing to sometimes retry the 2nd MX in the same process that just tried the 1st would only cost the additional connection attempt. If it makes the difference between successful or failed delivery of the mail, it would be worth it. If it makes mail arrive earlier it may still be worth it. OTOH, adding an elaborate scheme to the MTA which requires adding new information in the mail queue to make complex delivery and recovery decisions would certainly be costly and probably not worth the effort. OTTOMH, I would favor a randomized fallback scheme which does not depend on queued message state. When a delivery failure occurs, choose a random number, then decide whether to now try the next MX based on a probability derived from the MX level, or the ratio of MX levels, then maybe or maybe not retry the next level before requeueing. Should MX entries of equal value be tried equally? -- Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] at| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] dot| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: When will qmail back off to the next MX?
Racer X <[EMAIL PROTECTED]> writes on 27 September 1999 at 12:19:57 -0700 > publishing an MX host that is never reachable seems pretty broken to me. it > may be technically permitted, i suppose it's not explicitly forbidden > anywhere, but publishing the record is like saying "what if 2 plus 2 equals > 5?" interesting concept but pointless to bother with it. the firewall is > clouding the issue. Actually, I think the "permanently broken" MX host itself is clouding the issue. I get the impression that some people have strong feelings that we shouldn't change things to help out people with lazy "bad" configurations; they should be punished for their sins. I'm even capable of feeling that way myself with just a little encouragement :-) . So, suppose that the hypothetical host is in fact only broken for 1 month (they didn't update the DNS because they expected the new part to arrive any day, and then it was DOA and they had to start over, and because they believed that MTAs would fail over to their secondary MX, and they didn't realize their firewall was accepting the connection and then leaving it hanging). What is the appropriate MTA behavior in this case? It seems clear to me that what everybody would want in this situation is for an MTA to fail over to the secondary MX. Should we be giving any consideration to the question of whether, on the average, secondary MXs are less reliable than primary? I don't think we should; I don't think we should warp the implementation to accommodate incorrectly configured systems. (If we can accommodate them with some change that *doesn't* warp things, then we should; "be generous in what you accept"). -- David Dyer-Bennet ***NOTE ADDRESS CHANGES*** [EMAIL PROTECTED] http://dd-b.lighthunters.net/ (photos) Minicon: http://www.mnstf.org/minicon http://www.dd-b.net/dd-b (sf) http://ouroboros.demesne.com/ Ouroboros Bookworms Join the 20th century before it's too late!
Re: When will qmail back off to the next MX?
[EMAIL PROTECTED] <[EMAIL PROTECTED]> writes on 27 September 1999 at 15:06:28 -0500 > OTTOMH, I would favor a randomized fallback scheme which does not depend > on queued message state. When a delivery failure occurs, choose a random > number, then decide whether to now try the next MX based on a probability > derived from the MX level, or the ratio of MX levels, then maybe or maybe > not retry the next level before requeueing. > > Should MX entries of equal value be tried equally? I think attempting to make inferences about the relative priority of MX records from the differences in their priorities is a BIG mistake (other than the defined ordering). Many MX priority schemes are historical, and involve fitting things into existing cracks, so the intervals and values are random, except for ording. And it's a misuse of the priority value, subject to massive breakage if somebody else defines a competing misuse, or if a standard meaning is adopted. Just don't go there! -- David Dyer-Bennet ***NOTE ADDRESS CHANGES*** [EMAIL PROTECTED] http://dd-b.lighthunters.net/ (photos) Minicon: http://www.mnstf.org/minicon http://www.dd-b.net/dd-b (sf) http://ouroboros.demesne.com/ Ouroboros Bookworms Join the 20th century before it's too late!
Re: When will qmail back off to the next MX?
David Dyer-Bennet writes: > What is the appropriate MTA behavior in this case? It seems clear > to me that what everybody would want in this situation is for an > MTA to fail over to the secondary MX. If their MX records are incorrectly configured, their email isn't going to go through. Why should other hosts go through heroic hoops just to get the mail to them? > Should we be giving any consideration to the question of whether, on > the average, secondary MXs are less reliable than primary? I don't > think we should; I don't think we should warp the implementation to > accommodate incorrectly configured systems. Aren't you doing just that? Right now, qmail works fine for machines which are correctly configured but sometimes inaccessible. Various people (not you) are talking about warping the implementation to accommodate incorrectly configured systems. There's a ton of different ways you can configure your system so that email bounces. Why should a remote system bother to work around any of them? I mean, there's the chance that the SMTP server might be configured with the wrong hostname, so the client should strip off the hostname for the RCPT TO: lines, right?? -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: When will qmail back off to the next MX?
Russell Nelson <[EMAIL PROTECTED]> writes on 27 September 1999 at 16:44:19 -0400 > David Dyer-Bennet writes: > > What is the appropriate MTA behavior in this case? It seems clear > > to me that what everybody would want in this situation is for an > > MTA to fail over to the secondary MX. > > If their MX records are incorrectly configured, their email isn't > going to go through. Why should other hosts go through heroic hoops > just to get the mail to them? I would not describe the MX records as incorrectly configured; the primary MX points to what's supposed to be their primary mail exchanger, *but it's down for an unexpectedly long period*. Since they have a secondary MX in place, they don't worry about updating the DNS, expecting MTAs to fail over to the secondary DNS since the primary is down. Nor do I consider it jumping through "heroic hoops" to notice that you can't connect to the primary MX, and decide to try the next one. > > Should we be giving any consideration to the question of whether, on > > the average, secondary MXs are less reliable than primary? I don't > > think we should; I don't think we should warp the implementation to > > accommodate incorrectly configured systems. > > Aren't you doing just that? Right now, qmail works fine for machines > which are correctly configured but sometimes inaccessible. It doesn't work fine in the scenario I outlined at the beginning of my message. In that situation, the mail will sit on the qmail system until it expires, when there's a perfectly good secondary MX system sitting there waiting to accept it. This is not my definition of "works fine". > Various people (not you) are talking about warping the > implementation to accommodate incorrectly configured systems. > There's a ton of different ways you can configure your system so > that email bounces. Why should a remote system bother to work > around any of them? I mean, there's the chance that the SMTP > server might be configured with the wrong hostname, so the client > should strip off the hostname for the RCPT TO: lines, right?? The secondary MX exists to cover cases when the primary is down. It's not an "incorrectly configured" DNS to have a primary MX listed that happens to be down at the moment! -- David Dyer-Bennet ***NOTE ADDRESS CHANGES*** [EMAIL PROTECTED] http://dd-b.lighthunters.net/ (photos) Minicon: http://www.mnstf.org/minicon http://www.dd-b.net/dd-b (sf) http://ouroboros.demesne.com/ Ouroboros Bookworms Join the 20th century before it's too late!
Re: When will qmail back off to the next MX?
David Dyer-Bennet writes: > Russell Nelson <[EMAIL PROTECTED]> writes on 27 September 1999 at 16:44:19 -0400 > > > Should we be giving any consideration to the question of whether, on > > > the average, secondary MXs are less reliable than primary? I don't > > > think we should; I don't think we should warp the implementation to > > > accommodate incorrectly configured systems. > > > > Aren't you doing just that? Right now, qmail works fine for machines > > which are correctly configured but sometimes inaccessible. > > It doesn't work fine in the scenario I outlined at the beginning of my > message. In that situation, the mail will sit on the qmail system > until it expires, when there's a perfectly good secondary MX system > sitting there waiting to accept it. This is not my definition of > "works fine". Right, but you're suggesting that nobody will notice the lack of reception of email for seven days. If they make configuration changes without testing them (and I count leaving a down machine down as such), and then don't notice that something is broken for a week, then I'll wager that they'll be suited just as well without email. You're also presuming that they have the ability to read email off the "secondary" host. It would be very unusual for a host which functions identically to another to be given a lower priority. Much more often, the secondary host is one which is configured only to relay mail to the primary. > > Various people (not you) are talking about warping the > > implementation to accommodate incorrectly configured systems. > > There's a ton of different ways you can configure your system so > > that email bounces. Why should a remote system bother to work > > around any of them? I mean, there's the chance that the SMTP > > server might be configured with the wrong hostname, so the client > > should strip off the hostname for the RCPT TO: lines, right?? > > The secondary MX exists to cover cases when the primary is down. It's > not an "incorrectly configured" DNS to have a primary MX listed that > happens to be down at the moment! And a firewall which accepts connections for a down host is not misconfigured or broken by design?? -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: When will qmail back off to the next MX?
On Mon, 27 Sep 1999, Russell Nelson wrote: > David Dyer-Bennet writes: > > It doesn't work fine in the scenario I outlined at the beginning of my > > message. In that situation, the mail will sit on the qmail system > > until it expires, when there's a perfectly good secondary MX system > > sitting there waiting to accept it. This is not my definition of > > "works fine". > > Right, but you're suggesting that nobody will notice the lack of > reception of email for seven days. If they make configuration changes > without testing them (and I count leaving a down machine down as > such), and then don't notice that something is broken for a week, then > I'll wager that they'll be suited just as well without email. Exactly. There seems to be some very odd ideas of what a higher-numbered MX will do floating around in this discussion. > You're also presuming that they have the ability to read email off the > "secondary" host. It would be very unusual for a host which functions > identically to another to be given a lower priority. Much more often, > the secondary host is one which is configured only to relay mail to > the primary. Which is the defined behavior, and the default behavior in sendmail, qmail, and most other mailers I know of. Once the mail gets to the lowest-numbered MX, then any funny "local" processing happens. If a host is configured as "fallback" but only for use when the primary has a problem, yet the DNS is not changed to reflect the seondary's new status when the primary does fail, then one is sending the world mixed signals, and one gets what one deserves. The more typical setup is to give them idenitical MXs, in which case even qmail will try more than one given bad delivery problems. > > The secondary MX exists to cover cases when the primary is down. It's > > not an "incorrectly configured" DNS to have a primary MX listed that > > happens to be down at the moment! The secondary MX exists to receive mail for holding and requeuing to pass onto the primary when the primary is not reachable by the sender and the sender wants to unqueue the mail. If you're talking about failover, you either need equal MX weights, or you need to have the DNS adjust when the lower MX goes down. Anything else is a kludge, and an insistence thatthe world support various kludges, when doing it right is quite simple. As Russ noted, it may be not "incorrectly configured" DNS if the main mail server is down, but it's certainly not correct if you have two hosts acting as final mail destinations yet with differing MX weights, and you expect there never to be a glitch if the lower-numbered one is acting sort-of alive yet is unable to really receive mail. -M Michael Brian Scher (MS683/MS3213) Anthropologist, Attorney, Policy Analyst Mainlining Internet Connectivity for Fun and Profit [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Give me a compiler and a box to run it, and I can move the mail.
Re: When will qmail back off to the next MX?
Russell Nelson wrote: > David Dyer-Bennet writes: > > What is the appropriate MTA behavior in this case? It seems clear > > to me that what everybody would want in this situation is for an > > MTA to fail over to the secondary MX. > > If their MX records are incorrectly configured, their email isn't > going to go through. Why should other hosts go through heroic hoops > just to get the mail to them? Just because the primary MX-pointed host happens to be down does not make the MX records incorrectly configured. There are scenarios where MX records should indeed be changed. But there are also scenarios where the MX records are correct as they stand and the difference cannot be distinguished from the point of view of the MTA trying to send mail. > > Should we be giving any consideration to the question of whether, on > > the average, secondary MXs are less reliable than primary? I don't > > think we should; I don't think we should warp the implementation to > > accommodate incorrectly configured systems. > > Aren't you doing just that? Right now, qmail works fine for machines > which are correctly configured but sometimes inaccessible. Various I would disagree. At least you said "fine" as opposed to "conformant", opening it to disagreement of opinion, since "fine" is subjective. The reason I disagree is because of the scenario where it may take three days or more to correct the problems in the 1st host while the 2nd host is able to deliver the mail just fine. > people (not you) are talking about warping the implementation to > accommodate incorrectly configured systems. There's a ton of And some are talking about warping it to accomodate situations of failure that don't repressent a misconfiguration. > different ways you can configure your system so that email bounces. > Why should a remote system bother to work around any of them? I mean, > there's the chance that the SMTP server might be configured with the > wrong hostname, so the client should strip off the hostname for the > RCPT TO: lines, right?? I'm not suggesting we bend over backwards, or even bend at all, to accomodate incorrect configurations. However, I don't want to miss an opportunity to work around a problem in a correctly configured setup just because someone else may be able to produce identical symptoms by means of incorrect configuration. If it happens that a change intended to work around problems also happens to work around misconfiguration, who of us will feel bad about that (raise hands)? -- Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] at| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] dot| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: When will qmail back off to the next MX?
Russell Nelson wrote: > David Dyer-Bennet writes: [snip] > > It doesn't work fine in the scenario I outlined at the beginning of my > > message. In that situation, the mail will sit on the qmail system > > until it expires, when there's a perfectly good secondary MX system > > sitting there waiting to accept it. This is not my definition of > > "works fine". > > Right, but you're suggesting that nobody will notice the lack of > reception of email for seven days. If they make configuration changes > without testing them (and I count leaving a down machine down as > such), and then don't notice that something is broken for a week, then > I'll wager that they'll be suited just as well without email. You're suggesting that all incoming mail reaches them by means of qmail and that sendmail doesn't exist? If the 1st MX host is down (any scenario, including dying in the middle of receing SMTP DATA) and the 2nd MX host is up, they may well not notice anything because there isn't enough problem to notice. And if they do notice that some mail isn't arriving as expected, they could very easily be misled to not blame the 1st MX host because most mail is arriving just fine (via sendmail falling back to the 2nd MX host). I'm sure the system administrator will notice something wrong when he gets back from his vacation in Kuala Lampur. > You're also presuming that they have the ability to read email off the > "secondary" host. It would be very unusual for a host which functions > identically to another to be given a lower priority. Much more often, > the secondary host is one which is configured only to relay mail to > the primary. You're presuming that they read email off of either host. They may be reading it off of an internal mail server on a private address LAN that only hosts in the DMZ, acting as mail gateways, can reach. And there is also a valid reason to prefer one server over another to gateway the mail. If there are 2 servers in the DMZ, functionality may be split by having one act as the web server and the other act as the mail server, with failover being the other server. The 2nd MX host would then be the web server. It would be undesired to put half of the mail through it when the 1st is running fine and is dedicated to the purpose. > > The secondary MX exists to cover cases when the primary is down. It's > > not an "incorrectly configured" DNS to have a primary MX listed that > > happens to be down at the moment! > > And a firewall which accepts connections for a down host is not > misconfigured or broken by design?? Such a firewall is broken. Such a firewall is not the only scenario impacted by not falling back to the 2nd MX. Is it more important to punish broken configurations at the expense of missing an opportunity to work around a problem in a valid configuration? I know we hate misconfiguration, but is it necessary to be so obsessed with it? I'm arguing for the valid configurations, not that broken firewall scenario. I've pointed out how without such a firewall you can still have the same exact symptoms and many others like it. -- Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] at| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] dot| [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: When will qmail back off to the next MX?
Russell Nelson <[EMAIL PROTECTED]> writes on 27 September 1999 at 17:27:30 -0400 > David Dyer-Bennet writes: > > Russell Nelson <[EMAIL PROTECTED]> writes on 27 September 1999 at 16:44:19 -0400 > > > > Should we be giving any consideration to the question of whether, on > > > > the average, secondary MXs are less reliable than primary? I don't > > > > think we should; I don't think we should warp the implementation to > > > > accommodate incorrectly configured systems. > > > > > > Aren't you doing just that? Right now, qmail works fine for machines > > > which are correctly configured but sometimes inaccessible. > > > > It doesn't work fine in the scenario I outlined at the beginning of my > > message. In that situation, the mail will sit on the qmail system > > until it expires, when there's a perfectly good secondary MX system > > sitting there waiting to accept it. This is not my definition of > > "works fine". > > Right, but you're suggesting that nobody will notice the lack of > reception of email for seven days. If they make configuration changes > without testing them (and I count leaving a down machine down as > such), and then don't notice that something is broken for a week, then > I'll wager that they'll be suited just as well without email. They will continue to receive email, as I understand it, except from qmail sites. So they won't see an obvious symptom such as "no email arriving". > You're also presuming that they have the ability to read email off the > "secondary" host. It would be very unusual for a host which functions > identically to another to be given a lower priority. Much more often, > the secondary host is one which is configured only to relay mail to > the primary. I'm presuming that the primary and secondaries are boundary hosts that feed into some internal pool of systems for mail handlings. This is not uncommon at larger sites, but by no means universal either. > > > Various people (not you) are talking about warping the > > > implementation to accommodate incorrectly configured systems. > > > There's a ton of different ways you can configure your system so > > > that email bounces. Why should a remote system bother to work > > > around any of them? I mean, there's the chance that the SMTP > > > server might be configured with the wrong hostname, so the client > > > should strip off the hostname for the RCPT TO: lines, right?? > > > > The secondary MX exists to cover cases when the primary is down. It's > > not an "incorrectly configured" DNS to have a primary MX listed that > > happens to be down at the moment! > > And a firewall which accepts connections for a down host is not > misconfigured or broken by design?? I'd agree that it is, in fact, misconfigured or broken. I also believe it's a very easy mistake to make, since the mail hosts will presumably not be down all that often. -- David Dyer-Bennet ***NOTE ADDRESS CHANGES*** [EMAIL PROTECTED] http://dd-b.lighthunters.net/ (photos) Minicon: http://www.mnstf.org/minicon http://www.dd-b.net/dd-b (sf) http://ouroboros.demesne.com/ Ouroboros Bookworms Join the 20th century before it's too late!
