Bug#403583: Re: Bug#403583: exim4: client TLS authentication is broken
tags #403583 - moreinfo unreproducible tags #403583 confirmed pending thanks On Thu, Jan 11, 2007 at 04:01:18PM +0100, Marc Haber wrote: > I'd like people to test this whether it introduces any regression > before I commit to svn and upload. No negative feedback until now. Committing to svn. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403583: exim4: client TLS authentication is broken
tags #403583 - moreinfo unreproducible
tags #403583 confirmed
thanks
On Fri, Jan 05, 2007 at 10:10:36AM +0100, Marc Haber wrote:
> On Fri, Jan 05, 2007 at 01:19:39AM -0500, celejar wrote:
> > On 1/3/07, Marc Haber <[EMAIL PROTECTED]> wrote:
> > >* is a catchall, I have verified this in a test setup with a smarthost
> > >that had its reverse DNS deliberatelybroken.
> > >
> > >You only need to put the IP address in passwd.client if you have
> > >specified a host name with broken reverse DNS there as the hostname
> > >will only be compared to the reverse DNS.
> >
> > Perhaps I'm missing something, but as I mentioned in my original
> > report, my passwd.client does have an '*' line and exim still often
> > fails to authenticate.
>
> That is not supposed to happen. The "*" line should work.
After debugging in private, we found out that google's smarthost
address changes so fast that the transport gets different IP addresses
when finding out the host to connect to and when resolving the name
again to find out whether to authenticate, and determines that it does
not need to authenticate.
Changing the hosts_try_auth clause of the remote_smtp_smarthost
transport to
hosts_try_auth = ${if exists{CONFDIR/passwd.client} \
{ ${lookup{$host}nwildlsearch{CONFDIR/passwd.client}{$host_address}} }\
{} \
}
seems to have solved the issue for the original poster and in my test
lab.
Thanks to Heiko Schlittermand for his help in figuring this out.
I'd like people to test this whether it introduces any regression
before I commit to svn and upload.
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403583: exim4: client TLS authentication is broken
On Fri, 5 Jan 2007 15:30:45 +0100 Marc Haber <[EMAIL PROTECTED]> wrote: [snip] > I am somewhat "at the end of my latin" here, since I cannot reproduce > the bug. If you are on Debian etch or Debian sid (which your original > bug report suggested), please try purging exim (you'll probably need > --force-depends for that), rm -rf /etc/exim4, and reinstalling a > current exim4 package (smarthost handling has changed in 4.63-5, and I > have been testing with a current version). You seem to have your > configuration changed in some places, and I'd like to get you "back on > track" before debugging any further. Ok, I now have a totally fresh install and config of exim4 - here's 'dpkg -s exim4*': > ii exim4 4.63-13 metapackage to ease exim MTA (v4) > installation > ii exim4-base 4.63-13 support files for all exim MTA > (v4) packages > ii exim4-config4.63-13 configuration for the exim MTA > (v4) > un exim4-config-2(no description available) > un exim4-daemon-custom (no description available) > un exim4-daemon-heavy(no description available) > ii exim4-daemon-light 4.63-13 lightweight exim MTA (v4) daemon > ii exim4-doc-html 4.63-1 documentation for the Exim MTA > (v4) in html format > un exim4-doc-info(no description available) I also purged and rebuilt the config files, including passwd.client. I'll report back any problems or apparent lack thereof. > > Greetings > Marc Thanks, Celejar -- ssuds.sourceforge.net - Home of Ssuds and Ssudg, a Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403583: exim4: client TLS authentication is broken
On Fri, Jan 05, 2007 at 09:05:09AM -0500, Celejar wrote:
> On Fri, 5 Jan 2007 10:10:36 +0100
> Marc Haber <[EMAIL PROTECTED]> wrote:
> > (a)
> > verify that your passwd.client line is formatted like:
> > *:username:clear-text-password
> >
>
> The debugging output I sent was made with the passwd.client file I gave
> in my original report, which I believe has the '*' line correctly
> formatted.
yes, that looks good.
> > (b)
> > show me the output of:
> > exim4 -bP transport remote_smtp_smarthost | grep hosts_try_auth
>
> hosts_try_auth = ${if exists {/etc/exim4/passwd.client}{smtp.gmail.com}
> {}}
That looks good as well. However, your exim does think that the server
you're connected to is not listed in hosts_try_auth:
|64.233.185.109 in hosts_require_auth? no (option unset)
|gethostbyname2(af=inet6) returned 3 (NO_RECOVERY)
|gethostbyname2 looked up these IP addresses:
| name=gmail-smtp.l.google.com address=72.14.247.109
|64.233.185.109 in hosts_try_auth? no (end of list)
| SMTP>> MAIL FROM:<> SIZE=51400
My reference system, when configured to deliver through smtp.gmail.com
via my gmail account:
66.249.93.111 in hosts_require_auth? no (option unset)
gethostbyname2(af=inet6) returned 3 (NO_RECOVERY)
gethostbyname2 looked up these IP addresses:
name=gmail-smtp.l.google.com address=66.249.93.111
name=gmail-smtp.l.google.com address=66.249.93.109
66.249.93.111 in hosts_try_auth? yes (matched "smtp.gmail.com")
and then proceeds to authenticate.
I am somewhat "at the end of my latin" here, since I cannot reproduce
the bug. If you are on Debian etch or Debian sid (which your original
bug report suggested), please try purging exim (you'll probably need
--force-depends for that), rm -rf /etc/exim4, and reinstalling a
current exim4 package (smarthost handling has changed in 4.63-5, and I
have been testing with a current version). You seem to have your
configuration changed in some places, and I'd like to get you "back on
track" before debugging any further.
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403583: exim4: client TLS authentication is broken
On Fri, 5 Jan 2007 10:10:36 +0100
Marc Haber <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 05, 2007 at 01:19:39AM -0500, celejar wrote:
> > On 1/3/07, Marc Haber <[EMAIL PROTECTED]> wrote:
> > >* is a catchall, I have verified this in a test setup with a smarthost
> > >that had its reverse DNS deliberatelybroken.
> > >
> > >You only need to put the IP address in passwd.client if you have
> > >specified a host name with broken reverse DNS there as the hostname
> > >will only be compared to the reverse DNS.
> >
> > Perhaps I'm missing something, but as I mentioned in my original
> > report, my passwd.client does have an '*' line and exim still often
> > fails to authenticate.
>
> That is not supposed to happen. The "*" line should work.
>
> Can I see debugging output of a failed delivery attempt? If the
> debugging output you recently sent was already made with a "*" in
> passwd.client, please
>
> (a)
> verify that your passwd.client line is formatted like:
> *:username:clear-text-password
>
The debugging output I sent was made with the passwd.client file I gave
in my original report, which I believe has the '*' line correctly
formatted.
> (b)
> show me the output of:
> exim4 -bP transport remote_smtp_smarthost | grep hosts_try_auth
hosts_try_auth = ${if exists {/etc/exim4/passwd.client}{smtp.gmail.com}
{}}
> and (long line!)
> exim4 -be "$(exim4 -bP transport remote_smtp_smarthost | grep hosts_try_auth
> | awk '{print $2}' FS="=")"
smtp.gmail.com
>
> (both lines need to be executed as root).
>
> Greetings
> Marc
Thanks,
Celejar
--
ssuds.sourceforge.net - Home of Ssuds and Ssudg, a Simple Sudoku Solver
and Generator
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403583: exim4: client TLS authentication is broken
On Fri, Jan 05, 2007 at 01:19:39AM -0500, celejar wrote:
> On 1/3/07, Marc Haber <[EMAIL PROTECTED]> wrote:
> >* is a catchall, I have verified this in a test setup with a smarthost
> >that had its reverse DNS deliberatelybroken.
> >
> >You only need to put the IP address in passwd.client if you have
> >specified a host name with broken reverse DNS there as the hostname
> >will only be compared to the reverse DNS.
>
> Perhaps I'm missing something, but as I mentioned in my original
> report, my passwd.client does have an '*' line and exim still often
> fails to authenticate.
That is not supposed to happen. The "*" line should work.
Can I see debugging output of a failed delivery attempt? If the
debugging output you recently sent was already made with a "*" in
passwd.client, please
(a)
verify that your passwd.client line is formatted like:
*:username:clear-text-password
(b)
show me the output of:
exim4 -bP transport remote_smtp_smarthost | grep hosts_try_auth
and (long line!)
exim4 -be "$(exim4 -bP transport remote_smtp_smarthost | grep hosts_try_auth |
awk '{print $2}' FS="=")"
(both lines need to be executed as root).
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403583: exim4: client TLS authentication is broken
On 1/3/07, Marc Haber <[EMAIL PROTECTED]> wrote: [snip] * is a catchall, I have verified this in a test setup with a smarthost that had its reverse DNS deliberatelybroken. You only need to put the IP address in passwd.client if you have specified a host name with broken reverse DNS there as the hostname will only be compared to the reverse DNS. Perhaps I'm missing something, but as I mentioned in my original report, my passwd.client does have an '*' line and exim still often fails to authenticate. [snip] Greetings Marc Thnaks, Celejar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403583: exim4: client TLS authentication is broken
On Sun, Dec 24, 2006 at 09:17:49AM -0500, Celejar wrote: > Thanks very much for clearing this up. The documentation > [exim4-config_files(5)] currently reads: > > > server with the canonical host name target.mail.server.example. Many > > ISPs provide only an alias name of their SMTP smarthost. You need to > > check the canonical name by yourself manu- ally by querying the DNS, > > for example by using the host command. If the SMTP smarthost alias > > expands to multiple IPs, you probably need to have multiple lines or a > > wild card in the target.mail.server.example field, and when your ISP > > changes the alias, you will need to manually fix that. This is > > currently not possibly any better, see #244724. A host name value of * > > will divulge the password to any SMTP server asking for it. This is > > generally fine if you only have one SMTP server configured. > > This clearly states that a line beginning with '*' is a catchall; this > needs to be modified to warn about the foregoing exception, that exim > won't authenticate if reverse dns fails unless the smarthost's IP > address(es) is (are) explicitly given in passwd.client. * is a catchall, I have verified this in a test setup with a smarthost that had its reverse DNS deliberatelybroken. You only need to put the IP address in passwd.client if you have specified a host name with broken reverse DNS there as the hostname will only be compared to the reverse DNS. The manpage in question now reads: Please note that target.mail.server.example is currently the value that exim can read from reverse DNS: It first follows the host name of the target system until it finds and IP address, and then looks up the reverse DNS for that IP address to use the outcome of this query (or the IP address itself should the query fail) as index into /etc/exim4/passwd.client. This goes inevitably wrong if the host name of the mail server is a CNAME (a DNS alias), or the reverse lookup does not fit the forward one. Currently, you need to manually lookup all reverse DNS names for all IP addresses that your SMTP server host name points to, for example by using the host command. If the SMTP smarthost alias expands to multi- ple IPs, you need to have multiple lines for all the hosts. When your ISP changes the alias, you will need to manually fix that. You may minimize this trouble by using a wild card entry or regular expressions, thus reducing the risk of divulging the password to the wrong SMTP server while reducing the number of necessary lines. For a deeper discussion, see the Debian BTS #244724. I hope this is more clear. If not, please suggest a different wording. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403583: exim4: client TLS authentication is broken
On Sun, 24 Dec 2006 12:14:59 +0100 Marc Haber <[EMAIL PROTECTED]> wrote: > On Sat, Dec 23, 2006 at 11:41:05PM -0500, Celejar wrote: > > gmail-smtp.l.google.com [64.233.185.109]:587 status = usable > > 64.233.185.109 in serialize_hosts? no (option unset) > > delivering 1GyKob-n7-56 to gmail-smtp.l.google.com [64.233.185.109] > > ([EMAIL PROTECTED]) > > set_process_info: 3052 delivering 1GyKob-n7-56 to > > gmail-smtp.l.google.com [64.233.185.109] ([EMAIL PROTECTED]) > > Connecting to gmail-smtp.l.google.com [64.233.185.109]:587 ... connected > > We are connected to gmail-smtp.l.google.com, 64.233.185.109. > > > 64.233.185.109 in hosts_require_auth? no (option unset) > > gethostbyname2(af=inet6) returned 3 (NO_RECOVERY) > > gethostbyname2 looked up these IP addresses: > > name=gmail-smtp.l.google.com address=72.14.247.109 > > 64.233.185.109 in hosts_try_auth? no (end of list) > > 64.233.185.109 has no reverse DNS, Goof on Google's side. exim thus > looks up the IP address in the passwd.client file, and since it does > not find an entry, it does not try to authenticate. > > This is a new variant of the #244724 issue mentioned in > exim4-config_files(5). > > You need to have the IP addresses of the google smtp servers in your > passwd.client as well. > > Greetings > Marc Thanks very much for clearing this up. The documentation [exim4-config_files(5)] currently reads: > server with the canonical host name target.mail.server.example. Many ISPs > provide only an >alias name of their SMTP smarthost. You need to check the canonical > name by yourself manu- >ally by querying the DNS, for example by using the host command. If > the SMTP smarthost >alias expands to multiple IPs, you probably need to have multiple > lines or a wild card in >the target.mail.server.example field, and when your ISP changes the > alias, you will need >to manually fix that. This is currently not possibly any better, see > #244724. A host name >value of * will divulge the password to any SMTP server asking for it. > This is generally >fine if you only have one SMTP server configured. This clearly states that a line beginning with '*' is a catchall; this needs to be modified to warn about the foregoing exception, that exim won't authenticate if reverse dns fails unless the smarthost's IP address(es) is (are) explicitly given in passwd.client. Celejar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403583: exim4: client TLS authentication is broken
tags #403583 unreproducible moreinfo thanks On Mon, Dec 18, 2006 at 04:07:17AM -0500, Celejar wrote: > Exim is set to relay outgoing mail through a smarthost (smtp.gmail.com > a.k.a gmail-smtp.l.google.com) which requires the client to authenticate > via TLS. Exim is configured to do so, and /etc/exim4/passwd.client > contains the following lines: > > > *:[EMAIL PROTECTED]:my_password > > gmail-smtp.l.google.com:[EMAIL PROTECTED]:my_password > > smtp.gmail.com:[EMAIL PROTECTED]:my_password That looks correctl > Sending mail is often succesful, but it often fails with the > following log message: > > > -xx-xx xx:xx:xx xx ** [EMAIL PROTECTED] R=smarthost > > T=remote_smtp_smarthost: SMTP error from remote mail server after MAIL > > FROM:<> SIZE=: host gmail-smtp.l.google.com [64.233.185.111]: 530 > > 5.5.1 Authentication Required xx Are there any log entries for that message before (grep for the message_ID)? Is it possible to see debug output (obtained from exim4 -d -M for a message on queue or from piping the message into exim4 -d [EMAIL PROTECTED]) for a failed delivery attempt? Please send them to me in private e-mail as they might contain sensitive information such as passwords and try to sanitize the output of visible passwords. Be prepared to change your password after testing. > This problem is discussed at some length on the (regular, non-Debian) exim > mailing list [0], but I see no resolution there. Yes, the original bug reporter was not very helpful as he just repeated having no clue and not following any advice that was given. The original bug reporter finally posted log entries saying that the remote server was complaining about wrong credentials and stopped answering questions soon later. This is the reason for me asking you for more log entries for failing messages, just to find out whether you might have the same problem. > The information on the "GmailandExim4" page of the Debian wiki [1] also > does not help to resolve the problem. That information in the Debian wiki is not endorsed by the Debian exim4 maintainer, contains outdated and inaccurate information. Please refer to the original Debian exim4 docs that come with your package or to the wiki pages beginning with PkgExim4. For example, you're running an exim4 package that is reasonably current and do not need to modify your configuration any more to point exim towards port 587. See the update-exim4.conf.conf man page for more detailed information. In the mean time, I'll tag this bug as "unreproducible moreinfo". Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403583: exim4: client TLS authentication is broken
Package: exim4 Version: 4.63-2 Severity: normal *** Please type your report below this line *** Exim is set to relay outgoing mail through a smarthost (smtp.gmail.com a.k.a gmail-smtp.l.google.com) which requires the client to authenticate via TLS. Exim is configured to do so, and /etc/exim4/passwd.client contains the following lines: > *:[EMAIL PROTECTED]:my_password > gmail-smtp.l.google.com:[EMAIL PROTECTED]:my_password > smtp.gmail.com:[EMAIL PROTECTED]:my_password Sending mail is often succesful, but it often fails with the following log message: > -xx-xx xx:xx:xx xx ** [EMAIL PROTECTED] R=smarthost > T=remote_smtp_smarthost: SMTP error from remote mail server after MAIL > FROM:<> SIZE=: host gmail-smtp.l.google.com [64.233.185.111]: 530 > 5.5.1 Authentication Required xx Other MTAs on the system (Sylpheed, swaks and others) are consistently successful at relaying mail through the same smarthost. This problem is discussed at some length on the (regular, non-Debian) exim mailing list [0], but I see no resolution there. The information on the "GmailandExim4" page of the Debian wiki [1] also does not help to resolve the problem. [0] http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20061023/msg00323.html [1] http://wiki.debian.org/GmailAndExim4 Package-specific info: Exim version 4.63 #1 built 15-Aug-2006 20:40:36 Copyright (c) University of Cambridge 2006 Berkeley DB: Sleepycat Software: Berkeley DB 4.3.29: (September 6, 2005) Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dsearch nis nis0 passwd Authenticators: cram_md5 plaintext Routers: accept dnslookup ipliteral manualroute queryprogram redirect Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp Fixed never_users: 0 Size of off_t: 8 Configuration file is /var/lib/exim4/config.autogenerated # /etc/exim4/update-exim4.conf.conf # # Edit this file and /etc/mailname by hand and execute update-exim4.conf # yourself or use 'dpkg-reconfigure exim4-config' # # Please note that this is _not_ a dpkg-conffile and that automatic changes # to this file might happen. The code handling this will honor your local # changes, so this is usually fine, but will break local schemes that mess # around with multiple versions of the file. # # update-exim4.conf uses this file to determine variable values to replace # the DEBCONFsomethingDEBCONF strings in the configuration template files. # # Most settings found in here do have corresponding questions in the # Debconf configuration, but not all of them. # # This is a Debian specific file dc_eximconfig_configtype='smarthost' dc_other_hostnames='localhost.localdomain' dc_local_interfaces='127.0.0.1' dc_readhost='' dc_relay_domains='' dc_minimaldns='false' dc_relay_nets='' dc_smarthost='smtp.gmail.com' CFILEMODE='644' dc_use_split_config='true' dc_hide_mailname='false' dc_mailname_in_oh='true' mailname:localhost.localdomain -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i586) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-2-386 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages exim4 depends on: ii exim4-base4.63-2 support files for all exim MTA (v4 ii exim4-daemon-light4.63-2 lightweight exim MTA (v4) daemon exim4 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
