Re: [Fetchmail-users] Working around "Bad sender address syntax" error?

[J. R. <jo...@an...>]

On Tuesday, September 09, 2014 10:59:51 PM Matthias Andree wrote:
> Am 09.09.2014 um 15:17 schrieb Daniel Barrett:
> > I use fetchmail to retrieve email from an IMAP server every five
> > minutes, passing it to a local postfix process on my home Linux box
> > for delivery. The problem: sometimes an email has an invalid "From"
> > 
> > line (usually spam), like this one with leading hyphens:
> >   From: "- Some Dumb Spammer" <-Du...@ex...>
> > 
> > In this case, when fetchmail retrieves the email, the local postfix
> > 
> > process raises an error:
> >   fetchmail: SMTP error: 501 5.1.7 Bad sender address syntax
> > 
> > This error causes fetchmail to leave the bad email sitting on the IMAP
> > server, even when my .fetchmailrc file specifies "nokeep". As a
> > result, fetchmail re-downloads it every five minutes. Repeat
> > forever... or until I manually delete the bad email from the IMAP
> > server.
> 
> Daniel,
> 
> Older fetchmail versions promised to never delete mail from the server
> that was not reported as delivered by its SMTP/LMTP server or MDA, and
> since v6.3.10, fetchmail lives up to this promise.
> 
> > What's the best way to break these loops automatically, either
> > deleting or delivering the bad email, without opening a security hole
> > (e.g., permitting leading hyphens)?
> 
> I see at least three options:
> 
> 1. Leading hyphens are only a security risk if you are using scripts
> that would feed them to utilities that do not understand "--" to mark
> the end of options, or without these "--".  If you're sure you're safe,
> you can permit them.
> 
> 2. If you prefer to delete permanently undeliverable messages (those
> that elicit error codes 500 and above), use --nosoftbounce on the
> command line, or "set no softbounce" in the rcfile.  Details in the
> manual page.
> 
> 3. If you prefer to delete messages with particular error codes, see the
> manual page about the antispam option, see Rob MacGregor's message for a
> reference.

I would prefer to see a 4th option:
Save the email as a TXT file in a configurable location to allow us to at 
least confirm it is spam and not a misconfigured email client. (I've 
encountered that particular situation not too long ago)

--
Joost