Hi,
We occasionally experience an annoying feature of an
exchange/fetchmail/sendmail combination in handling of over-large mail
headers. It goes something like this...
Someone, somewhere, sends out an email to a huge list of people -
thousands - mostly on addresses on the corporate MS exchange server. The
mail is happily sent to all, and perfectly visible using outlook
(directly) or netscape mail (throught IMAP).
When fetchmail then attempts to read the message (again over IMAP), it
seems to be successful in dealing with the exchange server (a first,
eh?), but is rejected by sendmail with the following syslog entry:
Jun 5 15:00:22 homer sendmail[16035]: f55E0M616035: headers too large
(32768 max) from localhost during message collect
fetchmail then sends a bounce mail to the supposed recipient:
Subject:
This message was too large (SMTP error 552).
along with an attachment of the rejected header (in this case, it
includes the Received, From, CC, Date, Subject, Message ID, and MIME
headers - the CC header was the huge one).
The message is left on the server. All well and good so far. However,
fetchmail tries again - immediately. The net result is a (sendmail)
mailbox that fills up with bounce reports - each one approximately 64k,
and at a rate of around 5 per minute. The "warnings" option seems to
have no effect.
OS: linux 2.2.17 SMP
Fetchmail: fetchmail 5.5.5 (binary RPM)
Distribution: Redhat 7.0
sendmail: sendmail 8.11.0 (binary RPM)
exchange prompt: * OK Microsoft Exchange IMAP4rev1 server version
5.5.2654.31 (xxx) ready
The only solution seen so far is to go into the exchange mailbox
directly, and delete the unwanted mail by hand. And by that time, it
usually is very unwanted!
I agree that fetchmail's handling of each individual SMTP error is
correct, and might have a little discussion on the low limit applied by
sendmail. However, I think fetchmail should abide by it's "warnings"
option in this case, and not repeat the bounce report.
Unfortunately, we don't have a copy of the offending mail - when this
happens, the first method of fixing the problem is of course to delete
the bl@@dy thing! We do have a copy of the daemon report though, if it's
helpful.
Cheers,
Mike