At 8:10 AM -0700 1/22/03, Warren Michelsen imposed structure on a stream of electrons, yielding:
Then the secondary should try to pass it to the primary and do what the primary says. If the primary rejects the mail with a 5xx error then the secondary should bounce it.Yesterday my primary SIMS box was down for about 12 hours. Mail backed up on my secondary server as it should, but much of it bounced and I have no idea why.The router on the backup has entries of the sort: domain.com = domain.com.smtp for each of the domains for which it bounced some mail. Confusingly, some for each such domain did not bounce but some did. Here is an example: ___ Subject: Undeliverable mail: PS: iRack-3 Problems! From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Mon, 20 Jan 2003 22:18:30 -0700 Failed to deliver your message to [EMAIL PROTECTED]: SMTP: Address rejected by host Host 'mail.mdcclxxvi.com' says: 550 5.7.1 <[EMAIL PROTECTED]>... Relaying denied. IP name possibly forged [209.145.196.135] Reporting-MTA: dns; SMTP.az.net Final-Recipient: rfc822; [EMAIL PROTECTED] Action: failed Status: 5.0.0 Received: from [209.145.200.34] (HELO mercury.flg.digitalresources.net) by SMTP.az.net (Stalker SMTP Server 1.8b9d14) with ESMTP id S.0000122645 for <[EMAIL PROTECTED]>; Mon, 20 Jan 2003 22:11:43 -0700 Received: from 209.145.196.197 (LISTS.MDCCLXXVI.COM [209.145.196.197]) by mercury.flg.digitalresources.net (Vircom SMTPRS 1.4.231) with SMTP id <[EMAIL PROTECTED]> for <[EMAIL PROTECTED]>; Mon, 20 Jan 2003 22:10:37 -0700 Message-ID: <[EMAIL PROTECTED]> Date: Mon, 20 JAN 2003 22:10:59 -0700 From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> CC: Subject: PS: iRack-3 Problems! Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Priority: 1 (Highest) ___ Does it make sense that *any* mail for MDCCLXXVI.com would be bounced by the secondary, given the router entry in the secondary which says: MDCCLXXVI.com = MDCCLXXVI.com.smtp?
Absent deep support for authenticated SMTP (i.e. STARTTLS support with X.509 certs) there's no way for a SMTP client to positively identify a server as being the 'right' one for a domain name other than DNS. If DNS says that mail.mdcclxxvi.com is at 209.145.196.198 then whatever answers port 25 at 209.145.196.198 at a given moment is the only thing that any SMTP client can interpret as being the 'real' mail.mdcclxxvi.com.Big Question: When SIMS reports.... Host 'mail.mdcclxxvi.com' says: 550 5.7.1 <[EMAIL PROTECTED]>... Relaying denied. IP name possibly forged [209.145.196.135] .... How is it identifying the host as 'mail.mdcclxxvi.com' ? Does SIMS simply look up mail.mdcclxxvi.com and assume that the host at that IP address IS mail.mdcclxxvi.com or does a host have to specifically identify itself as mail.mdcclxxvi.com?
Ouch. Stupid feature. Tenon needs a solid slapping for bringing up an MTA on that address.The reason I ask is this... (And this may be the key to the whole works)... The reason that mail.mdcclxxvi.com was down is that my OS X Server box stole its IP address. A "Feature" of Tenon's iTools caused it to automatically configure the IP address of my main mail/web/DNS on its en0.
Yes, but it would be Bad and Wrong for any SMTP client to look at the initial banner, parse out a hostname, and not talk to the server if it identifies itself wrongly. Any client that did that would never talk to SIMS at all, since SIMS doesn't actually have the hostname in the banner (as most MTA's do.)I was moving a web site from my old, classic Mac OS box (my primary SIMS box) to my OS X Server (with iTools) box. I had updated the DNS and even checked that each resolver responded with the new IP address for this domain but somehow iTools got the old IP address instead when it did its lookup as the VHost was added, so it configured the iTools box to respond to the IP address that was in service on my main web/mail/DNS box, which is mail.mdcclxxvi.com. As is often the case in the world, the courteous, considerate one lost out to the rude one and my OS 9.x box obligingly shut down its Ethernet interface because it detected that IP already in use on the network. My SIMS box thus was unreachable. Any attempt by SIMS on the secondary to reach 'mail.mdcclxxvi.com' would have actually been connecting to my iTools-equipped OS X Server box which would have identified itself as xserver.mdcclxxvi.com.
Yes, because there's no reason to expect that it is not. In a network sense, that machines WAS mail.mdcclxxvi.com: it was answering on the IP address that the name resolved to.So, when it says: Host 'mail.mdcclxxvi.com' says: 550 5.7.1 <[EMAIL PROTECTED]>... Relaying denied. IP name possibly forged [209.145.196.135] is SIMS *assuming* 'mail.mdcclxxvi.com' because it's connecting to the address that *should be* 'mail.mdcclxxvi.com'?
No. There's no reliable way to get the "right" hostname from a standard SMTP session. Most MTA's put their primary name in the banner and the response to the HELO/EHLO introduction, but that's neither required nor reliable. The same MTA instance may be answering on one or more IP addresses that properly resolve from multiple names, and there's no way for that MTA instance to always be sure of what name the client used to get that address.Finally, if the secondary was in fact connecting to my xserver.mdcclxxvi.com box, could SIMS be made to put that host name in the bounce messages/log, etc. instead of the hoped for 'mail.mdcclxxvi.com'?
TLS support in MTA's can solve this, but SIMS doesn't do it and neither do most sites, even those running MTA's with support. The risk of another machine spoofing an IP address is a 'problem' of fairly limited scope that in general is easier to address by making it not happen rather than by catching it when it does occur. What iTools is doing is not normal or wise.
--
Bill Cole
[EMAIL PROTECTED]
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[EMAIL PROTECTED]>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
