fetchmail-friends
[Top] [All Lists]

[fetchmail]Re: The 5.8.16 release of fetchmail is available

2001-08-05 11:43:46
esr(_at_)thyrsus(_dot_)com (Eric S. Raymond) writes:

The 5.8.16 release of fetchmail is now available at the usual locations,
including <URL:http://www.tuxedo.org/~esr/fetchmail>.

I see four bugs in this version that should be fixed before 5.9.0.

fetchmail runs on a Linux 2.2 or 2.4 box, and forwards to localhost
which runs Postfix release 20010228-pl03.

SUMMARY:

Problem #1: fetchmail still looks up host names in "skip" entries
Problem #2: fetchmail uses @localhost as envelope sender on bounces
Problem #3: fetchmail doesn't cope with spaces in user names (multi-drop)
Problem #4: bogus bounces

DETAILS:

Problem #1: fetchmail looks up host names in "skip" entries unless the
            option "no dns" is set.

  .fetchmailrc contains:
    skip some.host with proto ETRN

  result:
    fetchmail: couldn't find canonical DNS name of some.host
    (the content is correct, some.host is invalid, so the DNS lookup
    must fail)

  However, had not fetchmail been changed to _not_ resolve these for
  "skip" entries?

  Adding "no dns" fixes THIS problem.

------------------------------------------------------------------------

