>From Matt and his admin at Microsoft.... FYI.... every time I try and telnet smtpinvite.mx.webtv.net 25 this morning I get the 421 error. Last night everyone was getting Connection Closed. What are you getting now?
Tyler -----Original Message----- From: Matt Lariz [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 28, 2004 11:41 AM To: [EMAIL PROTECTED] Subject: RE: [IMail Forum] FW: Primary MX - Server is failing Tyler, I too am working with mail admins who know far more than I do. They gave me the wrong RFC before. Instead of RFC822 I should have said RFC1123, which supercedes 822. The key as I see it, is that although Imail is being refused a connection at the network level, it is still interpreting that as an SMTP response 451(421?). In another email you sent me you said, "When I telnet to a non-existant host on port 25, there is never any response to the SYN, so the connection eventually times out." This may be a matter of semantics, but why you expect any response from a non-existent host? You also included this, "The fact that the remote host actively reset the connection, seems to be key here, as the RFC states: SMTP clients that experience a connection close, reset, or other communications failure due to circumstances not under their control (in violation of the intent of this specification but sometimes unavoidable) SHOULD, to maintain the robustness of the mail system, treat the mail transaction as if a 451 response had been received and act accordingly." However, in this case there is never an smtp connection to reset, only a network connection, which is refused. So Imail should treat this as if no SMTP connection could be made, which it couldn't, and fail over to the secondary. BTW, I am moving his thread to my personal email, so please make sure to reply to this address. Thanks. -- Matt Here is the info I got from my admin: It is really from RFC1123 which supercedes 822. In Particular: 5.3.4 Reliable Mail Transmission To transmit a message, a sender-SMTP determines the IP address of the target host from the destination address in the envelope. Specifically, it maps the string to the right of the "@" sign into an IP address. This mapping or the transfer itself may fail with a soft error, in which case the sender- SMTP will requeue the outgoing mail for a later retry, as required in Section 5.3.1.1. When it succeeds, the mapping can result in a list of alternative delivery addresses rather than a single address, because of (a) multiple MX records, (b) multihoming, or both. To provide reliable mail transmission, the sender-SMTP MUST be able to try (and retry) each of the addresses in this list in order, until a delivery attempt succeeds. However, there MAY also be a configurable limit on the number of alternate addresses that can be tried. In any case, a host SHOULD try at least two addresses. The following information is to be used to rank the host addresses: (1) Multiple MX Records -- these contain a preference indication that should be used in sorting. If there are multiple destinations with the same preference and there is no clear reason to favor one (e.g., by address preference), then the sender-SMTP SHOULD pick one at random to spread the load across multiple mail exchanges for a specific organization; note that this is a refinement of the procedure in [DNS:3]. What this means is if you are a sending SMTP site, you need to look up the receiving SMTP MX records and attempt to connect to each of them (in ascending preference order) until you connect to one. In our case our DNS MX records look like this: <chez:proc2> nslookup -sil -q=mx webtv.net Server: 63.249.69.29 Address: 63.249.69.29#53 webtv.net mail exchanger = 10 smtpinvite.mx.webtv.net. webtv.net mail exchanger = 20 smtpin.mx.webtv.net. This means they need to try to connect to smtpinvite.mx.webtv.net first, and if that fails they need to fall over to smtpin.mx.webtv.net. They should be able to verify that they cannot connect to smtpinvite by using telnet from their mail server to port 25. They will get "connection refused" which means they are being blocked from a network level. <chez:proc2> telnet smtpinvite.mx.webtv.net 25 Trying 209.240.204.25... telnet: connect to address 209.240.204.25: Connection refused telnet: Unable to connect to remote host The 421 error they were getting before was not being sent by our mail server. They were never able to connect to our mail server to get that error since we block them at the network level. It was generated by their own mail system when they were not able to connect. However, they should be able to connect to the second MX listed, smtpin.mx.webtv.net, which they can confirm also via telnet to port 25 <chez:proc2> telnet smtpin.mx.webtv.net 25 Trying 209.240.204.26... Connected to smtpin-3001.bay.webtv.net. Escape character is '^]'. 220 smtpin-3120.bay.webtv.net ESMTP WebTV_Postfix+sws (2.0.3/in.gso.28Feb2003) ready to rumble If their Mail Transport (IMail?? I am not familiar with that - what is it?) is not able to follow MX Chains properly, they may be able to hard code it to say that mail destined for webtv.net should connect directly to smtpin.mx.webtv.net instead of looking for that information within DNS. -----Original Message----- From: Tyler Jensen [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 6:01 PM To: SVC Service Operations Center Subject: FW: [IMail Forum] FW: Primary MX - Server is failing Hi again Matt, I have started a pretty good thread on the IMail list and thought you would like to see some of the responses. Thanks for your time. Tyler > >I am not disputing what you are saying, as you are more knowledgeable > >than I. However, it does not seem logical for iMail to treat this as a > >4xx temporary error code. > To me, it does. And RFC2821 3.9 tells IMail to treat it as a 4xx. > > My take is that if you say that you have a mailserver at a certain IP > and I can't reach it, I should try the backup. But if you have a > server at that IP and it isn't accepting connections to port 25, it is > probably in the > process of being rebooted. If it is being rebooted, it should accept the > E-mail on the next attempt. > > >Here is my concern: > > > >Example.com has the following DNS configuration > > > >Mail1 A 123.123.123.10 > >Mail2 A 123.123.123.20 > >@ MX 10 mail1.example.com > >@ MX 20 mail2.example.com > > > >Under this scenario, the admin of example.com feels that it's worthwhile > >to put a secondary server (mail2) online in order to provide continuous > >mail delivery services, in the event that mail1 fails. If the server > >fails and is offline completely, it is not going to respond to telnet. > >Ergo, if I telnet to mail1.example.com I am going to receive: > > > >Connecting To mail1.example.com...Could not open connection to the host, > >on port 25: Connect failed Correct. > > >According to you, iMail should interpret this as a temporary error and > >continue trying to send email to this host, even though it is apparently > >down. No. If you try connecting to mail1.example.com and it is down, you'll either get no response, or a "port not reachable" or other similar response. In that case, IMail will indeed try mail2.example.com. What is happening in this thread is that webtv's primary mailserver is responding with a "this port isn't active right now"; the same thing that would happen during a reboot. > >If this is the case, I am simply going to remove my secondary MXs > >from my domains, as they apparently will do very little good in the > >event that the primary server goes down! That's not a problem -- the only issue is if your mailserver has some serious problem that causes it not to accept connections to port 25 (timing out doesn't count; only if Windows responds with a "there is no service on this port" message is there a problem). > >Wouldn't a better and more logical behavior be for the sending SMTP > >server to say "MX 10, down. Trying MX 20". Also, I am curious to know > >what would cause iMail (or any mail server) to use mail2, and not mail1. Just about anything will cause IMail to try mail2.example.com. If IMail detects that the IP address it connected to is live, though, it will re-try it. -Scott > --- > Declude JunkMail: The advanced anti-spam solution for IMail mailservers > since 2000. > Declude Virus: Ultra reliable virus detection and the leader in > mailserver vulnerability detection. > Find out what you've been missing: Ask for a free 30-day evaluation. > > --- > [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ --- [This E-mail scanned for viruses by Declude Virus] --- [This E-mail scanned for viruses by Declude Virus] --- [This E-mail scanned for viruses by Declude Virus] To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
