Mailing List SIMS@mail.stalker.com Message #15463
From: Bill Cole <listbill@scconsult.com>
Subject: Re: An elemental question.
Date: Tue, 27 Feb 2007 09:45:50 -0500
To: SIMS Discussions <SIMS@mail.stalker.com>
At 10:43 AM +0100 2/27/07, Jorge Chamorro imposed structure on a stream of electrons, yielding:
El 24/2/07 01:10, "Bill Cole" <listbill@scconsult.com> escribió:

 At 11:37 PM +0100 2/23/07, jorge  imposed structure on a stream of
 electrons, yielding:
 Hello,

 Let's say that the MX for my domain resolves to an IP address whose
 inverse resolution points to another different host/domain.
 This is what happens when a mail server is run from a rented IP address.

 I believe that it's ok, but is it really ?

 Mostly. It may raise a little suspicion.

 The most important bit of resolution is that what you HELO and banner
 as (in SIMS, the "Main Domain Name" setting) should resolve forward
 to the IP others see you as. Reverse resolution is less important,
 but you should be concerned if it goes to a name that looks generic:
 derived from the IP address. Lack of any reverse DNS is even worse.

Just to make sure, Main Domain Name stands for the domain name
(example.com), not the MX host FQDF (mail.example.com), right ?

There is a setting for SIMS which carries the label "Main Domain Name" in the web configuration interface (and probably in Communigator as well, I just don't have a way to run Communigator handy.) That name is the one SIMS uses for EHLO/HELO commands, in its banner, and in Received headers. That name needs to have an A record (not a CNAME, not a MX) pointing to the IP address that is used for SIMS interacting with the world. That can be strange and non-obvious to set up if you have a machine with multiple interfaces and/or behind a router performing NAT. The SIMS "Main Domain Name" should be a fully-qualified name, and should match the name resolved from an MX lookup on any domain handled by your SIMS server.

This is somewhat counter-intuitive if you tend to think of domains names and host names as distinctly different things. There have probably been a dozen people over the past 10 years who have brought this issue up on this list. Either of these 2 sets of configuration would be reasonable:

SET 1:
 DNS:
   example.com MX 0 example.com
   example.com A 192.0.2.1
 SIMS Main Domain Name: example.com

SET 2:
 DNS:
   example.com MX 0 mail.example.com
   mail,example.com A 192.0.2.1
 SIMS Main Domain Name: mail.example.com
 SIMS Router:
   example.com = mail.example.com

However, a lot of people have found problems when doing this:

 DNS:
   example.com MX 0 mail.example.com
   mail,example.com A 192.0.2.1
 SIMS Main Domain Name: example.com


It works in most cases, but with the growing use of MTA identity quirks as a correlation to spam and related mail misbehaviors, that sort of setup will sometimes cause trouble.

 What do you think ?
 Any url to learn more about this particular aspect ?
 Any comments would be greatly appreciated.

 I don't have a specific deep URL, but you may find useful information
 behind http://www.sorbs.net in their description of their criteria
 for listing machines in their "dynamic" list. It gives a clue as to
 what some people are doing that is trusted by many others in a
 related area (i.e. stability and consistency of DNS.) What individual
 mail admins actually do in cross-checking can be a lot more severe,
 particularly with admins who have more understanding of how to tweak
 Sendmail than why...


Another problem I'm having lately is that some messages remain forever in
the queue, with "suspended" status. The smtp is set to retry 10 times @ 3
minutes intervals. What's the difference between "suspended" and "failed" ?

In theory, "suspended" means that the message has retries remaining. "Failed" means that the message has used up all of its retries and is waiting out the configured deletion period.

I've never seen the problem you are reporting on my own system, but others have mentioned it here in the past and I believe it is the result of having overly aggressive retry settings like yours. I believe that what may be happening is that an attempt to send has a very slow failure (i.e. over 3 minutes) and the retry algorithm gets confused. I can even see how such a circumstance might result in OS-level prevention of the message being cleared, but that would be completely hypothetical.

Reportedly, recycling SIMS clears up these undead messages.

--
Bill Cole
bill@scconsult.com

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster