On Fri, 2 Feb 2007, I wrote:
> Please can you post (or send to me) the full debugging output in both
> cases.
Robert did send me that data, offlist. I now know what the answer is, so
I'm replying onlist so that it gets into the archives.
The problem is that an unqualified domain was being used for a sender
address, as in:
11:02:19 22735 SMTP<< mail from:<root@earthsci>
11:02:19 22735 SMTP>> 250 OK
11:02:31 22735 SMTP<< rcpt to:<r.bannocks@nhm>
Now, unqualified domains have always been a troublesome PITA; I
personally do not recommend their use. IIRC, the RFCs always talk in
terms of FQDNs. However, some sites do try to use abbreviations. (In UK
academia, where this question originates, there was a culture of using
them in pre-Internet days, when the centralized registration system did
not allow name clashes so there could be no ambiguity. Some of this
culture still persists, I fear.)
In Exim 4.52, verification of the sender root@earthsci worked because
the DNS lookup on the server was allowed to expand it to
earthsci.nhm.ac.uk. This action was deliberately turned off in Exim
4.53. The relevant ChangeLog entries are:
PH/43 (Again a TF fix): In the dnslookup router, do not apply widen_domains
when verifying a sender address, unless rewrite_headers is false.
TF/05 The fix for PH/43 was not completely correct; widen_domains is always
OK for addresses that are the result of redirections.
TF/06 The fix for widen_domains has also been applied to qualify_single and
search_parents which are the other dnslookup options that can cause
header rewrites.
The reason for preventing the widening of unqualified names in sender
addresses is to prevent completely inappropriate address rewriting. For
example: Suppose the client host is client.one.tld and the server host,
totally unrelated, is server.two.tld. If the client sends
MAIL FROM:<x@rhubarb>
and the server tries to verify it with DNS qualification turned on, it
will work if rhubarb.two.tld exists - and rewrite the From: header to
contain that address. But this is totally inappropriate because the
sender address should be in the client's domain, not in the server's
domain. Note in particular that a bounce would go to x@???
and not back to the client - there might be scope for abuse here.
As the ChangeLog entry suggests, if you set rewrite_headers false it
will allow this widening, but it still wouldn't be appropriate, and the
message itself would end up with an unqualified domain in the From:
field.
I fear that the only solution here is to educate your users and/or to
change appropriate configurations so that they use fully qualified
domain names in sender addresses.
Philip
--
Philip Hazel, University of Cambridge Computing Service.
