On Tue, Jun 26, 2012 at 3:58 PM, Alessandro Vesely <ves...@tana.it> wrote:
> On Tue 26/Jun/2012 13:14:34 +0200 Jan Ingvoldstad wrote:
> > On Tue, Jun 26, 2012 at 12:52 PM, Sam Varshavchik
> > <mr...@courier-mta.com <mailto:mr...@courier-mta.com>> wrote:
> >
> > There are no prescribed means for handling bad DNS data. If DNS is
> > wrong, one cannot have any expectation that it will work in any
> > particular way, even if some parts of it are correct.
> >
> > That's not quite correct, there are prescribed means for handling bad
> > DNS data in the context of Internet mail delivery.
>
> > http://tools.ietf.org/html/rfc5321#section-5
> >
> > To put it briefly: it would appear that the RFC authors think that the
> > good old "be tolerant in what you accept" principle still applies, and
> > it would not be unreasonable for an MTA to skip a broken MX record and
> > try the other record(s), if any.
>
> I'd be curious to know where would that tolerance be expressed in the
> section you refer. I'd guess because it says:
>
> If MX records are present, but
> none of them are usable, this situation MUST be reported as an error.
>
> Thus, since in the above case one of them seems to be usable, one can
> derive that it is not mandatory to report that as an error. However,
> the next paragraph says clearly what to expect:
>
> When a domain name associated with an MX RR is looked up and the
> associated data field obtained, the data field of that response MUST
> contain a domain name. That domain name, when queried, MUST return
> at least one address record (e.g., A or AAAA RR) that gives the IP
> address of the SMTP server to which the message should be directed.
> Any other response [...] lies outside the scope of this Standard.
>
You are clearly misreading the paragraph.
This is about the DNS lookup for the hostname in the MX RR.
That is, if you have an MX record:
@ MX 20 mymx.example
The paragraph you're citing, is about what to do when performing a DNS
lookup for the A or AAAA record for mymx.example.
The vagueness in RFC 2821, which has not been adressed in RFC 5321 AFAICT,
is that it does not prescribe what to do if there are two MX records, where
one is invalid and the other is not.
The reasonable interpretation is therefore that it would probably be
tolerant to check the _other_ MX record if the first turned out to be
invalid.
--
Jan
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
