fetchmail, behaviour in response to SMTP 552 error code

[5tj]

Small mail server (~40 users) retrieves email from internet service provider using fetchmail.

fetchmail configuration file looks like this

poll pop.isp.example port 995 with proto pop3
user "user1@company.example" there with password "secret" is "user1@company.example" here
options fetchall ssl forcecr pass8bits norewrite;

and so on for all users.
fetchmail is called every few minutes like this

fetchmail --smtphost 127.0.0.1/25 --fetchmailrc /path/to/config

Mailserver on localhost is postfix, it is configured to accept these email addresses and deliver to local users.

Message size limit is set to 50 MB.

After running for a year without problems, one user received an email larger than the postfix message size limit in the Mailbox at the ISP.

fetchmail fetched the message via pop3 and delivered via smtp. Postfix complained about the message size (code 552) to fetchmail. Fetchmail logged the 552 code, sent a delivery failure notification to the sender, and did NOT delete the large message from the inbox at the ISP.

The events from last paragraph repeated every few minutes until the sender complained about getting hundreds of delivery failure notifications.

My question is, why did fetchmail not delete the large message from the inbox at the ISP? I generally appreciate that fetchmail makes sure that emails are correctly delivered before deleting them from the source, but in this case, as stated in the fetchmail man page, fetchmail should have deleted the message from the ISP inbox. The fetchmail man page states:

SMTP/ESMTP ERROR HANDLING

[...]

552 (message exceeds fixed maximum message size)
Delete the message from the server. Send bounce-mail to the orig‐
inator.


The "delete" part did not happen. fetchmail output:

2 message for user22@company.example at pop.isp.example (gazillion octets).
fetchmail: SMTP error: 552 5.4.3 Message size exceeds fixed limit
fetchmail: mail from MAILER-DAEMON@internal-hostname bounced to sender@large-message.example
reading message user22@company.example@pop.isp.example: 1 of 2 (gazillion octets) not flushed
reading message user22@company.example@pop.isp.example: 2 of 2 (61968 octets) flushed

(where gazillion was ~100MB)

[5tj]

This is at least unclear documentation, if not a documentation bug.

Solution is to also specify a --nosoftbounce command line parameter to fetchmail.

[NigO]

Mailserver on localhost is postfix, it is configured to accept these email addresses and deliver to local users.

Message size limit is set to 50 MB.

After running for a year without problems, one user received an email larger than the postfix message size limit in the Mailbox at the ISP.

fetchmail fetched the message via pop3 and delivered via smtp. Postfix complained about the message size (code 552) to fetchmail. Fetchmail logged the 552 code, sent a delivery failure notification to the sender, and did NOT delete the large message from the inbox at the ISP.

The events from last paragraph repeated every few minutes until the sender complained about getting hundreds of delivery failure notifications.

My question is, why did fetchmail not delete the large message from the inbox at the ISP? I generally appreciate that fetchmail makes sure that emails are correctly delivered before deleting them from the source, but in this case, as stated in the fetchmail man page, fetchmail should have deleted the message from the ISP inbox. The fetchmail man page states:

I've just come across the same problem. In my case, on a bandwidth-capped supply, fetchmail was repeatedly downloading and then failing to deliver a 10MB message, ramping up bandwidth pretty fast!

My solution was to set a limit in the fetchmailrc which was lower than my postfix limit - e.g.

limit 100000000  # 100MB per message

in the fetchmailrc and

postconf -e "message_size_limit = 101000000"

to set a 101MB limit for the local SMTP delivery using postfix.

Hope that helps someone else