Re: [Exim] Refuse connection if no MX for sending host

Top Page
Delete this message
Reply to this message
Author: Exim Users Mailing List
Date:  
To: Rick Duvall
CC: Exim Users Mailing List
Subject: Re: [Exim] Refuse connection if no MX for sending host
[ On Friday, October 24, 2003 at 16:27:28 (-0700), Rick Duvall wrote: ]
> Subject: Re: [Exim] Refuse connection if no MX for sending host
>
> I have come to the conclusion that even though the RFC says what it
> says, not everybody is going to follow it, and not everybody is going to
> dis-regard it and make their own standards in the same way either.


Indeed you're quite right about that! ;-)

> Therefore, it is impossible to implement one thing over another, because
> there is going to be a number of sites out there that will either reject my
> mail because they aren't following the specs, or I will reject theirs
> because I'm not following the specs, or I will reject theirs because they
> aren't following specs.


Well if you know your traffic patterns, and your SMTP peers are
reasonably predictable and/or stable, then you can do your own analysis
off their state of affairs and decide from there what policies you can
"afford" to implement.

> At this point in the MTA game, there is no standard
> that EVERYBODY follows. There is one that everybody is supposed to follow,
> but they don't. So I give up. If all MTA can't jive, then something is
> going to break at some point, and there is nothing we can do about it. So,
> we are all left with picking and choosing what we feel is right for our
> site, whether it follows RFC or not.


Oh, it's not all that bad. :-)

Almost every mailer does implement the basic protocol specifications
required for minimal interoperability, and most every domain has
sufficiently correct DNS to keep most of us happy most of the time.

However it's very important to keep security and admistrative policies
and their implementations distinct and separate in one's mind when
discussing real-world configurations. There are far too many people,
such as Mr. Byng-Maddick, who seem to be terribly confused about these
things. No Internet standard, RFC, or whatever, can actually dictate
policy requirements to anyone or to any site. If you wish to require
your peers to have valid MX records then that's your site policy and
nobody can say you're wrong.

Just remember that you're the one paying to host your mail server on the
Public Internet. If someone wants to send e-mail to your domain then
the onus is primarily on them to make sure they meet your minimum policy
requirements (provided of course that your mailer implements the basic
minimum functionality described by the interoperability documents and
provided that your mailer adequately describes your local policies in
the error messages it generates when a third-party client violates those
policies).

Of course some of us choose to try to interact with a rather wide and
diverse portion of the public internet and I can tell you from my
adventures with trying to contact many postmasters and hostmasters about
mailers and DNS that some of the problems I see would be hilariously
funny if they weren't actually the result of very poorly designed
software that well meaning people end up using without realizing what
they've got themsleves into. Thankfully Exim is not one of those pieces
of software -- indeed Exim sites are, overall, some of the best run I've
ever encountered and I'm certain the good design of Exim is a major
facilitator in making this so. I won't name names, but I will point out
that there is at least one widely used open-source mailer that doesn't
provide automatically for a <postmaster> mailbox for every domain it
handles locally and as a result I believe it is responsible for a larger
than average portion (relative to its deployment) in the postmaster zone
at rfc-ignorant.org. Occasionally it seems Exim instances are not aware
of all the domain names which they should answer for, but on average
they seem quite rare given the rate of deployment of Exim.

--
                        Greg A. Woods


+1 416 218-0098                  VE3TCP            RoboHack <woods@???>
Planix, Inc. <woods@???>          Secrets of the Weird <woods@???>