Re: [exim-dev] Unexpected RFC 1123 address canonicalization

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Phil Pennock
Fecha:  
A: Florian Weimer
Cc: exim-dev
Asunto: Re: [exim-dev] Unexpected RFC 1123 address canonicalization
On 2012-06-24 at 19:37 +0200, Florian Weimer wrote:
> This one is really confusing.
>
> The documentation says:
>
> | One situation in which Exim does not automatically rewrite a domain is when it
> | is the name of a CNAME record in the DNS. The older RFCs suggest that such a
> | domain should be rewritten using the "canonical" name, and some MTAs do this.
> | The new RFCs do not contain this suggestion.


My understanding is that this refers to the RFC822/2822/5322 headers,
such as "To:", "Cc:" and friends: long ago, I recall that if you mailed to
<foo@???> but bar.example.net existed in DNS as a CNAME to
wibble.example.com, then the addresses in those headers would be
rewritten to be <foo@???>.

My analysis of the next bit is my assumption without going and looking
at the code in context, because I really need to be asleep right now.

> | if (Ustrcmp(addr->domain, fully_qualified_name) != 0)
> | {


Domain name found from DNS != domain we look up

> |   if (strcmpic(addr->domain, fully_qualified_name) == 0)
> |     {
> |     uschar *at = Ustrrchr(addr->address, '@');
> |     memcpy(at+1, fully_qualified_name, Ustrlen(at+1));


Lower-case and continue as though unchanged.

> |     }
> |   else
> |     {
> |     rf_change_domain(addr, fully_qualified_name, ob->rewrite_headers, addr_new);
> |     return REROUTED;
> |     }
> |   }


Lookup routing for the new domain, instead of just chasing DNS; obey
rewrite_headers from the Router. So, instead of chasing DNS further,
go through the Routers from the top, handling the new domain. Which is
interesting.

>
> A test says:
>
> fw@x-1:~$ /usr/sbin/exim4 -bt mailman@???
> mailman@???
>     <-- mailman@???
>   router = dnslookup, transport = remote_smtp_ext
>   host ss.vix.com [2001:559:8000:cb::2] 
>   host ss.vix.com [24.104.150.2]        
> fw@x-1:~$ 


That tests the SMTP Envelope address, not the message headers.

> 19:32:30 22717 domain changed to ss.vix.com
> 19:32:30 22717 rewriting header lines


That's because the dnslookup Router's default value for rewrite_headers
is True.

----------------------------8< cut here >8------------------------------
+---------------+--------------+-------------+-------------+
|rewrite_headers|Use: dnslookup|Type: boolean|Default: true|
+---------------+--------------+-------------+-------------+

If the domain name in the address that is being processed is not fully
qualified, it may be expanded to its full form by a DNS lookup. For example, if
an address is specified as dormouse@teaparty, the domain might be expanded to
teaparty.wonderland.fict.example. Domain expansion can also occur as a result
of setting the widen_domains option. If rewrite_headers is true, all
occurrences of the abbreviated domain name in any Bcc:, Cc:, From:, Reply-to:,
Sender:, and To: header lines of the message are rewritten with the full domain
name.

This option should be turned off only when it is known that no message is ever
going to be sent outside an environment where the abbreviation makes sense.

When an MX record is looked up in the DNS and matches a wildcard record, name
servers normally return a record containing the name that has been looked up,
making it impossible to detect whether a wildcard was present or not. However,
some name servers have recently been seen to return the wildcard entry. If the
name returned by a DNS lookup begins with an asterisk, it is not used for
header rewriting.
----------------------------8< cut here >8------------------------------

> The configuration has no rewrite rules and no funky routers.


Hrm; I take it that mailman on the host does not know of its name after
CNAME chasing and is rejecting the messages?

-Phil