Bug 135060 - Bad address syntax
Summary: Bad address syntax
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: fetchmail
Version: 2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Miloslav Trmač
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-08 12:48 UTC by Mihnea Galca
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-06-07 20:15:43 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Fetchmail's log (2.84 KB, text/plain)
2004-10-08 12:50 UTC, Mihnea Galca
no flags Details

Description Mihnea Galca 2004-10-08 12:48:52 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3)
Gecko/20040910

Description of problem:
I get "bad address syntax" error while trying to fetch mail from a
remote pop3 server. The problem is serious, because the corresponding
mails are lost for ever (the ones with bad address syntax).

But, this error occurs only when I receive mail from a yahoo mail group.

I don't know if the problem is in fetchmail or in postfix.

I have a cyrus-imapd server (cyrus-imapd-2.2.3-11) and I use postfix
for mail delivery (postfix-2.0.18-4)

If I try to see the "bad" emails with a web mail interface, that the
provider has, these mails are displayed correctly.

NOTE: All other emails are received correctly.

Version-Release number of selected component (if applicable):
fetchmail-6.2.5-2

How reproducible:
Always

Steps to Reproduce:
1. Receive a mail from a yahoo group mail to a remote pop3 account.
2. Try to fetch it, using fetchmail and deliver it to local
cyrus-imapd server using postfix.
3.
    

Actual Results:  "501: Bad address syntax" is shown and the mail is lost

Expected Results:  Fetch correctly the email or in the case of an
error, not to delete from the pop3 account, the corresponding emails.

Additional info:
 In the past, everything worked fine in the same configuration. I will
attach a log file generated with fetchmail -v.

Comment 1 Mihnea Galca 2004-10-08 12:50:05 UTC
Created attachment 104933 [details]
Fetchmail's log

File generated using command "fetchmail -v"

Comment 2 Matthew Miller 2005-04-26 15:14:07 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 3 Miloslav Trmač 2005-06-07 20:15:43 UTC
As far as I can see, this is what happens:

The e-mail probably contains an invalid Return-Path header, likely
Return-Path: sentto-4139122-3310-1097238050-hash=rdslink.ro:
(qmail 2050 invoked from network); 8 Oct 2004 12:20:58 -0000

* fetchmail attempts to use it as a sender's e-mail address; postfix correctly
  rejects it.
* fetchmail attempts to bounce the e-mail to the sender; postfix correctly
  rejects it as well.
* fetchmail can't do anything about that e-mail now; if fetchmail was leaving
  such e-mails in the mailbox, the mailbox could eventually become full,
  leading to loss of "valid" e-mails. So it deletes the e-mail because it
  can't ever be delivered anywhere.

This is all behaving as intended. If you want to, you can (and probably should)
use "set no bouncemail" to direct the bounce to your mailbox; that way
you will recieve at least the bounce.

Note that it is possible that there is a bug in fetchmail header parsing code;
I think it is rather unlikely because there are other reports of similarly
mangled e-mails (e.g.
http://lists.ccil.org/pipermail/fetchmail-friends/2004-May/008631.html), but
it is still possible.

If you come across such a "bad e-mail" in the web interface again, please
try to get all its headers (unmodified); if it doesn't contain any
mangled Return-Path header, please reopen this bug report and attach
at least the headers.


Note You need to log in before you can comment on or make changes to this bug.