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