Q: Feature(badmx) - as added to version 8.14

If I'm reading the ruleset correctly, I don't see an exemption for one's self
(class $=w), one's relays (class $=R), one's masqueraders (class $=M), or or
one's virtual hosts (class $={VirtHosts}). Such an exemption could be useful
where a server has multiple virtual domains where one or more of the virtual
hosts in those domains are to be outbound servers only.

To help prevent inbound spam, I've placed DNS records that say "MX 0 localhost."
on virtual hosts that do not receive mail. ("localhost." is served in the
additonal section by my DNS servers with its usual addresses of 127.0.0.1 and
::1.) However, these virtual hosts sometimes source mail (via contact web forms
and cron jobs - e.g.), but if I were to use the stock feature defintion, it
appears that when the mail_from parameter is looked at, this locally generated
mail would be blocked by this feature. (Of course, mail to one's self passing
through localhost works for the host itself and fails for everyone else. I
don't care if the host qualifies to be listed at rfc-ignorant.org as it's not
sending off-host anyway, forwarding notwithstanding.)

I thought that the intent of the feature was to block mail from OTHER systems
that have bogus MX records. Presumedly, if one's own system has such a record,
it is on purpose and/or by design, but should this feature block mail to one's
self? Was this an oversight in the implementation of the feature - or on
purpose?

Re: Q: Feature(badmx) - as added to version 8.14

In article ,
"D. Stussy" wrote:

> If I'm reading the ruleset correctly, I don't see an exemption for one's self
> (class $=w), one's relays (class $=R), one's masqueraders (class $=M), or or
> one's virtual hosts (class $={VirtHosts}). Such an exemption could be useful
> where a server has multiple virtual domains where one or more of the virtual
> hosts in those domains are to be outbound servers only.
>
> To help prevent inbound spam, I've placed DNS records that say "MX 0
> localhost."
> on virtual hosts that do not receive mail. ("localhost." is served in the
> additonal section by my DNS servers with its usual addresses of 127.0.0.1 and
> ::1.)

That's wrong. You're telling anyone asking form that DNS record that
they are the place to deliver mail for those domains, which is a lie.

"MX 0 ." is a better approach for telling the world that a name is not a
valid domain-part in an email address. The RHS of the record is an
empty string, indicating quite explicitly that there is no mail
exchanger for the domain. There is an expired ID for that practice and
many places including Yahoo have it deployed widely.

> However, these virtual hosts sometimes source mail (via contact web
> ::forms
> and cron jobs - e.g.), but if I were to use the stock feature defintion, it
> appears that when the mail_from parameter is looked at, this locally
> generated
> mail would be blocked by this feature.

Sending mail with an envelope sender whose domain part is not
mail-routable is a bad thing to do. It SHOULD be routinely broken.

> (Of course, mail to one's self
> passing
> through localhost works for the host itself and fails for everyone else. I
> don't care if the host qualifies to be listed at rfc-ignorant.org as it's not
> sending off-host anyway, forwarding notwithstanding.)
>
> I thought that the intent of the feature was to block mail from OTHER systems
> that have bogus MX records. Presumedly, if one's own system has such a
> record,
> it is on purpose and/or by design, but should this feature block mail to
> one's
> self? Was this an oversight in the implementation of the feature - or on
> purpose?

It seems to me like the problem here is the generation of mail with a
sender address that is intentionally undeliverable. You probably want to
look at how you qualify bare local addresses and/or do masquerading to
solve the problem.

--
Now where did I hide that website...

Re: Q: Feature(badmx) - as added to version 8.14

"Bill Cole" wrote in message
news:bill-476FED.12154224112007@news.det.sbcglobal.net...
> In article ,
> "D. Stussy" wrote:
>
> > If I'm reading the ruleset correctly, I don't see an exemption for one's
self
> > (class $=w), one's relays (class $=R), one's masqueraders (class $=M), or or
> > one's virtual hosts (class $={VirtHosts}). Such an exemption could be
useful
> > where a server has multiple virtual domains where one or more of the virtual
> > hosts in those domains are to be outbound servers only.
> >
> > To help prevent inbound spam, I've placed DNS records that say "MX 0
> > localhost."
> > on virtual hosts that do not receive mail. ("localhost." is served in the
> > additonal section by my DNS servers with its usual addresses of 127.0.0.1
and
> > ::1.)
>
> That's wrong. You're telling anyone asking form that DNS record that
> they are the place to deliver mail for those domains, which is a lie.
>
> "MX 0 ." is a better approach for telling the world that a name is not a
> valid domain-part in an email address. The RHS of the record is an
> empty string, indicating quite explicitly that there is no mail
> exchanger for the domain. There is an expired ID for that practice and
> many places including Yahoo have it deployed widely.

