Hmmm.. The whilst your comments are correct there are a lot of broken
mail systems submitting mail like this. Many of them, as in this case,
are very old and not suited to being changed! This one is running an
ancient version of sendmail (a very good reason for putting it behind
exim) and I think there is a wider need to cope with situations like
this.
If nothing else the differing behaviour of exim -bt and the SMTP
dialogue needs addressing as this is confusing.
What is actually needed is for qualify_singe to be applied to
connections from some addresses only (i.e. local ones).
> -----Original Message-----
> From: Philip Hazel [mailto:ph10@hermes.cam.ac.uk]
> Sent: 02 February 2007 15:08
> To: exim-users@???
> Cc: Robert Bannocks
> Subject: Re: [exim] Problems arroung qualify_singe after exim 4.52
(and so
> with 4.66)
>
> 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.
