- Package:
- exim4-config
- Source:
- exim4
- Submitter:
- Andre Heynatz
- Date:
- 2017-10-19 10:51:02 UTC
- Severity:
- normal
I tried to configure exim4 for my ISP's mail account, 1&1. The hostname given by 1&1: auth.mail.onlinehome.de I created a passwd.client file with the following content: auth.mail.onlinehome.de:myusername:mypassword and changed other settings as described in /usr/share/doc/exim4-base/README.SMTP-AUTH. It does not work, the Exim4 log file tells the following: me@onlinehome.de R=smarthost T=remote_smtp: SMTP error from remote mailer after MAIL FROM:<> SIZE=2357: host authmailonline.kundenserver.de [212.227.15.180]: 530 Authentication required After debugging the SMTP session, I found out that exim4 does not use the dc_smarthost value 'auth.mail.onlinehome.de' as lookup key for /etc/exim4/passwd.client, instead it does a DNS lookup: $ host auth.mail.onlinehome.de auth.mail.onlinehome.de is an alias for authmailonline.kundenserver.de. authmailonline.kundenserver.de has address 212.227.15.180 authmailonline.kundenserver.de has address 212.227.15.132 authmailonline.kundenserver.de has address 212.227.15.148 authmailonline.kundenserver.de has address 212.227.15.164 $ dig auth.mail.onlinehome.de ... ;; ANSWER SECTION: auth.mail.onlinehome.de. 1675 IN CNAME authmailonline.kundenserver.de. authmailonline.kundenserver.de. 808 IN A 212.227.15.164 authmailonline.kundenserver.de. 808 IN A 212.227.15.180 authmailonline.kundenserver.de. 808 IN A 212.227.15.132 authmailonline.kundenserver.de. 808 IN A 212.227.15.148 ... authmailonline.kundenserver.de is used as the key, and this key is not found. So the authentication fails, and the mail is frozen. In config files, the original hostname should be used for lookup. I do not know in which way exim4 does react if the ISP changes the DNS alias which they are free to do.
On 2004-04-19 Andre Heynatz <vetasana@gmx.de> wrote:
[...]
[...]
[...]
Thank you for the report and the analysis.
[...]
"original hostname" is not well defined. ;-) Currently I cannot see a
soltuition for this problem besides documenting it and suggesting to
use
*:myusername:mypassword
if only one smarthost is involved.
cu andreas
I have debugged the SMTP session with
# exim4 >/tmp/debug 2>&1 -d+all me@onlinehome.de <<!
> testmail
> !
Strangely, both names (auth.mail.onlinehome.de,
authmailonline.kundenserver.de) are looked up somewhere:
21:13:55 3780 expanding: ${if exists
{/etc/exim4/passwd.client}{auth.mail.onlinehome.de}{}}
21:13:55 3780 result: auth.mail.onlinehome.de
21:14:00 3780 gethostbyname2 looked up these IP addresses:
21:14:00 3780 name=authmailonline.kundenserver.de address=212.227.15.132
21:14:00 3780 name=authmailonline.kundenserver.de address=212.227.15.148
21:14:00 3780 name=authmailonline.kundenserver.de address=212.227.15.164
21:14:00 3780 name=authmailonline.kundenserver.de address=212.227.15.180
21:14:00 3780 212.227.15.148 in hosts_try_auth? yes (matched
"auth.mail.onlinehome.de")
21:14:00 3780 expanding: /etc/exim4/passwd.client
21:14:00 3780 result: /etc/exim4/passwd.client
21:14:00 3780 search_open: lsearch "/etc/exim4/passwd.client"
21:14:00 3780 search_find: file="/etc/exim4/passwd.client"
21:14:00 3780 key="authmailonline.kundenserver.de" partial=-1 affix=NULL
starflags=1
21:14:00 3780 LRU list:
21:14:00 3780 9/etc/exim4/passwd.client
21:14:00 3780 End
21:14:00 3780 internal_search_find: file="/etc/exim4/passwd.client"
21:14:00 3780 type=lsearch key="authmailonline.kundenserver.de"
21:14:00 3780 file lookup required for authmailonline.kundenserver.de
21:14:00 3780 in /etc/exim4/passwd.client
21:14:00 3780 expanding: ${if
!eq{$tls_cipher}{}{^${extract{1}{:}{${lookup{$host}lsearch*{/etc/exim4/passwd.client}{$value}fail}}}^${extract{2}{:}{${lookup{$host}lsearch*{/etc/exim4/passwd.client}{$value}fail}}}}fail}
21:14:00 3780 result: ^myuser^mypassword
I have configured the DNS alias name in passwd.client, but exim4 still knows
the hostname given by me (via debconf). I wonder if it is possible to use
$DCsmarthost instead of $host, so that exim4 can use the key given in dc_smarthost.
The solution *:myusername:mypassword is good enough for a single user and for a
typical home configuration. For multiple users with different smarthosts, the
DNS aliasing problem remains.
| hosts_try_auth = ${if exists {CONFDIR/passwd.client}{DCsmarthost}{}}
DCsmarthost is "auth.mail.onlinehome.de" on your system.
[...]
[...]
And that is one ofthe authenticators, using:
${lookup{$host}lsearch*{CONFDIR/passwd.client}...
Yes, it is possible to replace "$host" with DCsmarthost in the
authenticator but ...
... it would only work for single smarthost setups.
cu andreas
Andreas Metzler wrote: For multiple users perhaps it would help to expand /etc/exim4/passwd.client or use another config file with the following content: user:smarthost:smarthostuser:smarthostpassword For all users the option hosts_try_auth could be set, so that this does not need to be configured.
Hi, this is Debian issue #244724, which I currently consider a request for clarification.----- Forwarded message from Andre Heynatz <vetasana@gmx.de> ---------- End forwarded message ----- Looks like exim does a double reverse lookup on the target host name, and then uses the name obtained from that reverse lookup to obtain user name and password to authenticate with. I do actually find this unproductive in today's world where service providers frequently have service CNAMEs pointing to different machines to be able to re-route client requests for maintenance and repair. With exim doing that double reverse lookup, an ISP re-pointing its service CNAMEs will probably break exim clients authenticating. Is there a reason that exim does it this way that I have missed? Greetings Marc
Marc wrote: ... Using what configuration file? Exim does not do outbound SMTP authentication when sending messages with its default configuration. This "bug" looks like it is *entirely* a bug with the users configuration file. Eli.
Can you please check whether the issue still happens with a current version of exim 4, and send us a copy of your /etc/exim4/update-exim4.conf.conf file? Greetings Marc
Marc wrote:
Answer is quite simple unfortunately - I didn't notice this at first since
I've had a headache the past few days, and an obnoxious cat pissing me off
all day to add to the headache.
"hosts_try_auth" expects a *HOST* list. Unfortunately for lack of better
choices, a "host" list is in fact a list of IPs. You cannot specify a
hostname in a hostlist. You're specifying a hostname in the hosts_try_auth
variable when it wants an IP. I will explain why it wants an IP now...
The file "passwd.client" is being used to store the name of the smarthost
(as a hostname), and the user/pass used for authentication.
Your problem is that Exim does a dns lookup to retrieve the IP of the
smarthost server you specify in route_list. This means when you specify
"smarthost.fqdn.example", it looks that up (no way to stop this unless you
specify an IP) to get an IP (or in this case a list of IPs) to deliver to.
Exim now knows it's going to deliver the email to one of:
It then passes control to the transport, which sets up delivery and checks
host_try_auth. The problem is that Exim cares not about the hostname of the
server at this point, it wants an IP to deliver to. Your config does an
"exists" test on the "passwd.client" file, sees it and expands the ${if...}
test to "smarthost.fqdn.example" which is illegal in a hostlist, so Exim
ignores it. You then fail in SMTP auth since there's no confirmation of an
IP and thus the problem.
To fix, quite simple. You specify an entry per *IP* of your mail server in
the "passwd.client" file each with the same SMTP auth credentials, and it
should work just fine (depending how your lookup is done for the SMTP auth
user/pass).
If you want a better fix, you need to redo your whole "smarthosts"
implementation, as it is not implemented correctly apparently - if you want
it to work the way the user is trying.
Eli.
I forgot to attache diff. Here is one. Osamu
tags #244724 upstream user exim4@packages.debian.org usertags #244724 valid-bug thanks I have committed some changes to svn. Thanks for providing a great starting point. Relevant to this bug may also be the discussion following http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20050221/msg00348.html, the essence of the outcome being Andreas writing: > We'll need to use a smarter lookup with or or save the original name > in $hosts_data. That smarter lookup has, however, not proven to be done easily, since we need to search for a line in passwd.client where the first field resolves to the IP we're connected to. This query-style lookup for text files is not yet possible in exim (http://www.exim.org/bugzilla/show_bug.cgi?id=65). The better possibility would be to select the authenticator in the transport where we still know the configured smarthost name for directly matching against passwd client. This also is not yet possible in exim (http://www.exim.org/bugzilla/show_bug.cgi?id=66). Since it would be extraordinarily hard to solve this with current exim (unless a new exciting idea comes up), I am going to tag this bug upstream and let it rot away until exim provides means to do this easier. Greetings Marc
tags #244724 upstream user exim4@packages.debian.org usertags #244724 valid-bug thanks I have committed some changes to svn. Thanks for providing a great starting point. Relevant to this bug may also be the discussion following http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20050221/msg00348.html, the essence of the outcome being Andreas writing: > We'll need to use a smarter lookup with or or save the original name > in $hosts_data. That smarter lookup has, however, not proven to be done easily, since we need to search for a line in passwd.client where the first field resolves to the IP we're connected to. This query-style lookup for text files is not yet possible in exim (http://www.exim.org/bugzilla/show_bug.cgi?id=65). The better possibility would be to select the authenticator in the transport where we still know the configured smarthost name for directly matching against passwd client. This also is not yet possible in exim (http://www.exim.org/bugzilla/show_bug.cgi?id=66). Since it would be extraordinarily hard to solve this with current exim (unless a new exciting idea comes up), I am going to tag this bug upstream and let it rot away until exim provides means to do this easier. Greetings Marc
Hi, After reading interesing discussion, I realise that it may be useful to have *EASY TO ACTIVATE* configuration option to enable debug output to address request: I hope /etc/exim4/debug.conf should have entry EXIM_DEBUG_LEVEL=5 EXIM_DEBUG_LOG=/var/log/exim4/debug.log or something :-) 0 being no debug output. Shoot me because I did not check if you already have this or not. Just my late night thought... Osamu
Hi, After reading interesing discussion, I realise that it may be useful to have *EASY TO ACTIVATE* configuration option to enable debug output to address request: I hope /etc/exim4/debug.conf should have entry EXIM_DEBUG_LEVEL=5 EXIM_DEBUG_LOG=/var/log/exim4/debug.log or something :-) 0 being no debug output. Shoot me because I did not check if you already have this or not. Just my late night thought... Osamu
My ISP put back AUTH for SMTP so I hit this bug again :-) It took me a while to realize the confofuration needs to use canonical name or just *. I think Debian provided configuration is better to use wildsearch than plain lsearch to enable wildcard in the hostname field here. Also, since I can not call the current /etc/exim4/passwd.client explanation as verbose and it may be overlooked if it was user modified, I updated README.Debian to point to the manpage which is not so easy to find for novice: $ man -k passwd.client exim4_passwd_client (5) - Files in use by the Debian exim4 packages The conclusion is here as attached patch. If this patch is not applied, the user who is seeking solution can modify their /etc/exim4/* contents as these changes and should be fine since these are conffiles.
Hi, I realized the recent passwd.client template is quite verbose. But I still think it is better to remind people for the current man page since it is always there. User may be using old template when updated. Still wildlsearch gives chance to use multiple ISPs with different account name and password so my patch should have value. Maybe question is if we should use wildlsearch or nwildlsearch. Also adding regular expression example such as ^\N.*smtp.*\.dti\.ne\.jp\N:ACCOUNTNAME:PASSWORD May be interesting addition for both manpage and passwd.client template. Regards, Osamu
Hi Osamu, That's a rather neat idea and I'm going to implement this soon. I am wondering, however, that we shuold probably use nwildlsearch instead of the wildlsearch* you have been suggesting. We do not need string expansion there, and wildlsearch* strikes me as redundant. Can you please verify? That is a good idea as well since the current /etc/exim4/passwd.client docs do little more than pointing the user to the manpage. I do not understand this part of the patch. Server authentication does not use passwd.client, and your change is going to introduce wildcards for _user names_, which does not sound desireable. Any chance that this part of the patch is result of a search-and-replace call? Without better arguments, I'm not going to take this part of the patch. The other instances of lsearch* have been replaced by nwildlsearch in svn, and pending successful testing, I'm going to upload soon. These are very good patches, modulo some Japanisms in the English wording, which I have replaced by appropriate Germanisms ;) Greetings Marc
Looks good ;) Ok, I suspected this. passwd.client in svn is now: # password file used when the local exim is authenticating to a remote # host as a client. # # see exim4_passwd_client(5) for more documentation # # Example: ### target.mail.server.example:login:password I do not see any need to adapt this. I have moved the passwd.client discussion from conf.d/auth/30_exim4-config_examples to the man page, and added a man page reference to conf.d/auth/30_exim4-config_examples. Greetings Marc
Hi, OK. If this mail goes out, then nwildlsearch is working :-) Now I have passwd.client ### with nwildlsearch ^.*smtp.*\.dti\.ne\.jp:foo@my.isp.net:XXXXXXX Let's think a bit while we are at it. This was accidental. I will test this mail without it. ... Also, you may want to update comments passwd.client comments and reference to passwd.client in 30_exim~xamples too. Let's see. Osamu
A bit of documentstion idea attached. Osamu
I have added the reference to update-exim4.conf(8). Ah, that's what you mean. I need to investigate this further to find out more examples. Greetings Marc
Yep. You had this in debconf template while not in the most critical manpage. If you dare, some IPv6 example may be the thing but I doubt it is used as much yet. Osamu
.I dc_smarthost List of hosts to which all outgoing mail is passed to and that takes care of delivering it. Multiple hosts are semicolon separated. Each of the hosts is tried, in the order specified (See exim specification, chapter 20.5). All deliveries go out to TCP port 25 unless a different port is specified after the host name, separated from the host name by two colons. Colons in IPv6 addresses need to be doubled. If a port number follows, IP addresses may be enclosed in brackets, which might be the only possibility to specify delivery to an IPv6 address and a different port. Examples: .br .BR host.domain.example deliver to host looked up on DNS, tcp/25 .br .BR host.domain.example::587 deliver to host looked up on DNS, tcp/587 .br .BR 192.168.2.4 deliver to IPv4 host, tcp/25 .br .BR 192.168.2.4::587 deliver to IPv4 host, tcp/587 .br .BR [192.168.2.4]::587 deliver to IPv4 host, tcp/587 .br .BR 2001::0db8::f::4::::2 deliver to IPv6 host, tcp/25 .br .BR [2001::0db8::f::4::::2]::587 deliver to IPv6 host, tcp/587 .br This is used as value of the DCsmarthost macro. Is this acceptable? Or did I miss examples? Greetings Marc
This has become a recurring issue and is documented now in the exim4-config_files(5) man page. Greetings Marc
This has become a recurring issue and is documented now in the exim4-config_files(5) man page. Greetings Marc
Hi, According to exim4_passwd_client(5), my configuration should not work, but it does (which is nice). I have the following router: | xxlweb: | debug_print = "R: xxlweb for $local_part@$domain" | driver = manualroute | senders = xxlweb.owsiany.pl | domains = ! +local_domains | transport = remote_smtp_smarthost | route_list = * mail.xxlweb.owsiany.pl byname | host_find_failed = defer | same_domain_copy_routing = no | no_more And the following data in passwd.client: | mail.xxlweb.owsiany.pl:porridge@xxlweb.owsiany.pl:my-secret-password Where mail.xxlweb.owsiany.pl is an A record: | ; <<>> DiG 9.4.1-P1.1 <<>> mail.xxlweb.owsiany.pl | ;; global options: printcmd | ;; Got answer: | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22706 | ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 | | ;; QUESTION SECTION: | ;mail.xxlweb.owsiany.pl. IN A | | ;; ANSWER SECTION: | mail.xxlweb.owsiany.pl. 24582 IN A 81.169.178.178 | | ;; AUTHORITY SECTION: | xxlweb.owsiany.pl. 24582 IN NS ns1.xxl-dns.de. | xxlweb.owsiany.pl. 24582 IN NS ns2.xxl-dns.de. | | ;; ADDITIONAL SECTION: | ns1.xxl-dns.de. 9492 IN A 81.169.167.222 | ns2.xxl-dns.de. 9492 IN A 85.214.120.249 | | ;; Query time: 27 msec | ;; SERVER: 212.17.32.1#53(212.17.32.1) | ;; WHEN: Mon Apr 13 11:35:55 2009 | ;; MSG SIZE rcvd: 134 But this IP addresses' reverse record is something else: | ; <<>> DiG 9.4.1-P1.1 <<>> -x 81.169.178.178 | ;; global options: printcmd | ;; Got answer: | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64868 | ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 11 | | ;; QUESTION SECTION: | ;178.178.169.81.in-addr.arpa. IN PTR | | ;; ANSWER SECTION: | 178.178.169.81.in-addr.arpa. 412 IN PTR alpha349.server4rent.eu. | | ;; AUTHORITY SECTION: [..snip..] | ;; Query time: 47 msec | ;; SERVER: 212.17.32.1#53(212.17.32.1) | ;; WHEN: Mon Apr 13 11:37:19 2009 | ;; MSG SIZE rcvd: 485 The manpage says this will make the /etc/exim4/passwd.client lookup fail, because it will look for alpha349.server4rent.eu, which is not there. But it does work, and it seems exim looks for the name specified in the router. This is with exim4 4.67-5build1 (ubuntu gutsy). Is this just a "lucky" corner case? Or has something been changed recently, and the bug can be closed? | >>>>>>>>>>>>>>>> Remote deliveries >>>>>>>>>>>>>>>> | --------> marcin@owsiany.pl <-------- | search_tidyup called | changed uid/gid: remote delivery to marcin@owsiany.pl with transport=remote_smtp_smarthost | uid=109 gid=121 pid=21851 | auxiliary group list: <none> | set_process_info: 21851 delivering 1LtJLS-0005gM-DE using remote_smtp_smarthost | T: remote_smtp_smarthost for marcin@owsiany.pl | set_process_info: 21850 delivering 1LtJLS-0005gM-DE: waiting for a remote delivery subprocess to finish | selecting on subprocess pipes | remote_smtp_smarthost transport entered | marcin@owsiany.pl | owsiany.pl in queue_smtp_domains? no (option unset) | checking status of mail.xxlweb.owsiany.pl | locking /var/spool/exim4/db/retry.lockfile | locked /var/spool/exim4/db/retry.lockfile | EXIM_DBOPEN(/var/spool/exim4/db/retry) | returned from EXIM_DBOPEN | opened hints database /var/spool/exim4/db/retry: flags=O_RDONLY | dbfn_read: key=T:mail.xxlweb.owsiany.pl:81.169.178.178 | dbfn_read: key=T:mail.xxlweb.owsiany.pl:81.169.178.178:1LtJLS-0005gM-DE | no host retry record | no message retry record | mail.xxlweb.owsiany.pl [81.169.178.178] status = usable | 81.169.178.178 in serialize_hosts? no (option unset) | delivering 1LtJLS-0005gM-DE to mail.xxlweb.owsiany.pl [81.169.178.178] (marcin@owsiany.pl) | set_process_info: 21851 delivering 1LtJLS-0005gM-DE to mail.xxlweb.owsiany.pl [81.169.178.178] (marcin@owsiany.pl) | Connecting to mail.xxlweb.owsiany.pl [81.169.178.178]:25 ... connected | waiting for data on socket | read response data: size=35 | SMTP<< 220 alpha349.server4rent.eu ESMTP | 81.169.178.178 in hosts_avoid_esmtp? no (option unset) | SMTP>> EHLO localhost | waiting for data on socket | read response data: size=135 | SMTP<< 250-alpha349.server4rent.eu | 250-AUTH=LOGIN CRAM-MD5 PLAIN | 250-AUTH LOGIN CRAM-MD5 PLAIN | 250-STARTTLS | 250-PIPELINING | 250 8BITMIME | 81.169.178.178 in hosts_avoid_tls? no (option unset) | SMTP>> STARTTLS | waiting for data on socket | read response data: size=19 | SMTP<< 220 ready for tls | initializing GnuTLS as a client | read D-H parameters from file | initialized D-H parameters | no TLS client certificate is specified | initialized certificate stuff | initialized GnuTLS session | cipher: TLS-1.0:RSA_AES_256_CBC_SHA1:32 | SMTP>> EHLO localhost | tls_do_write(bff40227, 16) | gnutls_record_send(SSL, bff40227, 16) | outbytes=16 | waiting for data on socket | Calling gnutls_record_recv(8145b58, bff3e227, 4096) | read response data: size=121 | SMTP<< 250-alpha349.server4rent.eu | 250-AUTH=LOGIN CRAM-MD5 PLAIN | 250-AUTH LOGIN CRAM-MD5 PLAIN | 250-PIPELINING | 250 8BITMIME | 81.169.178.178 in hosts_avoid_pipelining? no (option unset) | using PIPELINING | 81.169.178.178 in hosts_require_auth? no (option unset) | search_open: nwildlsearch "/etc/exim4/passwd.client" | search_find: file="/etc/exim4/passwd.client" | key="mail.xxlweb.owsiany.pl" partial=-1 affix=NULL starflags=0 | LRU list: | ?/etc/exim4/passwd.client | End | internal_search_find: file="/etc/exim4/passwd.client" | type=nwildlsearch key="mail.xxlweb.owsiany.pl" | file lookup required for mail.xxlweb.owsiany.pl | in /etc/exim4/passwd.client | mail.xxlweb.owsiany.pl in "mail0.vicoop.com"? no (end of list) | mail.xxlweb.owsiany.pl in "mail.xxlweb.owsiany.pl"? yes (matched "mail.xxlweb.owsiany.pl") | lookup yielded: porridge@xxlweb.owsiany.pl:my-secret-password
I just realized I snipped the output just before the most interesting part, though it does not change my point, the lookup key is the same: | 81.169.178.178 in hosts_try_auth? yes (matched "81.169.178.178") | scanning authentication mechanisms | search_open: nwildlsearch "/etc/exim4/passwd.client" | cached open | search_find: file="/etc/exim4/passwd.client" | key="mail.xxlweb.owsiany.pl" partial=-1 affix=NULL starflags=0 | LRU list: | ?/etc/exim4/passwd.client | End | internal_search_find: file="/etc/exim4/passwd.client" | type=nwildlsearch key="mail.xxlweb.owsiany.pl" | cached data used for lookup of mail.xxlweb.owsiany.pl | in /etc/exim4/passwd.client | lookup yielded: porridge@xxlweb.owsiany.pl:my-secret-password | search_open: nwildlsearch "/etc/exim4/passwd.client" | cached open | search_find: file="/etc/exim4/passwd.client" | key="mail.xxlweb.owsiany.pl" partial=-1 affix=NULL starflags=0 | LRU list: | ?/etc/exim4/passwd.client | End | internal_search_find: file="/etc/exim4/passwd.client" | type=nwildlsearch key="mail.xxlweb.owsiany.pl" | cached data used for lookup of mail.xxlweb.owsiany.pl | in /etc/exim4/passwd.client | lookup yielded: porridge@xxlweb.owsiany.pl:my-secret-password | SMTP>> AUTH CRAM-MD5 | tls_do_write(bff40227, 15) | gnutls_record_send(SSL, bff40227, 15) | outbytes=15 | waiting for data on socket | Calling gnutls_record_recv(8145b58, bff3e227, 4096) | read response data: size=62 | SMTP<< 334 PDEyNjcxLjEyMzk2MTgzMDNAYWxwaGEzNDkuc2VydmVyNHJlbnQuZXU+ | SMTP>> ******************************************************************************** | tls_do_write(bff40227, 82) | gnutls_record_send(SSL, bff40227, 82) | outbytes=82 | waiting for data on socket | Calling gnutls_record_recv(8145b58, bff3e227, 4096) | read response data: size=14 | SMTP<< 235 go ahead
This file no longer exists, as of 4.72-6+squeeze2 (I'm running squeeze).
I just ran into this bug. I did not read the discussion carefully,
but since it has been open for 7 years, I assume it is not so easy to fix.
I just want to say that the exim4-config_files man page is not the first,
or the second, or the third place I would think of looking for the
solution to this problem. :-) Therefore, may I respectfully suggest that
the relevant paragraph from the exim4-config_files man page be copied to
the top of /etc/exim4/passwd.client or at a miniumum a pointer be added
there? Bear in mind that an auth failure doesn't not immediately point to
a config issue. Thanks for your attention.
Regards, Faheem
This file no longer exists, as of 4.72-6+squeeze2 (I'm running squeeze).
I just ran into this bug. I did not read the discussion carefully,
but since it has been open for 7 years, I assume it is not so easy to fix.
I just want to say that the exim4-config_files man page is not the first,
or the second, or the third place I would think of looking for the
solution to this problem. :-) Therefore, may I respectfully suggest that
the relevant paragraph from the exim4-config_files man page be copied to
the top of /etc/exim4/passwd.client or at a miniumum a pointer be added
there? Bear in mind that an auth failure doesn't not immediately point to
a config issue. Thanks for your attention.
Regards, Faheem
Much like Marcin in 2009, I'm not seeing a problem
with reverse DNS lookups in 2012.
The warning is in the man page for
exim4_passwd_client.
It says, in part
"This goes inevitably wrong if [...] the
reverse lookup does not fit the forward one."
I was worried that since the reverse DNS of my
smarthost listed in /etc/exim4/passwd.client
reports a different domain name, exim wouldn't
work.
But it did.
My smarthost has a DNS "A" record.
I'm using version 4.80-5.1 of exim.
Thanks,
Kingsley
Мaybe add another variable to store the original address of smarthost?
For information, Debian bug #837535 [1] (closed and archived)
and upstream Exim.org bug #1885 [2] (closed and tagged wontfix)
probably turn out to be instances of the Debian bug whose log
you are reading, #244724 [3].
1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837535
2: https://bugs.exim.org/show_bug.cgi?id=1885
3: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=244724
No action is requested. No reply is needed (unless you have
something you would like me to test). This message is just for
information. Thank you for maintaining Exim.
For users affected by this issue: the aforementioned Exim.org
bug log details a thorough and apparently effective workaround.
(The workaround is probably not new, but the discussion with
upstream developers in the Exim.org bug log is unusually
informative. The discussion starts with an incorrect premise
of mine, but ends with a fairly clear understanding of the
problem by everybody involved.)
Dear Customer, We can not deliver your parcel arrived at January 02. Postal label is enclosed to this e-mail. Please check the attachment! Yours respectfully, Lloyd Richardson, USPS Delivery Agent.
[image: Inline image 1]