OK, but as "." doesn't resolve to any address, the feature is still going to
reject the sender. That doesn't change anything with regard to this function.
Additionally, is "MX 0 ." legal, as specifying the null target isn't specifying
a valid host name? No one doubts whether "localhost" is a host name and
therefore a syntactically valid entry; one that also possesses an address-type
record to back that assertion. Furthermore, for the hosts concerned, real
people would figure out and send to the domain's main MX record set, not the
host's, so the only mail that would be (attempted to be) sent to the host is
spam, and having spam sit-and-spin in the spammer's machine's mail queue isn't
necessarily a bad thing.

> > However, these virtual hosts sometimes source mail (via contact web
> > ::forms
> > and cron jobs - e.g.), but if I were to use the stock feature defintion, it
> > appears that when the mail_from parameter is looked at, this locally
> > generated
> > mail would be blocked by this feature.
>
> Sending mail with an envelope sender whose domain part is not
> mail-routable is a bad thing to do. It SHOULD be routinely broken.

I didn't actually say that the hostname was used as the sender's domain, but
that is the default, so I understand your comment.

> > (Of course, mail to one's self
> > passing
> > through localhost works for the host itself and fails for everyone else. I
> > don't care if the host qualifies to be listed at rfc-ignorant.org as it's
not
> > sending off-host anyway, forwarding notwithstanding.)
> >
> > I thought that the intent of the feature was to block mail from OTHER
systems
> > that have bogus MX records. Presumedly, if one's own system has such a
> > record,
> > it is on purpose and/or by design, but should this feature block mail to
> > one's
> > self? Was this an oversight in the implementation of the feature - or on
> > purpose?
>
> It seems to me like the problem here is the generation of mail with a
> sender address that is intentionally undeliverable. You probably want to
> look at how you qualify bare local addresses and/or do masquerading to
> solve the problem.

Which for an automated report isn't a bad thing. Too bad that "cron" doesn't
use a sender of "<>" - but either the auto-mail is received or not; bounces
(beyond the log entries) won't be helpful. Masquerading and other such things
don't make inbound mail undeliverable. An MX to localhost does. It's necessary
to PREVENT attempts that hit the firewall (which count towards one's colocation
monthly traffic allocation).

However, none of that addresses my question. Was it the intent to NOT exempt
the local domains of the mail server from this test - or was that a design
oversight?

Re: Q: Feature(badmx) - as added to version 8.14

In article ,
"D. Stussy" wrote:

> "Bill Cole" wrote in message
> news:bill-476FED.12154224112007@news.det.sbcglobal.net...
> > In article ,
> > "D. Stussy" wrote:
> >
> > > If I'm reading the ruleset correctly, I don't see an exemption for one's
> self
> > > (class $=w), one's relays (class $=R), one's masqueraders (class $=M), or
> > > or
> > > one's virtual hosts (class $={VirtHosts}). Such an exemption could be
> useful
> > > where a server has multiple virtual domains where one or more of the
> > > virtual
> > > hosts in those domains are to be outbound servers only.
> > >
> > > To help prevent inbound spam, I've placed DNS records that say "MX 0
> > > localhost."
> > > on virtual hosts that do not receive mail. ("localhost." is served in
> > > the
> > > additonal section by my DNS servers with its usual addresses of 127.0.0.1
> and
> > > ::1.)
> >
> > That's wrong. You're telling anyone asking form that DNS record that
> > they are the place to deliver mail for those domains, which is a lie.
> >
> > "MX 0 ." is a better approach for telling the world that a name is not a
> > valid domain-part in an email address. The RHS of the record is an
> > empty string, indicating quite explicitly that there is no mail
> > exchanger for the domain. There is an expired ID for that practice and
> > many places including Yahoo have it deployed widely.
>
> OK, but as "." doesn't resolve to any address, the feature is still going to
> reject the sender.

