Re: [exim] 454 Error

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: Viktor Dukhovni
Data:  
Para: exim-users
Assunto: Re: [exim] 454 Error
On Wed, Jul 27, 2016 at 01:53:48PM -0400, John C Klensin wrote:

> Please be careful when you interpret 2821 or 5321 as prohibiting
> / deprecating some action.


Of course, but this forum is perhaps not one where we need to be
quite as careful as we might need to be in an RFC or IETF WG
discussion. In the end it seems that at least for a length 1 CNAME
chain, we are in violent agreement:

> Now, the text you quote from 2821 (and the slight more detailed
> but essentially equivalent text in Section 2.3.5 of RFC 5321)
> fairly explicitly say that
>
>    foo.example.net. CNAME  bar.example.net.
>    bar.example.net. MX 0 smtp1.example.com.

>
> and hence an address of user@??? is valid.  The
> intent, which I hope is clear, is that the RCPT command
> transmitted to smtp1.example.com have <user@???> as
> its [primary] parameter and not anything involving "bar".  That
> is important because it is SMTP-valid to treat the putative
> mailbox user@??? as different from
> user@???.  If there were an additional DNS record
>    fuzz.example.net. CNAME bar.example.net.
> mail to user@??? could legitimately be given yet
> different treatment.


This confirms what I understand to be the essential thrust of the
relevant changes in 2821 and 5321. Specifically, it is now unwise
to rewrite the domains in SMTP email addresses when CNAME indirection
is encountered.

> However, when the name chain is rather more like
>
> foo.example.net. CNAME bong.example.net.
> bong.example.net. CNAME bar.example.net.
> bar.example.net. MX 0 smtp1.example.com.


Indeed that rather risks interoperability issues.

> Combine that with the unfortunate relationship between CNAME
> records and DNSSEC, and the best practice advice is to avoid
> them if possible.


Can you elaborate on this "unfortunate relationship"? CNAME RRs
get RRSIGs mostly just like any other RRset, except for the
indirection when the CNAME is dynamically inferred from a signed
DNAME. When a validating iterative resolver returns an answer that
involves one or more CNAME expansions, the AD bit in the reply is
only set when *all* the answers (CNAMEs and actual answer RRsets)
are validated.

I am not aware of what makes the situation an unfortunate one. An
off-list response is fine, if you think this takes us too far
off-topic for this forum. However, better understanding of DNSSEC
is probably of some value to email administrators.

-- 
    Viktor.