I apologize if this has been discussed before, but I have been unable
to find any posts in the archives.
Our organization has been successfully running Sendmail 8.13.x
on our clusters. I am now experimenting with Sendmail 8.14.x
as well as reviewing our configuration files.
I am currently investigating the Sendmail 8.14.x "badmx" feature.
According to the features list and the documentation, this feature
enables the rejection of messages with envelope sender address
domains that resolve to "bad" MX records. This appears to work
as advertised, and it definitely bases the result on the domain of
the envelope sender's e-mail address.
However, the resulting error message is confusing, since it implies
that the problem domain is contained in the recipient e-mail address:
mail from:
250 2.1.0 ... Sender ok
rcpt to:
550 5.1.2 ... Illegal MX record for recipient host invaliddomain
Am I missing something obvious? And if so, please elaborate. :-)
Thanks in advance,
--Beth
bhalsema@purdue.edu
Re: FEATURE(`badmx") Question
am 06.11.2007 20:20:02 von gtaylor
On 11/06/07 10:37, Beth Halsema wrote:
> However, the resulting error message is confusing, since it implies
> that the problem domain is contained in the recipient e-mail address:
>
> mail from:
> 250 2.1.0 ... Sender ok
> rcpt to:
> 550 5.1.2 ... Illegal MX record for recipient host
> invaliddomain
>
> Am I missing something obvious? And if so, please elaborate. :-)
One thing that jumps out at me immediately is the fact that the badmx
feature appears to be running after the RCPT verb has been issued. I
would have thought that the badmx feature would run after the MAIL verb.
I wonder if you don't have something like 'delay checks' (or what ever
the exact name is) enabled. This way rather than out and out rejecting
an invalid envelope from address, you can optionally white list the
envelope from address based on the envelope recipient(s). Thus if you
want any thing and everything to postmaster@domain.tld to be accepted
regardless of the validity of the envelope from address you would need
this ability.
Break the message "... Illegal MX record for recipient host
invaliddomain ..." down in to its sub-pieces. "Illegal MX record for
Re: FEATURE(`badmx") Question
am 06.11.2007 21:33:35 von Beth Halsema
On Tue, 6 Nov 2007, Grant Taylor wrote:
> Date: Tue, 06 Nov 2007 13:20:02 -0600
> From: Grant Taylor
> Reply-To: A UseNet comp.mail.sendmail newsgroup to mailing list gateway.
>
> Subject: Re: FEATURE(`badmx') Question
>
> On 11/06/07 10:37, Beth Halsema wrote:
> > However, the resulting error message is confusing, since it implies that the
> > problem domain is contained in the recipient e-mail address:
> >
> > mail from:
> > 250 2.1.0 ... Sender ok
> > rcpt to:
> > 550 5.1.2 ... Illegal MX record for recipient host
> > invaliddomain
> >
> > Am I missing something obvious? And if so, please elaborate. :-)
>
> One thing that jumps out at me immediately is the fact that the badmx feature
> appears to be running after the RCPT verb has been issued. I would have
> thought that the badmx feature would run after the MAIL verb. I wonder if you
> don't have something like 'delay checks' (or what ever the exact name is)
> enabled. This way rather than out and out rejecting an invalid envelope from
> address, you can optionally white list the envelope from address based on the
> envelope recipient(s). Thus if you want any thing and everything to
> postmaster@domain.tld to be accepted regardless of the validity of the
> envelope from address you would need this ability.
Yes, I am using FEATURE(`delay_checks')...which is required for other
configuration items. We are not looking to whitelist these types of
messages...in fact, we are considering not accepting them.
If one eliminates the 'delay_checks' and other configuration items (that
required the inclusion of 'delay_checks'), then one gets the following
dialogue:
mail from:
550 5.1.2 ... Illegal MX record for recipient host badmxdomain
Again, the recipient host is not the problem...it is the sending domain.
Again, Sendmail has come to the right conclusion.
> Break the message "... Illegal MX record for recipient host invaliddomain ..."
> down in to its sub-pieces. "Illegal MX record for
Re: FEATURE(`badmx") Question
am 06.11.2007 22:09:53 von gtaylor
On 11/06/07 14:33, Beth Halsema wrote:
> Yes, I am using FEATURE(`delay_checks')...which is required for other
> configuration items. We are not looking to whitelist these types of
> messages...in fact, we are considering not accepting them.
>
> If one eliminates the 'delay_checks' and other configuration items
> (that required the inclusion of 'delay_checks'), then one gets the
> following dialogue:
>
> mail from:
> 550 5.1.2 ... Illegal MX record for recipient
> host badmxdomain
>
> Again, the recipient host is not the problem...it is the sending
> domain. Again, Sendmail has come to the right conclusion.
I expected as much. Sendmail may (likely does) have a few bugs in it,
but it's ""business logs is usually very sound.
> Exactly. So, would it be more appropriate and clear to say:
>
> "Illegal MX record for sender address "
>
> ?
Possibly.
> So, my first example would result in the following dialogue:
>
> mail from:
> 250 2.1.0 ... Sender ok
> rcpt to:
> 550 5.1.2 ... Illegal MX record for sender address
> badmxdomain
Yes...
> If something else was meant by the current text, then I am hoping to
> better understand and interpret this feature correctly. If not, then
> I would propose a more clear error message.
If you want your server to say something else, search the source code
and change it.
> Thanks again!
*nod*
Grant. . . .
Re: FEATURE(`badmx") Question
am 07.11.2007 00:01:45 von Res
On Tue, 6 Nov 2007, Grant Taylor wrote:
>> Again, the recipient host is not the problem...it is the sending
>> domain. Again, Sendmail has come to the right conclusion.
>
> I expected as much. Sendmail may (likely does) have a few bugs in it,
> but it's ""business logs is usually very sound.
>
>> Exactly. So, would it be more appropriate and clear to say:
>>
>> "Illegal MX record for sender address "
>>
>> ?
>
> Possibly.
>
>> So, my first example would result in the following dialogue:
>>
>> mail from:
>> 250 2.1.0 ... Sender ok
>> rcpt to:
>> 550 5.1.2 ... Illegal MX record for sender address
>> badmxdomain
>
> Yes...
When you think about the implimentation, it is the recipient host.
Because the MX is looked up for senders_domain, so as if to send to
senders_domain (EG: you click reply to the sender) thereby making,
for the purpose of this test, senders_domain in fact the recipient
domain, so with that intention it's not wrong.
But, I agree it might be confusing to some and have fired off an Email
to Clauss suggesting for clarity reasons, a change to something like
....Illegal MX record for
We'll wait and see what he says :)
--
Cheers
Res
Re: FEATURE(`badmx") Question
am 07.11.2007 07:41:57 von Res
On Wed, 7 Nov 2007, Res wrote:
> But, I agree it might be confusing to some and have fired off an Email
> to Clauss suggesting for clarity reasons, a change to something like
> ...Illegal MX record for
>
Clauss agrees :)
The 'recipient' word is now removed from this feature.
--
Cheers
Res
Re: FEATURE(`badmx") Question
am 07.11.2007 12:31:39 von Beth Halsema
On Wed, 7 Nov 2007, Res wrote:
> Date: Wed, 7 Nov 2007 09:01:45 +1000 (EST)
> From: Res
> Reply-To: comp-mail-sendmail@ausics.net
> Subject: Re: FEATURE(`badmx') Question
>
> When you think about the implimentation, it is the recipient host.
>
> Because the MX is looked up for senders_domain, so as if to send to
> senders_domain (EG: you click reply to the sender) thereby making,
> for the purpose of this test, senders_domain in fact the recipient
> domain, so with that intention it's not wrong.
I see your point. Thank you for elaborating. With that logic in mind,
it does make perfect sense.
> But, I agree it might be confusing to some and have fired off an Email
> to Clauss suggesting for clarity reasons, a change to something like
> ...Illegal MX record for
>
> We'll wait and see what he says :)
I saw your follow-up, Res. Thank you, Grant, Res, and Clauss.