Yes, but with very likely less DNS work.


> That doesn't change anything with regard to this
> function.
> Additionally, is "MX 0 ." legal, as specifying the null target isn't
> specifying
> a valid host name?

It is syntactically valid.

> No one doubts whether "localhost" is a host name and
> therefore a syntactically valid entry; one that also possesses an
> address-type
> record to back that assertion.

But it is a special name and address that means a different thing
practically to every resolver asking the question.


> Furthermore, for the hosts concerned, real
> people would figure out and send to the domain's main MX record set, not the
> host's, so the only mail that would be (attempted to be) sent to the host is
> spam, and having spam sit-and-spin in the spammer's machine's mail queue
> isn't
> necessarily a bad thing.

Are you saying you think real users would start stripping off elements
in the domain part of an email address until it worked?

There's no logical basis for that. It would be a really foolish thing to
do. There's no reason to expect that if user@foo.example.com fails
because of bad DNS for foo.example.com, then user@example.com will be a
logical place to send the mail.

As for 'spinning' in a spammer's machine, I think that's wishful
thinking. Given what I've seen of the sort of spamware that is commonly
used for sending to harvested addresses, there's not really any facility
for looping the message. That's more a feature of ancient real MTA's and
actively misconfigured modern ones (e.g. you can do it with sendmail if
you really want to...) than of the send-only stuff used by the
bottom-feeder spammers.

> > > However, these virtual hosts sometimes source mail (via contact web
> > > ::forms
> > > and cron jobs - e.g.), but if I were to use the stock feature defintion,
> > > it
> > > appears that when the mail_from parameter is looked at, this locally
> > > generated
> > > mail would be blocked by this feature.
> >
> > Sending mail with an envelope sender whose domain part is not
> > mail-routable is a bad thing to do. It SHOULD be routinely broken.
>
> I didn't actually say that the hostname was used as the sender's domain, but
> that is the default, so I understand your comment.
>
> > > (Of course, mail to one's self
> > > passing
> > > through localhost works for the host itself and fails for everyone else.
> > > I
> > > don't care if the host qualifies to be listed at rfc-ignorant.org as it's
> not
> > > sending off-host anyway, forwarding notwithstanding.)
> > >
> > > I thought that the intent of the feature was to block mail from OTHER
> systems
> > > that have bogus MX records. Presumedly, if one's own system has such a
> > > record,
> > > it is on purpose and/or by design, but should this feature block mail to
> > > one's
> > > self? Was this an oversight in the implementation of the feature - or on
> > > purpose?
> >
> > It seems to me like the problem here is the generation of mail with a
> > sender address that is intentionally undeliverable. You probably want to
> > look at how you qualify bare local addresses and/or do masquerading to
> > solve the problem.
>
> Which for an automated report isn't a bad thing. Too bad that "cron" doesn't
> use a sender of "<>" - but either the auto-mail is received or not; bounces
> (beyond the log entries) won't be helpful. Masquerading and other such
> things
> don't make inbound mail undeliverable. An MX to localhost does. It's
> necessary
> to PREVENT attempts that hit the firewall (which count towards one's
> colocation
> monthly traffic allocation).

Well, you can masquerade envelopes and make the mail seem to come from
some theoretically returnable addresses, or you can rewrite just the one
address you need broken to <> or to someplace real if you want to know
about failures. I use the User DB for this, because I never could get
the right mix of virtual/generic/masquerading to rewrite everything
correctly. All my cron (and other locally-generated) mail that
originates internally as being from various bare local user names across
a couple hundred machines leaves them all as being from the same set of
deliverable addresses mapped as both mailname and maildrop fields in a
userdb. Quite handy. I don't know if it is possible to map to null in
userdb, but for one address it shouldn't be hard to hack out a rule
directly (I can hear the horrified gasps already...)


> However, none of that addresses my question. Was it the intent to NOT exempt
> the local domains of the mail server from this test - or was that a design
> oversight?