Problem #2: fetchmail bounces mail with MAIL FROM:
            <fetchmail-daemon(_at_)localhost>

  When Postfix feeds localhost through qualification, it gets
  localhost.ping.de on that box (that's strange, but correct), forwards
  mail to the next hop and catches a double-bounce:

    status=bounced (host nx5.hrz.uni-dortmund.de[129.217.131.21] said:
    501 Unknown domain 'localhost.ping.de')

  and rightly so, localhost.ping.de does not exist (NXDOMAIN), as shown
  by dig:

  ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4
  ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
  ;; QUERY SECTION:
  ;;      localhost.ping.de, type = A, class = IN

  Regretfully, Postfix doesn't make rewrite exceptions for
  "localhost". If that's a good thing or not, may be debatable, however,
  that's how the release version behaves, and AFAIK, the newer snapshots
  behave in the same way.

  As a temporary workaround, after looking at the fetchmail source code,
  I added this line:

    skip some.host with proto ETRN no dns

  to the end of .fetchmailrc.

  However, an option to force fetchmail to use the FQDN might be very
  useful here, as would adding this trick to the FAQ until fetchmail has
  an option -- suggestion: set bouncefromdomain myhostname.ping.de

------------------------------------------------------------------------


Problem #3: fetchmail does not cope with spaces in user names 
            (multidrop mode)

  I am fetching mail with "envelope Delivered-To" and "qvirtual
  SOMEHOST.ping.de-" options. Sending mail to users without spaces in
  their names work fine, for existent as for non-existant users.

  Now, if I send mail to "gibt es nicht"@SOMEHOST.ping.de
  (SOMEHOST.ping.de is a mask, I don't want to reveal the real domain),
  the mail is forwarded to the user starting fetchmail and carries these
  headers:

    Delivered-To: SOMEHOST.ping.de-gibt es 
nicht(_at_)SOMEHOST(_dot_)ping(_dot_)de
    X-Fetchmail-Warning: ; SMTP listener rejected local recipient addresses: 
gibtesnicht

  fetchmail -vv writes:
    reading message 3 of 3 (1120 header octets)
    About to rewrite Return-Path: 
<ma(_at_)dt(_dot_)e-technik(_dot_)uni-dortmund(_dot_)de>
    Rewritten version is Return-Path: 
<ma(_at_)dt(_dot_)e-technik(_dot_)uni-dortmund(_dot_)de>
    
    About to rewrite To: "gibt es nicht"@SOMEHOST.ping.de
    Rewritten version is To: "gibt es nicht"@SOMEHOST.ping.de
    
    About to rewrite From: 
ma(_at_)dt(_dot_)e-technik(_dot_)uni-dortmund(_dot_)de (Matthias Andree)
    Rewritten version is From: 
ma(_at_)dt(_dot_)e-technik(_dot_)uni-dortmund(_dot_)de (Matthias Andree)
    
    fetchmail: mapped gibtesnicht to local gibtesnicht
    fetchmail: forwarding to SOMEHOST.ping.de
    fetchmail: SMTP> MAIL 
FROM:<ma(_at_)dt(_dot_)e-technik(_dot_)uni-dortmund(_dot_)de> SIZE=1151
    fetchmail: SMTP< 250 Ok
    fetchmail: SMTP> RCPT TO:<gibtesnicht(_at_)SOMEHOST(_dot_)ping(_dot_)de>
    fetchmail: SMTP< 550 <gibtesnicht(_at_)SOMEHOST(_dot_)ping(_dot_)de>: User 
unknown
    
  fetchmail must not crunch the spaces out of the username. It can strip
  leading and trailing spaces for what it's worth.
  
  Postfix does cope with user names that have spaces:

  date | mail '"test user"'

    Aug  5 19:38:09 SOMEHOST postfix/pickup[5887]: A3585ADB0D: uid=0 from=<root>
    Aug  5 19:38:09 SOMEHOST postfix/cleanup[6097]: A3585ADB0D: 
message-id=<20010805173809(_dot_)A3585ADB0D(_at_)SOMEHOST(_dot_)ping(_dot_)de>
    Aug  5 19:38:09 SOMEHOST postfix/qmgr[5888]: A3585ADB0D: 
from=<root(_at_)SOMEHOST(_dot_)ping(_dot_)de>, size=311, nrcpt=1 (queue active)
    Aug  5 19:38:10 SOMEHOST postfix/local[6099]: A3585ADB0D: to=<test 
user(_at_)SOMEHOST(_dot_)ping(_dot_)de>, relay=local, delay=1, status=sent 
("|/usr/bin/procmail -a "$EXTENSION"")

  The test mail ends up in "/var/mail/test user":

    From root(_at_)SOMEHOST(_dot_)ping(_dot_)de  Sun Aug  5 19:39:49 2001
    Return-Path: <root(_at_)SOMEHOST(_dot_)ping(_dot_)de>
    Delivered-To: "test user"@SOMEHOST.ping.de
    Received: by SOMEHOST.ping.de (Postfix, from userid 0)
        id 8B5A0ADB0D; Sun,  5 Aug 2001 19:39:49 +0200 (CEST)
    To: "test user"@SOMEHOST.ping.de
    Message-Id: 
<20010805173949(_dot_)8B5A0ADB0D(_at_)SOMEHOST(_dot_)ping(_dot_)de>
    Date: Sun,  5 Aug 2001 19:39:49 +0200 (CEST)
    From: root(_at_)SOMEHOST(_dot_)ping(_dot_)de (root)

    Sun Aug  5 19:39:49 CEST 2001

  Sending mail remotely to "test user"@SOMEHOST.ping.de fails:

    Aug  5 19:41:43 SOMEHOST postfix/smtpd[6117]: connect from 
SOMEHOST.ping.de[62.72.94.133]
    Aug  5 19:41:43 SOMEHOST postfix/smtpd[6117]: 89D78ADB0D: 
client=SOMEHOST.ping.de[62.72.94.133]
    Aug  5 19:41:43 SOMEHOST postfix/smtpd[6117]: reject: RCPT from 
SOMEHOST.ping.de[62.72.94.133]: 550 
<testuser(_at_)SOMEHOST(_dot_)ping(_dot_)de>: User unknown; 
from=<ma(_at_)dt(_dot_)e-technik(_dot_)uni-dortmund(_dot_)de> 
to=<testuser(_at_)SOMEHOST(_dot_)ping(_dot_)de>

------------------------------------------------------------------------

Problem #4:

fetchmail sends two bounces per failed mail, the first one is ok, the
second one looks somewhat broken (mind the Diagnostic-Code: and Status fields):

First bounce: (note 550 is not in antispam)

| General SMTP/ESMTP error.
| ---
| Reporting-MTA: dns; ludwig.ping.de
| 
| Final-Recipient: rfc822; testuser   
| Last-Attempt-Date: Sun, 05 Aug 2001 19:41:48 +0200 (CEST)
| Action: failed
| Status: 5.0.0
| Diagnostic-Code: 550 <testuser(_at_)ludwig(_dot_)ping(_dot_)de>: User unknown

Note that the Final-Recipient is unqualified, which is not
allowed. 5.0.0 is not very specific, but given that neither Postfix nor
fetchmail support RFC-2034, that may be the best we can get.

Second bounce:

| Some addresses were rejected by the MDA fetchmail forwards to.
| -----
| Reporting-MTA: dns; ludwig.ping.de
| 
| Final-Recipient: rfc822; testuser   
| Last-Attempt-Date: Sun, 05 Aug 2001 19:41:48 +0200 (CEST)
| Action: failed
| Status: t.0.0
| Diagnostic-Code: testuser: 221 Bye

The Status and Diagnostic Code looks bogus and don't conform to
RFC1891. Plus, "Action: failed" does not match a "221" reply code.

-- 
Matthias Andree