Re: bogusmx [Was: DNS restrictions for a mail server]

[Jonas Eckerman]

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: 
STD0013: 
RFC2181: 

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]

[Kai Schaetzl]

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]

[mouss]

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]

[Benny Pedersen]

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]

[Benny Pedersen]

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]

[mouss]

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 [EMAIL PROTECTED] to [EMAIL PROTECTED] 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]

[SM]

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]

[Michael Scheidell]

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]

[SM]

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]

[Michael Scheidell]

> 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]

[mouss]

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]

[SM]

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]

[Michael Scheidell]

>  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
_

bogusmx [Was: DNS restrictions for a mail server]

[mouss]

Matt Kettler a écrit :
> Stefan Jakobs wrote:
>> On Tuesday 21 October 2008 14:57, Matt Kettler wrote:
>> 
>>   
>>> 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."
>>
>> 
>>
>> 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