diff options
-rw-r--r-- | NEWS | 3 | ||||
-rw-r--r-- | driver.c | 36 | ||||
-rw-r--r-- | fetchmail-FAQ.html | 9 |
3 files changed, 32 insertions, 16 deletions
@@ -18,8 +18,9 @@ fetchmail-4.1.0 () * Enable parser to detect and complain about the most common syntax error. * More warnings about things that can go wrong with multidrop. * Dave Bodenstab's fix for flaky phone lines. +* Always pass FQDNs in RCPT TO addresses (avoids minor tsuris with exim). -There are 262 people on the fetchmail-friends list. +There are 263 people on the fetchmail-friends list. fetchmail-4.0.8 (Thu Aug 7 17:05:27 EDT 1997) * Fixed core dump bug in UID handling introduced by the 4.0.6 change. @@ -862,7 +862,7 @@ int num; /* index of message */ } else { - char *ap, *ctt, options[MSGBUFSIZE]; + char *ap, *ctt, options[MSGBUFSIZE], addr[128]; /* build a connection to the SMTP listener */ if ((smtp_open(ctl) == -1)) @@ -984,14 +984,19 @@ int num; /* index of message */ * * RFC 1123 requires that the domain name part of the * RCPT TO address be "canonicalized", that is a FQDN - * or MX but not a CNAME. RFC1123 doesn't say whether - * the FQDN part can be null (as it frequently will be - * here), but it's hard to see how this could cause a - * problem. + * or MX but not a CNAME. Some listeners (like exim) + * enforce this. */ for (idp = xmit_names; idp; idp = idp->next) if (idp->val.num == XMIT_ACCEPT) - if (SMTP_rcpt(ctl->smtp_socket, idp->id) == SM_OK) + { +#ifdef HAVE_SNPRINTF + snprintf(addr, sizeof(addr)-1, "%s@%s", idp->id,fetchmailhost); +#else + sprintf(addr, "%s@%s", idp->id, ); +#endif /* HAVE_SNPRINTF */ + + if (SMTP_rcpt(ctl->smtp_socket, addr) == SM_OK) good_addresses++; else { @@ -1000,12 +1005,21 @@ int num; /* index of message */ error(0, 0, "SMTP listener doesn't like recipient address `%s'", idp->id); } - if (!good_addresses && SMTP_rcpt(ctl->smtp_socket, user) != SM_OK) + } + if (!good_addresses) { - error(0, 0, - "can't even send to calling user!"); - free(headers); - return(PS_SMTP); +#ifdef HAVE_SNPRINTF + snprintf(addr, sizeof(addr)-1, "%s@%s", idp->id, fetchmailhost); +#else + sprintf(addr, "%s@%s", idp->id, ); +#endif /* HAVE_SNPRINTF */ + + if (SMTP_rcpt(ctl->smtp_socket, user) != SM_OK) + { + error(0, 0, "can't even send to calling user!"); + free(headers); + return(PS_SMTP); + } } /* tell it we're ready to send data */ diff --git a/fetchmail-FAQ.html b/fetchmail-FAQ.html index 844ad20a..4d48e2a6 100644 --- a/fetchmail-FAQ.html +++ b/fetchmail-FAQ.html @@ -10,7 +10,7 @@ <table width="100%" cellpadding=0><tr> <td width="30%">Back to <a href="index.html">Fetchmail Home Page</a> <td width="30%" align=center>To <a href="/~esr/sitemap.html">Site Map</a> -<td width="30%" align=right>$Date: 1997/08/10 19:00:48 $ +<td width="30%" align=right>$Date: 1997/08/11 20:03:53 $ </table> <HR> <H1>Frequently Asked Questions About Fetchmail</H1> @@ -741,10 +741,11 @@ Note this <em>does</em> require a modern /bin/sh.<p> <h2><a name="T2">T2. How can I use fetchmail with exim?</a></h2><p> By default, the exim listener enforces the the RFC1123 requirement -that MAIL FROM addresses you pass to it have to be canonical +that MAIL FROM and RCPT TO addresses you pass to it have to be canonical (e.g. with a fully qualified hostname part). <p> -This is a potential problem if the MTAs upstream from your fetchmail +Fetchmail always passes fully qualified RCPT TO addresses. But +MAIL FROM is a potential problem if the MTAs upstream from your fetchmail don't necessarily pass canonicalized From and Return-Path addresses, and fetchmail's <CODE>rewrite</CODE> option is off. The specific case where this has come up involves bounce messages generated by sendmail @@ -1233,7 +1234,7 @@ to solve the problem system-wide.<P> <table width="100%" cellpadding=0><tr> <td width="30%">Back to <a href="index.html">Fetchmail Home Page</a> <td width="30%" align=center>To <a href="/~esr/sitemap.html">Site Map</a> -<td width="30%" align=right>$Date: 1997/08/10 19:00:48 $ +<td width="30%" align=right>$Date: 1997/08/11 20:03:53 $ </table> <P><ADDRESS>Eric S. Raymond <A HREF="mailto:esr@thyrsus.com"><esr@snark.thyrsus.com></A></ADDRESS> |