I can't speak to the actual design intent, but that question is
puzzling. If sendmail knows the domain part of an address to be local,
i.e. Class w, it should never be trying any sort of name resolution on
it. It seems to me to be wrong for sendmail to be doing so. However,
that does not seem to me to be the situation you described: this is not
a local name but a sibling host in a common parent domain, right?

--
Now where did I hide that website...

Re: Q: Feature(badmx) - as added to version 8.14

"Bill Cole" wrote in message
news:bill-AFF6C5.21092625112007@news.det.sbcglobal.net...
> In article ,
> "D. Stussy" wrote:
>
> > "Bill Cole" wrote in message
> > news:bill-476FED.12154224112007@news.det.sbcglobal.net...
> > > In article ,
> > > "D. Stussy" wrote:
> > >
> > > > If I'm reading the ruleset correctly, I don't see an exemption for one's
> > self
> > > > (class $=w), one's relays (class $=R), one's masqueraders (class $=M),
or
> > > > or
> > > > one's virtual hosts (class $={VirtHosts}). Such an exemption could be
> > useful
> > > > where a server has multiple virtual domains where one or more of the
> > > > virtual
> > > > hosts in those domains are to be outbound servers only.
> > > >
> > > > To help prevent inbound spam, I've placed DNS records that say "MX 0
> > > > localhost."
> > > > on virtual hosts that do not receive mail. ("localhost." is served in
> > > > the
> > > > additonal section by my DNS servers with its usual addresses of
127.0.0.1
> > and
> > > > ::1.)
> > >
> > > That's wrong. You're telling anyone asking form that DNS record that
> > > they are the place to deliver mail for those domains, which is a lie.
> > >
> > > "MX 0 ." is a better approach for telling the world that a name is not a
> > > valid domain-part in an email address. The RHS of the record is an
> > > empty string, indicating quite explicitly that there is no mail
> > > exchanger for the domain. There is an expired ID for that practice and
> > > many places including Yahoo have it deployed widely.
> >
> > OK, but as "." doesn't resolve to any address, the feature is still going to
> > reject the sender.
>
> Yes, but with very likely less DNS work.

Rejecting the sender is the problem - when the sender is YOURSELF.

> > That doesn't change anything with regard to this
> > function.
> > Additionally, is "MX 0 ." legal, as specifying the null target isn't
> > specifying
> > a valid host name?
>
> It is syntactically valid.

But not semantically valid. "." is not a hostname. An MX record target (RHS)
is required to be a hostname.

> > No one doubts whether "localhost" is a host name and
> > therefore a syntactically valid entry; one that also possesses an
> > address-type
> > record to back that assertion.
>
> But it is a special name and address that means a different thing
> practically to every resolver asking the question.

Nonsense, and you know it. It means exactly the same thing to every host: Send
the mail to myself.

> > Furthermore, for the hosts concerned, real
> > people would figure out and send to the domain's main MX record set, not the
> > host's, so the only mail that would be (attempted to be) sent to the host is
> > spam, and having spam sit-and-spin in the spammer's machine's mail queue
> > isn't
> > necessarily a bad thing.
>
> Are you saying you think real users would start stripping off elements
> in the domain part of an email address until it worked?
>
> There's no logical basis for that. It would be a really foolish thing to
> do. There's no reason to expect that if user@foo.example.com fails
> because of bad DNS for foo.example.com, then user@example.com will be a
> logical place to send the mail.

Actually, I am expecting that a legitimate user may simply send directly to
user@example.com and not even worry about the specific hostname in the domain.
Even if they do decide to try the specific host, they will probably investigate
and immediately note the loopbacked MX record. If they don't, they're idiots no
smarter than spammers.

> As for 'spinning' in a spammer's machine, I think that's wishful
> thinking. Given what I've seen of the sort of spamware that is commonly
> used for sending to harvested addresses, there's not really any facility
> for looping the message. That's more a feature of ancient real MTA's and
> actively misconfigured modern ones (e.g. you can do it with sendmail if
> you really want to...) than of the send-only stuff used by the
> bottom-feeder spammers.

And you assume that all spammers have the most current spamware. How about
zombied machines? If a message is caught in a queue, then it may give the owner
of the zombied machine reason to investigate and find out his machine has been
taken over.

