Large incoming email getting deferrer

[dspillett]

I am having trouble with large incoming email failing to be delivered. They get caught in the deferred queue.

There are relevant looking log entries that agree with the message in the tool-tip for the messages in the web admin display of the queues:

Oct 10 19:21:56 z5 postfix/lmtp[20790]: 073296C06E: to=<address@server.com>, relay=<server.name.tld>[<111.222.333.444>]:7025, delay=336, delays=319/0.29/0.3/16, dsn=4.4.2, status=deferred (lost connection with <server.name.tld>[<111.222.333.444>] while sending end of data -- message may be sent more than once)

and

Oct 10 20:31:54 z5 postfix/lmtp[13738]: 073296C06E: to=<address@server.com>, relay=<server.name.tld>[<111.222.333.444>]:7025, delay=4534, delays=4520/0.01/0.26/14, dsn=4.4.2, status=deferred (lost connection with <server.name.tld>[<111.222.333.444>] while sending end of data -- message may be sent more than once)

where the server name and IP address are those of the Zimbra server, not a remote machine.

I've sent a few test messages to myself and it seems to be those over about 10Mb that get stuck, everything else goes through OK. Is there anywhere else I can look for clues as to why large messages are causing trouble?

If it makes any difference, zimbraMtaMaxMessageSize and zimbraFileUploadMaxSize shouldn't be the problem as they are set fairly large (104857600 and 100000000 respectively).

[Baylink]

Binary attachments to MIME encoded messages expand, since they're encoded into less dense ASCII; forgetting this is a favorite email admin mistake -- I make it too.

I think it's 4:3, but it might be 3:2; your limit is either 6.6MB or 7.5MB to fit into what Zimbra calls "10MB".

[dspillett]

Originally Posted by Baylink

I think it's 4:3, but it might be 3:2; your limit is either 6.6MB or 7.5MB to fit into what Zimbra calls "10MB".

4:3 plus a bit usually - most attachments are base64 encoded or something similar meaning each three bytes become 4, then there is usually an extra character (a line break) added every 40.

Though my settings (quoted above) are around the 100Mb mark by my understanding, not 10Mb?

And if the error was that the message was too large, I would expect it to be dropped and a bounce message send back to the originator. These messages are just getting stuck in the deferred queue.

[Baylink]

Oops. Miscounted the zeroes, sorry. That was all I had. ;-)

[dspillett]

Originally Posted by Baylink

Oops. Miscounted the zeroes, sorry. That was all I had. ;-)

No worries. Just to be sure I bumped the settings up with an extra 0 and restarted everything. Requeueing the messages still fails: they move from deferred to active then back to deferred again with the same error (as seen by watching the size of the directories under /opt/zimbra/data/postfix/spool).

For part of the time during this process the server became unresponsive (my web client gave a "server busy or not responding" message), if that is any extra clue?

(oh, and it is ~4:3 - the messages with a 13Mb attachment are showing as about 17.5Mb in the queue)

Extra: I've gone some extra testing, and found that the problem kicks in at around the 9Mb area (12 actual mail size). As it seems to take a while for larger mails to be processed I'm guessing that the problem is a time-out somewhere (though a 10Mb mail taking long enough to cause a timeout is lower performance than I'd expect, even considering I'm running Zimbra under UML). In the absence of knowing where to look for further logs to see what is baulking at the bigger mail I've set my maximums back down to 8Mb so at least anyone sending a large mail gets a useful bounce message rather than it seemingly vanishing into the ether.

If anyone has any hints on sorting the problem, let me know. Lowering the mail size limit is only a minor inconvenience, but the user is affects is one who will whine irritatingly!