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:[EMAIL PROTECTED] > Sent: 02 February 2007 15:08 > To: [email protected] > 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:<[EMAIL PROTECTED]> > 11:02:19 22735 SMTP>> 250 OK > 11:02:31 22735 SMTP<< rcpt to:<[EMAIL PROTECTED]> > > 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 [EMAIL PROTECTED] 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:<[EMAIL PROTECTED]> > > 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 [EMAIL PROTECTED] > 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. -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
