--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--