You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by mouss <mo...@netoyen.net> on 2008/10/22 09:28:02 UTC
bogusmx [Was: DNS restrictions for a mail server]
Matt Kettler a écrit :
> Stefan Jakobs wrote:
>> On Tuesday 21 October 2008 14:57, Matt Kettler wrote:
>> <snip>
>>
>>> In general it is recommended to not point a MX record to a CNAME, but
>>> that's just to reduce repetative querries. It is extraordinarily
>>> commonplace in the real world, and AFAIK 100% RFC legal.
>>>
>> I don't think so. See: http://www.rfc-ignorant.org/policy-bogusmx.php
>>
>> "Section 10.3 of RFC 2181 points out that pointing an MX RR at a hostname
>> which is actually a CNAME RR is invalid, and such hosts are also listed."
>>
>> <snip>
>>
>> Greetings
>> Stefan
>>
> Fair enough. It is still extraordinarily common.
>
> It's also not actually the point of the OP's restrictions, but it was a
> part of his example.
>
> (Also, I have to point out just because it's a RFC violation and RFCI
> chooses to list it does not make it useful in spam filtering. RFCI is
> interesting data, but it's also extremely FP prone nowdays)
>
The bogusmx and dsn sublists are still useful for score based filtering
(some people even use them in smtp reject as well, although I find that
"unsafe"). The current 50_scores.cf has:
score DNS_FROM_RFC_BOGUSMX 0 2.125 0 1.482 # n=0 n=2
score DNS_FROM_RFC_DSN 0 2.527 0 1.495 # n=0 n=2
It would be intersting to divide the bogusmx list according to the type
of error and see which errors are indicative of spam. I'll bet that the
CNAME error is neutral, but I have no evidence. but errors like the
following ones either mean spam or unreachable sender (and if you can't
reach the sender, it is probable that you want him to get an error to
fix his config):
$ host -t mx 06688.com
06688.com mail is handled by 0 dev.null.
$ host -t mx 0h.cn
0h.cn mail is handled by 10 mail.0h.cn.$ host mail.0h.cn.
Host mail.0h.cn. not found: 3(NXDOMAIN)
$ host -t mx socks.xmission.com
socks.xmission.com mail is handled by 10 127.0.0.1
$ host -t mx 3banatomy.co.kr
3banatomy.co.kr has no MX record
Re: bogusmx [Was: DNS restrictions for a mail server]
Posted by Kai Schaetzl <ma...@conactive.com>.
Benny Pedersen wrote on Fri, 24 Oct 2008 02:38:13 +0200 (CEST):
> not using cnames olso works 100% of time, but maybe you can show example
> where it does not and where you shows cnames solves it nicely ?
That's going way off-topic now. Could you (anyone) move this to private,
please? Thanks.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
Re: bogusmx [Was: DNS restrictions for a mail server]
Posted by Jonas Eckerman <jo...@frukt.org>.
Benny Pedersen wrote:
[About CNAME MX records...]
>> rfc means 'request for comment'. and rfc's change as technology changes.
>
> but not much in smtp have changed since first version deployed
The RFC in question (RFC2181) is about DNS, not SMTP.
Actually, in STD0010 and STD0013 (the standards documents
describing SMTP and DNS), there is no clear prohibition against
CNAME MX records.
There is this in STD0010:
---8<---
There is one other special case. If the response contains an
answer which is a CNAME RR, it indicates that REMOTE is actually
an alias for some other domain name. The query should be repeated
with the canonical domain name.
---8<---
Using a CNAME MX record might break the standards track proposal
RFC2181, but (AFAICS) it does not break the actual standards
(STD0010, STD0013). OTH, not resolving a CNAME MX record to the
actual A record does break the SMTP standard (STD0010) from what
I can see.
Note:
I only browsed STD0010 and STD0013 now, and one of the
improvements in later RFCs is the use of MUST and SHOULD to make
requirements and suggestions easier to distinguish. So if this
matters to you, read the documents.
References:
STD0010: <http://vvv.truls.org/RFCs/pages/std10.html>
STD0013: <http://vvv.truls.org/RFCs/pages/std13.html>
RFC2181: <http://vvv.truls.org/RFCs/pages/rfc2181.html>
Appendix:
This really has little bearing on wether one can refuse to accept
a mail with a sender domain the MX of wich points to a CNAME. Of
course one can refuse to accept such a mail. One can refuse to
accept mail based on the air humidity in Glasgow and the
temperature at Luleå if one wants to.
Regards
/Jonas
--
Jonas Eckerman, FSDB & Fruktträdet
http://whatever.frukt.org/
http://www.fsdb.org/
http://www.frukt.org/
Re: bogusmx [Was: DNS restrictions for a mail server]
Posted by Benny Pedersen <me...@junc.org>.
On Thu, October 23, 2008 19:29, Michael Scheidell wrote:
> we arn't arguing rfc's, and by '99% of the time', actually, it works
> 100% of the time unless you use the rfc-ignorant blacklists.
being rfc compliant olso works
> rfc means 'request for comment'. and rfc's change as technology changes.
but not much in smtp have changed since first version deployed
> I don't know if, or, since you are the expert in this, maybe you can
> enlighten us.. What major mail server can't deliver email to a mx record
> that is a cname? if there were technical problems, then the major email
> hosted providers would not be using it.
not using cnames olso works 100% of time, but maybe you can show example
where it does not and where you shows cnames solves it nicely ?
--
Benny Pedersen
Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: bogusmx [Was: DNS restrictions for a mail server]
Posted by mouss <mo...@netoyen.net>.
Benny Pedersen a écrit :
> On Thu, October 23, 2008 20:43, mouss wrote:
>
>> subdomains, as used to be the case when all the internet was unix,
>> but this is no more the case).
>
> lets hope thay are deploying dkim next then, it was newer meant to rewrite
> any header from sender to tecipient, but still some do this
>
I don't think "they" rewrite headers. only envelope recipient. anyway,
the result in general is mail rejected, so with or without dkim, it'll
probably break.
Re: bogusmx [Was: DNS restrictions for a mail server]
Posted by Benny Pedersen <me...@junc.org>.
On Thu, October 23, 2008 20:43, mouss wrote:
> subdomains, as used to be the case when all the internet was unix,
> but this is no more the case).
lets hope thay are deploying dkim next then, it was newer meant to rewrite
any header from sender to tecipient, but still some do this
--
Benny Pedersen
Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: bogusmx [Was: DNS restrictions for a mail server]
Posted by mouss <mo...@netoyen.net>.
Michael Scheidell a écrit :
> we arn't arguing rfc's, and by '99% of the time', actually, it works
> 100% of the time unless you use the rfc-ignorant blacklists.
>
> rfc means 'request for comment'. and rfc's change as technology changes.
>
> I don't know if, or, since you are the expert in this, maybe you can
> enlighten us.. What major mail server can't deliver email to a mx record
> that is a cname? if there were technical problems, then the major email
> hosted providers would not be using it.
>
>
it probably works in many cases, but it's not reliably. Some MTAs do
rewrite the recipient address, which may or may not work. I mean, if you
have this:
example.com. MX 1 mx.example.com.
mx.example.com. CNAME mx1.example.com.
then some MTAs will rewrite foo@example.com to foo@mx1.example.com. and
this may cause problems (this will work in domains that accept mail for
all subdomains, as used to be the case when all the internet was unix,
but this is no more the case).
Re: bogusmx [Was: DNS restrictions for a mail server]
Posted by SM <sm...@resistor.net>.
At 10:29 23-10-2008, Michael Scheidell wrote:
>we arn't arguing rfc's, and by '99% of the time', actually, it works
>100% of the time unless you use the rfc-ignorant blacklists.
If it works 100% of the time for you, what can I say.
>I don't know if, or, since you are the expert in this, maybe you can
>enlighten us.. What major mail server can't deliver email to a mx
>record that is a cname? if there were technical problems, then the
>major email hosted providers would not be using it.
I doubt I'm an expert. Current versions of Postfix and sendmail
handle the CNAME. There are some configuration cases where sendmail
may generate a delivery failure. I don't use major email hosted
providers as a yardstick. There was one major email hosted provider
that rejected messages if the sending domain listed an IPv6 host as
one of the MX targets.
I suggest that we agree to disagree as we are not arguing about the same thing.
Regards,
-sm
Re: bogusmx [Was: DNS restrictions for a mail server]
Posted by Michael Scheidell <sc...@secnap.net>.
we arn't arguing rfc's, and by '99% of the time', actually, it works
100% of the time unless you use the rfc-ignorant blacklists.
rfc means 'request for comment'. and rfc's change as technology changes.
I don't know if, or, since you are the expert in this, maybe you can
enlighten us.. What major mail server can't deliver email to a mx record
that is a cname? if there were technical problems, then the major email
hosted providers would not be using it.
--
Michael Scheidell, CTO
Phone: 561-999-5000, x 1259
> *| *SECNAP Network Security Corporation
* Certified SNORT Integrator
* King of Spam Filters, SC Magazine 2008
* Information Security Award 2008, Info Security Products Guide
* CRN Magazine Top 40 Emerging Security Vendors
_________________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.spammertrap.com
_________________________________________________________________________
Re: bogusmx [Was: DNS restrictions for a mail server]
Posted by SM <sm...@resistor.net>.
Hi Michael,
At 08:58 23-10-2008, Michael Scheidell wrote:
>Why? Its being widely used by 'email experts' and hosted email anti-spam
>companies now.
The section of the SMTP standard that discusses about MX records is
commonly misinterpreted by some people. Even if CNAMEs are widely
used, that doesn't mean that it is correct. A lot of things works
99% of the time.
Quoting RFC 2182 which explains the matter:
"Searching for either NS or MX records causes "additional section
processing" in which address records associated with the value of the
record sought are appended to the answer. This helps avoid needless
extra queries that are easily anticipated when the first was made.
Additional section processing does not include CNAME records, let
alone the address records that may be associated with the canonical
name derived from the alias. Thus, if an alias is used as the value
of an NS or MX record, no address will be returned with the NS or MX
value. This can cause extra queries, and extra network burden, on
every query. It is trivial for the DNS administrator to avoid this
by resolving the alias and placing the canonical name directly in the
affected record just once when it is updated or installed. In some
particular hard cases the lack of the additional section address
records in the results of a NS lookup can cause the request to fail."
The SMTP standard discusses how to locate a target host and points to
the above section to explain the prohibition of CNAMEs. A strict
reading of the section about locating a target host shows that the
behavior is undefined when CNAMEs are used. This means that you
might end up with unexpected results. One can go back to the
standard about mail routing to understand how mail preferences are
processed to determine where a message should be delivered. That
influenced the decision on discouraging CNAMEs in the data section of MX RRs.
My comment is not about bogusmx or antispam; it's about how to
determine in a reliable way where to deliver a message.
Regards,
-sm
Re: bogusmx [Was: DNS restrictions for a mail server]
Posted by Michael Scheidell <sc...@secnap.net>.
> At 15:01 22-10-2008, Michael Scheidell wrote:
>> Maybe rfc's need to change.. There is no modern software that can't send to
>> a cnamed mx or mx'ed cname, whatever.
>
> I doubt that it will be changed to accommodate that. It's not only a
> matter of software. Such a change would have an impact on DNS.
>
> Regards,
> -sm
>
Why? Its being widely used by 'email experts' and hosted email anti-spam
companies now.
Happens now and you don't even see it.
--
Michael Scheidell, CTO
>|SECNAP Network Security
Winner 2008 Network Products Guide Hot Companies
FreeBSD SpamAssassin Ports maintainer
_________________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.spammertrap.com
_________________________________________________________________________
Re: bogusmx [Was: DNS restrictions for a mail server]
Posted by SM <sm...@resistor.net>.
At 15:01 22-10-2008, Michael Scheidell wrote:
>Maybe rfc's need to change.. There is no modern software that can't send to
>a cnamed mx or mx'ed cname, whatever.
I doubt that it will be changed to accommodate that. It's not only a
matter of software. Such a change would have an impact on DNS.
Regards,
-sm
Re: bogusmx [Was: DNS restrictions for a mail server]
Posted by mouss <mo...@netoyen.net>.
Michael Scheidell a écrit :
>> 3banatomy.co.kr
>
> Minor point, rfc's don't require an mx record an a record will satisfy the
> rfc's just fine. (and one of the major saas email anti-spam providers used
> to use cname records for all their clients.. Yes, they took them off, one at
> a time, as clients complianted that they were blacklisted by
> bogusmx.rfc-ignorant.com..
>
"other" customers should complain too:
$ host smtp.secureserver.net
smtp.secureserver.net is an alias for smtp.where.secureserver.net.
smtp.where.secureserver.net has address 64.202.166.12
> Maybe rfc's need to change.. There is no modern software that can't send to
> a cnamed mx or mx'ed cname, whatever.
>
>
>
> host -t a 3banatomy.co.kr
> 3banatomy.co.kr has address 211.189.26.139
>
mea culpa. I've been tooo lazy. I'll have to script that so that I don't
forget again!
Re: bogusmx [Was: DNS restrictions for a mail server]
Posted by Michael Scheidell <sc...@secnap.net>.
> 3banatomy.co.kr
Minor point, rfc's don't require an mx record an a record will satisfy the
rfc's just fine. (and one of the major saas email anti-spam providers used
to use cname records for all their clients.. Yes, they took them off, one at
a time, as clients complianted that they were blacklisted by
bogusmx.rfc-ignorant.com..
Maybe rfc's need to change.. There is no modern software that can't send to
a cnamed mx or mx'ed cname, whatever.
host -t a 3banatomy.co.kr
3banatomy.co.kr has address 211.189.26.139
--
Michael Scheidell, CTO
>|SECNAP Network Security
Winner 2008 Network Products Guide Hot Companies
FreeBSD SpamAssassin Ports maintainer
_________________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.spammertrap.com
_________________________________________________________________________