You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Sebastian Ries <Se...@dtnet.de> on 2008/10/21 14:37:59 UTC
OT: DNS restrictions for a mail server
Hi there
I just want to know some opinions on the following DNS Setup for a mail
server:
# host -t MX example.com
example.com mail is handled by 100 mail.example.com.
# host mail.example.com
mail.example.com is an alias for hostname.example.com.
hostname.example.com has address 1.2.3.4
# host 1.2.3.4
4.3.2.1.in-addr.arpa domain name pointer hostname.example.com.
The mailserver (postfix) connects saying it is hostname.example.com.
Should this be a correct setup?
One partner we want to send mails to does BOUNCE mails with
554 5.7.1 DNS Blacklisted by in-addr.arpa (in reply to MAIL FROM
command)
Do you think this is correct?
I think this also prevents from getting mail from googlemail:
sr@ben:~$ host -t MX googlemail.com
googlemail.com mail is handled by 5 gmail-smtp-in.l.google.com.
googlemail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.
googlemail.com mail is handled by 10 alt2.gmail-smtp-in.l.google.com.
googlemail.com mail is handled by 50 gsmtp147.google.com.
googlemail.com mail is handled by 50 gsmtp183.google.com.
sr@ben:~$ host gmail-smtp-in.l.google.com.
gmail-smtp-in.l.google.com has address 209.85.129.27
gmail-smtp-in.l.google.com has address 209.85.129.114
sr@ben:~$ host 209.85.129.27
27.129.85.209.in-addr.arpa domain name pointer fk-in-f27.google.com.
Is this true?
Regards
Sebastian Ries
--
------------------------------------------------------------
DT Netsolution GmbH - Talaeckerstr. 30 - D-70437 Stuttgart
Tel: +49-711-849910-36 Fax: +49-711-849910-936
WEB: http://www.dtnet.de/ email: Sebastian.Ries@dtnet.de
Re: OT: DNS restrictions for a mail server
Posted by Byung-Hee HWANG <bh...@izb.knu.ac.kr>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sebastian Ries wrote:
> Hi there
>
> I just want to know some opinions on the following DNS Setup for a mail
> server:
>
> # host -t MX example.com
> example.com mail is handled by 100 mail.example.com.
>
> # host mail.example.com
> mail.example.com is an alias for hostname.example.com.
> hostname.example.com has address 1.2.3.4
>
> # host 1.2.3.4
> 4.3.2.1.in-addr.arpa domain name pointer hostname.example.com.
>
> The mailserver (postfix) connects saying it is hostname.example.com.
>
>
> Should this be a correct setup?
It looks like CNAME error. See RFC 974 ;;
> One partner we want to send mails to does BOUNCE mails with
> 554 5.7.1 DNS Blacklisted by in-addr.arpa (in reply to MAIL FROM
> command)
> Do you think this is correct?
>
> I think this also prevents from getting mail from googlemail:
> sr@ben:~$ host -t MX googlemail.com
> googlemail.com mail is handled by 5 gmail-smtp-in.l.google.com.
> googlemail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.
> googlemail.com mail is handled by 10 alt2.gmail-smtp-in.l.google.com.
> googlemail.com mail is handled by 50 gsmtp147.google.com.
> googlemail.com mail is handled by 50 gsmtp183.google.com.
> sr@ben:~$ host gmail-smtp-in.l.google.com.
> gmail-smtp-in.l.google.com has address 209.85.129.27
> gmail-smtp-in.l.google.com has address 209.85.129.114
> sr@ben:~$ host 209.85.129.27
> 27.129.85.209.in-addr.arpa domain name pointer fk-in-f27.google.com.
>
> Is this true?
Google is true. That's basic rule of DNS ;;
> Regards
> Sebastian Ries
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iEYEARECAAYFAkkBS1kACgkQB00DNxnlnTarngCeI+GYTLl3iA0i/0p4xFEuiyor
CYAAnApt9bzG2ng+MYmAmjHfphyJudBm
=75AD
-----END PGP SIGNATURE-----
Re: OT: DNS restrictions for a mail server
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> >># host mail.example.com
> >>mail.example.com is an alias for hostname.example.com.
> >>hostname.example.com has address 1.2.3.4
> >
> >
> >Wrong. The MX record has to point to an A name, not a CNAME.
On 22.10.08 21:21, Len Conrad wrote:
> what?
>
> MX record's data field is a domain name
>
> That domain name owns one or more A records.
>
> With mail, the shortest resolution path is always best practice, and
> resolving through a CNAME is not the shortest.
Isn't that exactly what Joseph Brennan said/wrote?
> Similarly, an MX's IP should have only one PTR record, whose domain name
> in the data field "matches" with an A record:
This is not so important, unless they are used for outgoing mail.
I don't know of anybody who checks for validity of reverse RRs of named MX
records point to (why to check that? to refuse delivering mail to provided
address? what will it tell the sender?), and I know of domains where MXes do
not have PTR records and nothing happens.
> d.c.b.a.in-addr.arpa. PTR label.domain.tld.
>
> label.domain.tld. A a.b.c.d
This should apply for everyone who wants to use any remote services, which
is not the MX case (the MX indicate inbound, not outbound servers).
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
There's a long-standing bug relating to the x86 architecture that
allows you to install Windows. -- Matthew D. Fuller
Re: OT: DNS restrictions for a mail server
Posted by Len Conrad <LC...@Go2France.com>.
>># host mail.example.com
>>mail.example.com is an alias for hostname.example.com.
>>hostname.example.com has address 1.2.3.4
>
>
>Wrong. The MX record has to point to an A name, not a CNAME.
what?
MX record's data field is a domain name
That domain name owns one or more A records.
With mail, the shortest resolution path is always best practice, and resolving through a CNAME is not the shortest.
Similarly, an MX's IP should have only one PTR record, whose domain name in the data field "matches" with an A record:
d.c.b.a.in-addr.arpa. PTR label.domain.tld.
label.domain.tld. A a.b.c.d
Len
______________________________________________
IMGate OpenSource Mail Firewall www.IMGate.net
Re: OT: DNS restrictions for a mail server
Posted by Joseph Brennan <br...@columbia.edu>.
--On Tuesday, October 21, 2008 2:37 PM +0200 Sebastian Ries <
Sebastian.Ries@dtnet.de> wrote:
># host -t MX example.com
> example.com mail is handled by 100 mail.example.com.
>
># host mail.example.com
> mail.example.com is an alias for hostname.example.com.
> hostname.example.com has address 1.2.3.4
Wrong. The MX record has to point to an A name, not a CNAME.
Joseph Brennan
Lead Email Systems Engineer
Columbia University Information Technology
Re: OT: DNS restrictions for a mail server
Posted by Bernd Petrovitsch <be...@firmix.at>.
On Wed, 2008-10-22 at 15:49 +0200, mouss wrote:
[...]
> In my understanding, these are different concepts. In particular, RMX
> doesn't hijack the TXT record, which is one of the major sins of SPF.
SPF has it's own record type. Use "TYPE99" if your named doesn't
understand "SPF" yet.
The TXT record "hack" was IMHO just a means to be able to deploy
something.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Re: OT: DNS restrictions for a mail server
Posted by mouss <mo...@netoyen.net>.
Daniel J McDonald wrote:
> On Wed, 2008-10-22 at 23:59 +0200, Jonas Eckerman wrote:
>> Matus UHLAR - fantomas wrote:
>>
>>>> In my understanding, these are different concepts. In particular, RMX
>>>> doesn't hijack the TXT record, which is one of the major sins of SPF.
>>> Yes, but they both were designed to do the same work. SPF however can do
>>> more. TXT was used because nothing else could, at least I think so.
>> They could have used a prefix "host" to avoid hijacking the main
>> TXT record. (So you'd query the TXT record for
>> "__spf__.domain.tld" or something like that instead of the TXT
>> record for "domain.tld" when checking SPF.
>
> Could of, but underscores are not a legal character in domain names.
no, they are perfectly legal "in domain names". They are being used in
DKIM. don't confuse with hostnames.
>
> And now BIND 9.4 supports the SPF RR type, so we just have to wait a
> decade or two until everyone still running bind 4.0 has a chance to
> upgrade.... ;-)
>
and a century until everyone has a chance to upgrade their mail software
to use the new record ;-p
Re: OT: DNS restrictions for a mail server
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> On Wed, 2008-10-22 at 23:59 +0200, Jonas Eckerman wrote:
> > Matus UHLAR - fantomas wrote:
> >
> > >> In my understanding, these are different concepts. In particular, RMX
> > >> doesn't hijack the TXT record, which is one of the major sins of SPF.
> >
> > > Yes, but they both were designed to do the same work. SPF however can do
> > > more. TXT was used because nothing else could, at least I think so.
> >
> > They could have used a prefix "host" to avoid hijacking the main
> > TXT record. (So you'd query the TXT record for
> > "__spf__.domain.tld" or something like that instead of the TXT
> > record for "domain.tld" when checking SPF.
On 28.10.08 07:01, Daniel J McDonald wrote:
> Could of, but underscores are not a legal character in domain names.
in _host_ names. they are being tested in other DNS names, like SRV
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
99 percent of lawyers give the rest a bad name.
Re: OT: DNS restrictions for a mail server
Posted by Daniel J McDonald <da...@austinenergy.com>.
On Wed, 2008-10-22 at 23:59 +0200, Jonas Eckerman wrote:
> Matus UHLAR - fantomas wrote:
>
> >> In my understanding, these are different concepts. In particular, RMX
> >> doesn't hijack the TXT record, which is one of the major sins of SPF.
>
> > Yes, but they both were designed to do the same work. SPF however can do
> > more. TXT was used because nothing else could, at least I think so.
>
> They could have used a prefix "host" to avoid hijacking the main
> TXT record. (So you'd query the TXT record for
> "__spf__.domain.tld" or something like that instead of the TXT
> record for "domain.tld" when checking SPF.
Could of, but underscores are not a legal character in domain names.
And now BIND 9.4 supports the SPF RR type, so we just have to wait a
decade or two until everyone still running bind 4.0 has a chance to
upgrade.... ;-)
--
Daniel J McDonald, CCIE #2495, CISSP #78281, CNX
Austin Energy
http://www.austinenergy.com
Re: OT: DNS restrictions for a mail server
Posted by Jonas Eckerman <jo...@frukt.org>.
Matus UHLAR - fantomas wrote:
>> In my understanding, these are different concepts. In particular, RMX
>> doesn't hijack the TXT record, which is one of the major sins of SPF.
> Yes, but they both were designed to do the same work. SPF however can do
> more. TXT was used because nothing else could, at least I think so.
They could have used a prefix "host" to avoid hijacking the main
TXT record. (So you'd query the TXT record for
"__spf__.domain.tld" or something like that instead of the TXT
record for "domain.tld" when checking SPF.
/Jonas
--
Jonas Eckerman, FSDB & Fruktträdet
http://whatever.frukt.org/
http://www.fsdb.org/
http://www.frukt.org/
Re: OT: DNS restrictions for a mail server
Posted by Kai Schaetzl <ma...@conactive.com>.
Dan McDonald wrote on Wed, 22 Oct 2008 11:11:13 -0500:
> I'm not certain what you are talking about. SPF is very commonly
> deployed.
>
> http://www.openspf.org/Statistics
I don't see that you can deduce "is very commonly deployed" from that page.
> See especially http://utility.nokia.net/~lars/meter/spf.html
These figures are bogus.
> Lars Eggert added SPF to his set of experimental deployment meters. At the
> moment his statistics covers only "top"-Alexa sites for ten countries and
> the world, plus the domains used in e-mail addresses of current
> Internet-draft authors. On that somewhat limited base almost half of
> these "top"-domains publish some kind of SPF policy.
BTW: have you checked how SPF plays out in your SA rules? I find that SPF_FAIL,
SPF_HELO_PASS or SPF_PASS all have over 90/95% ham which makes the rules somewhat
indistinguishable. This means that 95% of the mail that fails SPF is actually
desired mail. On the other hand the SPF_HELO_PASS/SPF_PASS seems to be indicate of ham, it
hits on 95% ham. e.g. you can use it for negative scoring at least a little bit.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
Re: OT: DNS restrictions for a mail server
Posted by mouss <mo...@netoyen.net>.
McDonald, Dan a écrit :
>>> On 22.10.08 15:49, mouss wrote:
>>>> In my understanding, these are different concepts. In particular, RMX
>>>> doesn't hijack the TXT record, which is one of the major sins of SPF.
>>> Yes, but they both were designed to do the same work. SPF however can do
>>> more. TXT was used because nothing else could, at least I think so.
>>>
>
> RFC 4408, section 3.1.1, defines a new RR type for SPF.
yes, but my feeling is that it's too late. The purists are long gone
away. I think there were many tactical errors (SPF was presented as
"simple to implement" thanks to TXT, instead of "will help in this and
that. and for compatibility, we could use a TXT record...". other
tactical errors were "SPF will solve the spam problem" [and no, I am not
inventing that. search...] which appears to be one of the reasons why
outblaze removed their SPF records).
> But waiting for
> everyone in the world to upgrade their DNS resolver to handle the new RR
> type would have greatly slowed the adoption of SPF.
>
>> Maybe. but hijacking the TXT record got many people against SPF. and it
>> doesn't look like SPF is widespread. so the "compatibility"/-ease of
>> deployment argument didn't really catch.
>
> I'm not certain what you are talking about. SPF is very commonly
> deployed.
>
depends on how to quantify "widespread". I personally consider 12.6%
(after this many years) not to be "widespread", exceptionally since this
includes "corner cases" (cases when almost everybody agrees that SPF is
good for. This includes domains that never send mail, ... etc) as well
as "+all" records.
> http://www.openspf.org/Statistics
> See especially http://utility.nokia.net/~lars/meter/spf.html
>
>
Re: OT: DNS restrictions for a mail server
Posted by "McDonald, Dan" <Da...@austinenergy.com>.
On Wed, 2008-10-22 at 17:04 +0200, mouss wrote:
> Matus UHLAR - fantomas a écrit :
> >>> On 21.10.08 19:31, mouss wrote:
> >>>> Search for RMX (Reverse Mail eXchanger).
> > On 22.10.08 15:49, mouss wrote:
> >> In my understanding, these are different concepts. In particular, RMX
> >> doesn't hijack the TXT record, which is one of the major sins of SPF.
> >
> > Yes, but they both were designed to do the same work. SPF however can do
> > more. TXT was used because nothing else could, at least I think so.
> >
>
RFC 4408, section 3.1.1, defines a new RR type for SPF. But waiting for
everyone in the world to upgrade their DNS resolver to handle the new RR
type would have greatly slowed the adoption of SPF.
> Maybe. but hijacking the TXT record got many people against SPF. and it
> doesn't look like SPF is widespread. so the "compatibility"/-ease of
> deployment argument didn't really catch.
I'm not certain what you are talking about. SPF is very commonly
deployed.
http://www.openspf.org/Statistics
See especially http://utility.nokia.net/~lars/meter/spf.html
--
Daniel J McDonald, CCIE #2495, CISSP #78281, CNX
Austin Energy
http://www.austinenergy.com
Re: OT: DNS restrictions for a mail server
Posted by mouss <mo...@netoyen.net>.
Matus UHLAR - fantomas a écrit :
>>> On 21.10.08 19:31, mouss wrote:
>>>> Search for RMX (Reverse Mail eXchanger).
>>>>
>>>> didn't go far for now.
>
>>> Yes, was kinda superseded by SPF,
>
> On 22.10.08 15:49, mouss wrote:
>> In my understanding, these are different concepts. In particular, RMX
>> doesn't hijack the TXT record, which is one of the major sins of SPF.
>
> Yes, but they both were designed to do the same work. SPF however can do
> more. TXT was used because nothing else could, at least I think so.
>
Maybe. but hijacking the TXT record got many people against SPF. and it
doesn't look like SPF is widespread. so the "compatibility"/-ease of
deployment argument didn't really catch.
>>> which may also require additional DNS queries :)
>> sure, but this also prevents silly decisions by poor dns caching
>> implementations (In particular, implementations that set a reputation
>> based on one spf lookup).
>
> Hmm?
hot... mail.
This is one of the reasons I don't set SPF records anymore.
Re: OT: DNS restrictions for a mail server
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> > On 21.10.08 19:31, mouss wrote:
> >> Search for RMX (Reverse Mail eXchanger).
> >>
> >> didn't go far for now.
> > Yes, was kinda superseded by SPF,
On 22.10.08 15:49, mouss wrote:
> In my understanding, these are different concepts. In particular, RMX
> doesn't hijack the TXT record, which is one of the major sins of SPF.
Yes, but they both were designed to do the same work. SPF however can do
more. TXT was used because nothing else could, at least I think so.
> > which may also require additional DNS queries :)
>
> sure, but this also prevents silly decisions by poor dns caching
> implementations (In particular, implementations that set a reputation
> based on one spf lookup).
Hmm?
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
The only substitute for good manners is fast reflexes.
Re: OT: DNS restrictions for a mail server
Posted by mouss <mo...@netoyen.net>.
Matus UHLAR - fantomas a écrit :
>> Jorge Valdes a écrit :
>>> Matus UHLAR - fantomas wrote:
>>>
>>>>> The point of MX is to point to hosts that receive mail, if you send mail to
>>>>> someone.
>>>>>
>>>>> The point of PTR is to provide host name when you receive mail from someone.
>>>>>
>>>>> The PTR has NOTHING to do with MX records and vice versa!
>>>>>
>>>>
>>> So maybe there should be a new type of DNS record: MS (name suggestions
>>> welcomed :) ) to let everyone know the server is an _outbound_ only mail
>>> server: a server that sends mail for a domain that _may_ also receive
>>> mail for the domain. This is a lot simpler than having to parse a SPF
>>> record, which may also require additional DNS queries.
>
> On 21.10.08 19:31, mouss wrote:
>> Search for RMX (Reverse Mail eXchanger).
>>
>> didn't go far for now.
>
> Yes, was kinda superseded by SPF,
In my understanding, these are different concepts. In particular, RMX
doesn't hijack the TXT record, which is one of the major sins of SPF.
> which may also require additional DNS
> queries :)
sure, but this also prevents silly decisions by poor dns caching
implementations (In particular, implementations that set a reputation
based on one spf lookup).
Re: OT: DNS restrictions for a mail server
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> Jorge Valdes a écrit :
> > Matus UHLAR - fantomas wrote:
> >
> >>> The point of MX is to point to hosts that receive mail, if you send mail to
> >>> someone.
> >>>
> >>> The point of PTR is to provide host name when you receive mail from someone.
> >>>
> >>> The PTR has NOTHING to do with MX records and vice versa!
> >>>
> >>
> > So maybe there should be a new type of DNS record: MS (name suggestions
> > welcomed :) ) to let everyone know the server is an _outbound_ only mail
> > server: a server that sends mail for a domain that _may_ also receive
> > mail for the domain. This is a lot simpler than having to parse a SPF
> > record, which may also require additional DNS queries.
On 21.10.08 19:31, mouss wrote:
> Search for RMX (Reverse Mail eXchanger).
>
> didn't go far for now.
Yes, was kinda superseded by SPF, which may also require additional DNS
queries :)
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Quantum mechanics: The dreams stuff is made of.
Re: OT: DNS restrictions for a mail server
Posted by mouss <mo...@netoyen.net>.
Jorge Valdes a écrit :
> Matus UHLAR - fantomas wrote:
>
>>> The point of MX is to point to hosts that receive mail, if you send mail to
>>> someone.
>>>
>>> The point of PTR is to provide host name when you receive mail from someone.
>>>
>>> The PTR has NOTHING to do with MX records and vice versa!
>>>
>>
> So maybe there should be a new type of DNS record: MS (name suggestions
> welcomed :) ) to let everyone know the server is an _outbound_ only mail
> server: a server that sends mail for a domain that _may_ also receive
> mail for the domain. This is a lot simpler than having to parse a SPF
> record, which may also require additional DNS queries.
>
Search for RMX (Reverse Mail eXchanger).
didn't go far for now.
> [snip]
>
Re: OT: DNS restrictions for a mail server
Posted by Jorge Valdes <jv...@intercom.com.sv>.
Matus UHLAR - fantomas wrote:
> > The point of MX is to point to hosts that receive mail, if you send mail to
> > someone.
> >
> > The point of PTR is to provide host name when you receive mail from someone.
> >
> > The PTR has NOTHING to do with MX records and vice versa!
> >
>
So maybe there should be a new type of DNS record: MS (name suggestions
welcomed :) ) to let everyone know the server is an _outbound_ only mail
server: a server that sends mail for a domain that _may_ also receive
mail for the domain. This is a lot simpler than having to parse a SPF
record, which may also require additional DNS queries.
DNS Configuration Examples:
1.- If a company has a single mail server for both inbound and outbound,
it would be required for them to setup both an MX record and a MS
record, i.e.:
example.com IN MX 10 mail
example.com IN MS 10 mail
2.- If a company has different servers for inbound and outbound mail,
they could setup different records to allow for all servers to be specified:
example.com IN MX 10 mail1
example.com IN MX 20 mail2
example.com IN MS 10 smtp1
example.com IN MS 20 smtp2
When a mail server gets a connection, it would ask for the PTR record in
order to check HELO|EHLO argument and get the host's name; when the MAIL
FROM: command is received, the domain part could be used to get the MS
record and optionally reject the sender if the hostname from the
connection is not listed in the MS record list. If we do allow the
sender, that could later trigger a SpamAssassin rule that says that the
envelope sender is sending mail from a host that is not allowed.
whitelist_ms a.b.c.d/x configuration directives could be used to bypass
the rule.
Also, DNSBL could benefit from these records, as exceptions could be
generated for these records in the same manner that MX records generate
exceptions. I understand that any new type DNS record must be discussed,
and this is not the proper list to do it in, but this discussion is
probably appropiate since it's: OT.
-- Jorge Valdes
Re: OT: DNS restrictions for a mail server
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 21.10.08 14:37, Sebastian Ries wrote:
> I just want to know some opinions on the following DNS Setup for a mail
> server:
>
> # host -t MX example.com
> example.com mail is handled by 100 mail.example.com.
>
> # host mail.example.com
> mail.example.com is an alias for hostname.example.com.
INVALID - MX must not point to CNAME
> hostname.example.com has address 1.2.3.4
>
> # host 1.2.3.4
> 4.3.2.1.in-addr.arpa domain name pointer hostname.example.com.
> The mailserver (postfix) connects saying it is hostname.example.com.
correct.
> One partner we want to send mails to does BOUNCE mails with
> 554 5.7.1 DNS Blacklisted by in-addr.arpa (in reply to MAIL FROM
> command)
> Do you think this is correct?
not enough informative, but i'd say correct.
> I think this also prevents from getting mail from googlemail:
> sr@ben:~$ host -t MX googlemail.com
> googlemail.com mail is handled by 5 gmail-smtp-in.l.google.com.
> googlemail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.
> googlemail.com mail is handled by 10 alt2.gmail-smtp-in.l.google.com.
> googlemail.com mail is handled by 50 gsmtp147.google.com.
> googlemail.com mail is handled by 50 gsmtp183.google.com.
> sr@ben:~$ host gmail-smtp-in.l.google.com.
> gmail-smtp-in.l.google.com has address 209.85.129.27
> gmail-smtp-in.l.google.com has address 209.85.129.114
> sr@ben:~$ host 209.85.129.27
> 27.129.85.209.in-addr.arpa domain name pointer fk-in-f27.google.com.
Unless you are that big IDIOT that you check PTR on place you should not
check for, it's not the reason.
The point of MX is to point to hosts that receive mail, if you send mail to
someone.
The point of PTR is to provide host name when you receive mail from someone.
The PTR has NOTHING to do with MX records and vice versa!
Please stop this bullshit until it spreads. There are MANY hosts/domains
that have MX pointing to something different than PTR, and they all have no
problems.
I am ocasionally receiving this kind of "complaints" and the problem always
lies elsewhere, but some incompetent idiots search for problems where they
are not, and ignore them where they are.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Atheism is a non-prophet organization.
Re: OT: DNS restrictions for a mail server
Posted by Rubin Bennett <rb...@thatitguy.com>.
On Tue, 2008-10-21 at 14:46 +0200, Sebastian Ries wrote:
> Hi
>
> > One partner we want to send mails to does BOUNCE mails with
> > 554 5.7.1 DNS Blacklisted by in-addr.arpa (in reply to MAIL FROM
> > command)
> > Do you think this is correct?
>
> I talked to the admin of the mailserver and what he is doing is:
>
> host says it is hostname.example.com
> spamfilter checkes the MX for example.com
> spamfilter does not do any further checks
> spamfilter sees hostname.example.com != mail.example.com
> => BOUNCE
>
> :-/
>
In this situation, I either tell my server to masquerade as the MX for
outbound SMTP or I add a nigh numbered (i.e. low priority) MX record for
the outbound server (that way hostname.example.com shows up in the MX
record search results).
Rubin
Re: OT: DNS restrictions for a mail server
Posted by Sebastian Ries <Se...@dtnet.de>.
Hi
> One partner we want to send mails to does BOUNCE mails with
> 554 5.7.1 DNS Blacklisted by in-addr.arpa (in reply to MAIL FROM
> command)
> Do you think this is correct?
I talked to the admin of the mailserver and what he is doing is:
host says it is hostname.example.com
spamfilter checkes the MX for example.com
spamfilter does not do any further checks
spamfilter sees hostname.example.com != mail.example.com
=> BOUNCE
:-/
Regards
Sebastian Ries
--
------------------------------------------------------------
DT Netsolution GmbH - Talaeckerstr. 30 - D-70437 Stuttgart
Tel: +49-711-849910-36 Fax: +49-711-849910-936
WEB: http://www.dtnet.de/ email: Sebastian.Ries@dtnet.de
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
_________________________________________________________________________
bogusmx [Was: DNS restrictions for a mail server]
Posted by mouss <mo...@netoyen.net>.
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: OT: DNS restrictions for a mail server
Posted by Matt Kettler <mk...@verizon.net>.
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)
Re: OT: DNS restrictions for a mail server
Posted by Stefan Jakobs <st...@rus.uni-stuttgart.de>.
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
Re: OT: DNS restrictions for a mail server
Posted by Sebastian Ries <Se...@dtnet.de>.
Hi
> > I think this also prevents from getting mail from googlemail:
> > sr@ben:~$ host -t MX googlemail.com
> > googlemail.com mail is handled by 5 gmail-smtp-in.l.google.com.
> > googlemail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.
> > googlemail.com mail is handled by 10 alt2.gmail-smtp-in.l.google.com.
> > googlemail.com mail is handled by 50 gsmtp147.google.com.
> > googlemail.com mail is handled by 50 gsmtp183.google.com.
> > sr@ben:~$ host gmail-smtp-in.l.google.com.
> > gmail-smtp-in.l.google.com has address 209.85.129.27
> > gmail-smtp-in.l.google.com has address 209.85.129.114
> > sr@ben:~$ host 209.85.129.27
> > 27.129.85.209.in-addr.arpa domain name pointer fk-in-f27.google.com.
> >
> > Is this true?
> >
> Well, do you expect your "host" command is lying?
If my host command is lying I have other, bigger problems ;-)
I wanted to know if my assumption that he will not get any mails from
googlemail.com is right.
I took the direct way and triggered the change of the DNS record.
So now (in a view houres) the MX for example.com will be
hostname.example.com. so this should not cause any more problems.
Further opinion appreciated ;-)
Regards
Sebastian Ries
--
------------------------------------------------------------
DT Netsolution GmbH - Talaeckerstr. 30 - D-70437 Stuttgart
Tel: +49-711-849910-36 Fax: +49-711-849910-936
WEB: http://www.dtnet.de/ email: Sebastian.Ries@dtnet.de
Re: OT: DNS restrictions for a mail server
Posted by Matt Kettler <mk...@verizon.net>.
Sebastian Ries wrote:
> Hi there
>
> I just want to know some opinions on the following DNS Setup for a mail
> server:
>
> # host -t MX example.com
> example.com mail is handled by 100 mail.example.com.
>
> # host mail.example.com
> mail.example.com is an alias for hostname.example.com.
> hostname.example.com has address 1.2.3.4
>
> # host 1.2.3.4
> 4.3.2.1.in-addr.arpa domain name pointer hostname.example.com.
>
> The mailserver (postfix) connects saying it is hostname.example.com.
>
>
> Should this be a correct setup?
>
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.
reverse-lookup mismatch also happens a lot with non-cnames, particularly
when the hostname has multiple A record IP addresses associated. Often
those IPs won't all have the same PTR results, even though they all came
from the same A record.
> One partner we want to send mails to does BOUNCE mails with
> 554 5.7.1 DNS Blacklisted by in-addr.arpa (in reply to MAIL FROM
> command)
> Do you think this is correct?
>
Well, at that point you'd be looking at their smarthosts, not their
MXes, but it's pretty common there too.
(MX is their inbound mail servers, which for a large domain are very
rarely the same servers as the ones that send mail out)
> I think this also prevents from getting mail from googlemail:
> sr@ben:~$ host -t MX googlemail.com
> googlemail.com mail is handled by 5 gmail-smtp-in.l.google.com.
> googlemail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.
> googlemail.com mail is handled by 10 alt2.gmail-smtp-in.l.google.com.
> googlemail.com mail is handled by 50 gsmtp147.google.com.
> googlemail.com mail is handled by 50 gsmtp183.google.com.
> sr@ben:~$ host gmail-smtp-in.l.google.com.
> gmail-smtp-in.l.google.com has address 209.85.129.27
> gmail-smtp-in.l.google.com has address 209.85.129.114
> sr@ben:~$ host 209.85.129.27
> 27.129.85.209.in-addr.arpa domain name pointer fk-in-f27.google.com.
>
> Is this true?
>
Well, do you expect your "host" command is lying?
There are dozens of other large domains that do this. Here's another:
MX lookup for aol.com:
aol.com MX preference = 15, mail exchanger = mailin-04.mx.aol.com
aol.com MX preference = 15, mail exchanger = mailin-01.mx.aol.com
aol.com MX preference = 15, mail exchanger = mailin-02.mx.aol.com
aol.com MX preference = 15, mail exchanger = mailin-03.mx.aol.com
Looking up the A record of one of those:
Name: mailin-04.mx.aol.com
Addresses: 64.12.138.57, 205.188.159.216, 64.12.138.88
Reverse lookup of the IPS:
Address: 64.12.138.57
Name: md.mx.aol.com
Address: 205.188.159.216
Name: db.mx.aol.com
Address: 64.12.138.88
Name: me.mx.aol.com
> Regards
> Sebastian Ries
>
>
Re: OT: DNS restrictions for a mail server
Posted by mouss <mo...@netoyen.net>.
Sebastian Ries a écrit :
> Hi there
>
> I just want to know some opinions on the following DNS Setup for a mail
> server:
>
> # host -t MX example.com
> example.com mail is handled by 100 mail.example.com.
>
> # host mail.example.com
> mail.example.com is an alias for hostname.example.com.
wrong. an MX must not be a CNAME. your mail may be blocked because of this.
More generally, there is not much benefit from using a CNAME inside a
single zone (both alias and cname are in the same zone) because you can
use a script to convert the CNAME record to a "real" record. CNAME is
mostly useful when the alias points to a record in a remote zone (that
is not under your control).
> hostname.example.com has address 1.2.3.4
>
> # host 1.2.3.4
> 4.3.2.1.in-addr.arpa domain name pointer hostname.example.com.
>
> The mailserver (postfix) connects saying it is hostname.example.com.
>
>
> Should this be a correct setup?
>
for sending mail? yes.
> One partner we want to send mails to does BOUNCE mails with
> 554 5.7.1 DNS Blacklisted by in-addr.arpa (in reply to MAIL FROM
> command)
the error message is useless. Who is in-addr.arpa and why is he blocking
mail? :)
> Do you think this is correct?
>
> I think this also prevents from getting mail from googlemail:
if the reason is that the MX name differs from the "hostname", then he
wouldn't get mail from any large site (including all ISPs).
The MX is for receiving mail, not for sending mail. Sites who have the
resources use different systems for these two _different_ functions
(first, you don't want to block outbound mail if your MX is overloaded
or DOSed. second, the outbound mail server can be firewalled so that it
is only accessible from specific networks, ... etc).
> sr@ben:~$ host -t MX googlemail.com
> googlemail.com mail is handled by 5 gmail-smtp-in.l.google.com.
> googlemail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.
> googlemail.com mail is handled by 10 alt2.gmail-smtp-in.l.google.com.
> googlemail.com mail is handled by 50 gsmtp147.google.com.
> googlemail.com mail is handled by 50 gsmtp183.google.com.
> sr@ben:~$ host gmail-smtp-in.l.google.com.
> gmail-smtp-in.l.google.com has address 209.85.129.27
> gmail-smtp-in.l.google.com has address 209.85.129.114
> sr@ben:~$ host 209.85.129.27
> 27.129.85.209.in-addr.arpa domain name pointer fk-in-f27.google.com.
>
> Is this true?
>
> Regards
> Sebastian Ries
>