> > > > However, these virtual hosts sometimes source mail (via contact web
> > > > ::forms
> > > > and cron jobs - e.g.), but if I were to use the stock feature defintion,
> > > > it
> > > > appears that when the mail_from parameter is looked at, this locally
> > > > generated
> > > > mail would be blocked by this feature.
> > >
> > > Sending mail with an envelope sender whose domain part is not
> > > mail-routable is a bad thing to do. It SHOULD be routinely broken.
> >
> > I didn't actually say that the hostname was used as the sender's domain, but
> > that is the default, so I understand your comment.
> >
> > > > (Of course, mail to one's self
> > > > passing
> > > > through localhost works for the host itself and fails for everyone else.
> > > > I
> > > > don't care if the host qualifies to be listed at rfc-ignorant.org as
it's
> > not
> > > > sending off-host anyway, forwarding notwithstanding.)
> > > >
> > > > I thought that the intent of the feature was to block mail from OTHER
> > systems
> > > > that have bogus MX records. Presumedly, if one's own system has such a
> > > > record,
> > > > it is on purpose and/or by design, but should this feature block mail to
> > > > one's
> > > > self? Was this an oversight in the implementation of the feature - or
on
> > > > purpose?
> > >
> > > It seems to me like the problem here is the generation of mail with a
> > > sender address that is intentionally undeliverable. You probably want to
> > > look at how you qualify bare local addresses and/or do masquerading to
> > > solve the problem.
> >
> > Which for an automated report isn't a bad thing. Too bad that "cron"
doesn't
> > use a sender of "<>" - but either the auto-mail is received or not; bounces
> > (beyond the log entries) won't be helpful. Masquerading and other such
> > things
> > don't make inbound mail undeliverable. An MX to localhost does. It's
> > necessary
> > to PREVENT attempts that hit the firewall (which count towards one's
> > colocation
> > monthly traffic allocation).
>
> Well, you can masquerade envelopes and make the mail seem to come from
> some theoretically returnable addresses, or you can rewrite just the one
> address you need broken to <> or to someplace real if you want to know
> about failures. I use the User DB for this, because I never could get
> the right mix of virtual/generic/masquerading to rewrite everything
> correctly. All my cron (and other locally-generated) mail that
> originates internally as being from various bare local user names across
> a couple hundred machines leaves them all as being from the same set of
> deliverable addresses mapped as both mailname and maildrop fields in a
> userdb. Quite handy. I don't know if it is possible to map to null in
> userdb, but for one address it shouldn't be hard to hack out a rule
> directly (I can hear the horrified gasps already...)

Which has NOTHING to do with the point and question I raised.

> > However, none of that addresses my question. Was it the intent to NOT
exempt
> > the local domains of the mail server from this test - or was that a design
> > oversight?
>
> I can't speak to the actual design intent, but that question is
> puzzling. If sendmail knows the domain part of an address to be local,
> i.e. Class w, it should never be trying any sort of name resolution on
> it. It seems to me to be wrong for sendmail to be doing so. However,
> that does not seem to me to be the situation you described: this is not
> a local name but a sibling host in a common parent domain, right?

Then why did you even bother answering?

Additionally, it IS a local name that bears the loopbacked MX record. Why do
you think I asked why a class $=w sender wasn't excluded from the check? DUH!

Re: Q: Feature(badmx) - as added to version 8.14

In article ,
"D. Stussy" wrote:

> "Bill Cole" wrote in message
> news:bill-AFF6C5.21092625112007@news.det.sbcglobal.net...
> > In article ,
> > "D. Stussy" wrote:
> >
[...]
> > > Furthermore, for the hosts concerned, real
> > > people would figure out and send to the domain's main MX record set, not
> > > the
> > > host's, so the only mail that would be (attempted to be) sent to the host
> > > is
> > > spam, and having spam sit-and-spin in the spammer's machine's mail queue
> > > isn't
> > > necessarily a bad thing.
> >
> > Are you saying you think real users would start stripping off elements
> > in the domain part of an email address until it worked?
> >
> > There's no logical basis for that. It would be a really foolish thing to
> > do. There's no reason to expect that if user@foo.example.com fails
> > because of bad DNS for foo.example.com, then user@example.com will be a
> > logical place to send the mail.
>
> Actually, I am expecting that a legitimate user may simply send directly to
> user@example.com and not even worry about the specific hostname in the
> domain.
> Even if they do decide to try the specific host, they will probably
> investigate
> and immediately note the loopbacked MX record. If they don't, they're idiots
> no
> smarter than spammers.

