spam filter and MX records
Mark_Andrews at isc.org
Wed Feb 1 05:30:09 UTC 2006
> On 31 Jan 2006, at 19:27 PST, Mark Andrews wrote:
> >> On 31 Jan 2006, at 15:20 PST, barber.greg at gmail.com wrote:
> >>> Well it's kind of a strange setup the mailer and the webmail
> >>> interface
> >>> all reside on machine. Prior to the filter being put in place no MX
> >>> existed for this machine it was only an A record set to the email
> >>> domain so instead of being mail.xyz.123.edu or mx.xyz.123.edu it's A
> >>> record was just xyz.123.edu. I thought in a situtation like this the
> >>> change would be warranted in case the filters went offline foreign
> >>> mailers would sense that xyz.123.edu was down and requeue the
> >>> message
> >>> instead of delivering straight to xyz.123.edu via the A record.
> >> I presume from your comments that xyz.123.edu is a subdomain of the
> >> parent 123.edu domain and that an A record had been defined to allow
> >> mail to be sent to "user.mailbox at xyz.123.edu". Further the A record
> >> that is associated with the domain name contains the IP address of
> >> the mail server.
> >> For robustness, the strategy employed by sendmail and Exchange's IMS
> >> is to query DNS for any record associated with xyz.123.edu. The DNS
> >> response will contain A, MX, NS, and any other associated record.
> >> If an MX record exists, sendmail and IMS will prefer to use this to
> >> deliver mail and will select the MX record with the lowest preference
> >> value. If the system with the lowest preference value is not
> >> reachable, they will attempt to deliver mail using an MX record with
> >> a higher preference value. If all of the systems identified in MX
> >> records are unreachable and there is an A record for the resource,
> >> they will attempt to deliver the mail using the A record.
> > Any MTA that falls back to A / AAAA records when MX records
> > are present is BROKEN.
> > A MTA is only supposed to fallback to a A / AAAA record when
> > there are *no* MX records.
> Yes, RFC 2821 does make the statement that if there are any MX
> records present the A record is to be ignored.
As did RFC 974 which was issued 20 years ago now.
> There are also broken mail systems. They will deliver mail to the A
> record. If you don't want that to happen, observe the "prudent man"
> principle. Provide an A record to the system that you want them to
> use for relaying mail.
Well if you still want to try to support pre-MX aware MTAs
20 years after the introduction of MX records. These days
the only real world SMTP engines that ignore MX records are
> >> If you want all your mail relayed through a defined mail exchange
> >> system and never directly, you need to specify on one of your MX
> >> records a preference value of 0. This informs sendmail and IMS that
> >> you will only accept mail relayed through this system.
> > 0 is not a special value.
> See RFC 2821 regarding the implicit MX record. If there is only an A
> record, it is to be treated as if it were an MX record with a
> preference of 0. This seems somewhat special to me.
No that does not make zero special. The zero could be replaced
with any value. It was just simpler to state a value rather
than having people ask "What preference should we use?".
> >> Most of the mail systems that don't understand MX records have been
> >> retired. There are a few still out there. To address this type of
> >> system, I would set the subdomain's A record to the address of your
> >> preferred or only mail exchange system: in your case, the mail
> >> filter system.
> >> As you can see, a part of the problem is understanding how systems
> >> make use of the information in DNS.
> >> Merton Campbell Crockett
> >> m.c.crockett at adelphia.net
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
> Merton Campbell Crockett
> m.c.crockett at adelphia.net
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the bind-users