Date: Thu, 14 Jan 2010 05:28:52 -0800 From: David Wolfskill <david@catwhisker.org> To: Benjamin Lutz <mail@maxlor.com> Cc: freebsd-chat@freebsd.org Subject: Re: How Fetchmail made me a spammer Message-ID: <20100114132852.GF86359@bunrab.catwhisker.org> In-Reply-To: <201001141016.56877.mail@maxlor.com> References: <201001141016.56877.mail@maxlor.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--bzbqqSE9NzptQ+zO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 --=20 David H. Wolfskill david@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. --bzbqqSE9NzptQ+zO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAktPHBMACgkQmprOCmdXAD27dgCfbzhxi2sKj/rJcQZKr0IZ/2nV WV4Anj4oT9d7ODbup1audAa7XQLXq4vi =uHju -----END PGP SIGNATURE----- --bzbqqSE9NzptQ+zO--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100114132852.GF86359>