People who can comprehend a loopback MX record are a pretty restricted
set.



> > As for 'spinning' in a spammer's machine, I think that's wishful
> > thinking. Given what I've seen of the sort of spamware that is commonly
> > used for sending to harvested addresses, there's not really any facility
> > for looping the message. That's more a feature of ancient real MTA's and
> > actively misconfigured modern ones (e.g. you can do it with sendmail if
> > you really want to...) than of the send-only stuff used by the
> > bottom-feeder spammers.
>
> And you assume that all spammers have the most current spamware.

Not at all. I'm saying that for the most part, there's no SMTP listener
on the machines spewing at very poorly harvested addresses, and even in
those cases where there is, it is unlikely to be significantly affected
by

> How about
> zombied machines? If a message is caught in a queue, then it may give the
> owner
> of the zombied machine reason to investigate and find out his machine has
> been
> taken over.

Most zombies have no mail queues that the rightful owner of the box has
any consciousness of. Even when a zombied box also has a real MTA
running on it, you have to work very hard with dedicated idiocy to make
any reasonably modern MTA trust MX records to tell it what mail domains
it is responsible for.

There may be some cases like compromised web form spamming where MX to
localhost failures are noisy in the form of double bounces, but null MX
has an identically noisy result that is slightly less confusing to the
reader of double bounces.



[...]

> > >Too bad that "cron" doesn't
> > > use a sender of "<>" - but either the auto-mail is received or not;
> > > bounces
> > > (beyond the log entries) won't be helpful. Masquerading and other such
> > > things
> > > don't make inbound mail undeliverable. An MX to localhost does. It's
> > > necessary
> > > to PREVENT attempts that hit the firewall (which count towards one's
> > > colocation
> > > monthly traffic allocation).



> > Well, you can masquerade envelopes and make the mail seem to come from
> > some theoretically returnable addresses, or you can rewrite just the one
> > address you need broken to <> or to someplace real if you want to know
> > about failures. I use the User DB for this, because I never could get
> > the right mix of virtual/generic/masquerading to rewrite everything
> > correctly. All my cron (and other locally-generated) mail that
> > originates internally as being from various bare local user names across
> > a couple hundred machines leaves them all as being from the same set of
> > deliverable addresses mapped as both mailname and maildrop fields in a
> > userdb. Quite handy. I don't know if it is possible to map to null in
> > userdb, but for one address it shouldn't be hard to hack out a rule
> > directly (I can hear the horrified gasps already...)
>
> Which has NOTHING to do with the point and question I raised.

Only because you persist in dodging the point that you should NEVER be
generating mail with an undeliverable sender domain. If you re-read the
above, you'll notice that you lamented cron not using <> and I offered
suggestions to make it do so.



> > > However, none of that addresses my question. Was it the intent to NOT
> exempt
> > > the local domains of the mail server from this test - or was that a
> > > design
> > > oversight?
> >
> > I can't speak to the actual design intent, but that question is
> > puzzling. If sendmail knows the domain part of an address to be local,
> > i.e. Class w, it should never be trying any sort of name resolution on
> > it. It seems to me to be wrong for sendmail to be doing so. However,
> > that does not seem to me to be the situation you described: this is not
> > a local name but a sibling host in a common parent domain, right?
>
> Then why did you even bother answering?

Have you noticed anyone who could actually explain Sendmail design
choices posting anything other than announcements in the past few
months?


> Additionally, it IS a local name that bears the loopbacked MX record. Why do
> you think I asked why a class $=w sender wasn't excluded from the check?
> DUH!

Because I am not seeing the same behavior, and you have been using
'domain' and 'hostname' in ways that implied to me that you think an MTA
should try to tell the difference.

As you and I seem not to be speaking the same language, I'll make sure
not to bother you with further responses.

--
Now where did I hide that website...