How Fetchmail made me a spammer

David Wolfskill david at catwhisker.org
Thu Jan 14 13:40:06 UTC 2010


On Thu, Jan 14, 2010 at 10:16:56AM +0100, Benjamin Lutz wrote:
> ...
> The lessons learned:
> - I need better monitoring. I already monitor postfix's queue size and
>   get alerts if it goes above a certain size, but in this case, the email
>   in question never ended up in the queue. Monitoring bandwidth usage at
>   the firewall and mails-per-hour at the mail server (which includes error
>   notices) should let me detect sooner that something is amiss next time.

For monitoring various Postfix queue sizes, I wrote (and sent a copy to
postfix-users@ 2 - 3 years ago) a Perl script that did the job
significantly more efficiently than the then-current practice of some of
my colleagues at my employer at the time.  I believe I called it
"qstat".  If you're not already using it, and are concerned with Postfix
queue sizes over time, I recommend at least checking it out.  (Its use
can also help someone new to Postfix get a better grasp of how messages
move from one queue to another during the course of Postfix processing.)


> - Postfix's default 10MB size limit seems outdated seeing how internet
>   connections have become faster; I've upped it to 50MB.

Errr... it's a "default" because it's a configuration parameter that
you're welcome to change should your situation warrant such a change.

While this is rather an "apples vs. oranges" pseudo-comparison, I note
that the maximum allowable size for messages on most of the technical
lists @FreeBSD.org is 200KB.

> - Fetchmail's defaults are dangerous. The softbounce option, which is the
>   default (the manpage claims it'll be disabled by default with the next
>   version,) can generate large amounts of spam.

I would strongly encourage great caution in any effort involving
generating email as a result of post-processing an email message that
has completed "final delivery" (in the MTA, vs. human, sense).  Note
that a message in that state may well lack reliable indications of the
envelope-sender and -recipient addresses.

Even declining to accept such a (secondary) message (by rejecting
deliivery) can easily be problematic (at best).

And any message awaiting access via POP has undergone final delivery
already.

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-chat/attachments/20100114/fcc46481/attachment.pgp


More information about the freebsd-chat mailing list