Hello.
I come across a situation when an almost-hitting-limit
message has been retried and retried multiple times
and was finally returned to the sender.
The receiving side uses a milter (antivirus application).
Here's how it looks like on the sending side:
postfix/qmgr: E7749E064: from=<sender>, size=10239013, nrcpt=1 (queue active)
postfix/smtp: E7749E064: to=<recipient>, relay=relay, delay=134789,
delays=134602/0.01/0.08/188, dsn=4.3.0, status=deferred (host relay said: 450
4.3.0 Queue file write error (in reply to end of DATA command))
Note the size of the message which is 10239013 which is
very close to the default 10Mb size limit.
And here's how it looks like on the receiving side:
postfix/cleanup: warning: milter8_message: vstream_fseek incoming/4BE085028D:
File too large
postfix/cleanup: 4BE085028D: milter-reject: END-OF-MESSAGE from host: 4.3.0
Queue file write error; from=<sender> to=<recipient> proto=ESMTP helo=<helo>
The receiving side is running old release of Postfix,
2.5.6 (I'm trying to upgrade but it is not easy since
that version uses my modifications which I want to
avoid).
This goes from milter/milter8.c:milter8_message():
case MILTER8_STAT_ENVELOPE:
if (vstream_fseek(qfile, data_offset, SEEK_SET) < 0) {
msg_warn("%s: vstream_fseek %s: %m", myname, VSTREAM_PATH(qfile));
return ("450 4.3.0 Queue file write error");
}
And vstream_fseek() does VSTREAM_FFLUSH_SOME(stream),
and if that fails, it returns -1. As far as I can
see, the problem happens due to some unflushed data
still lingering in the vstream buffer.
It is obvious that when we're trying to flush this
stream, we should account for the situation when
the message is too large, and return hard error
instead of temp-erroring.
In the history I found this:
20090918
Bugfix (introduced Postfix 2.3): with Milter RCPT TO replies
turned off, there was no automatic flush-before-read on the
smtpd-to-milter stream, because the read was done on the
cleanup-to-milter stream. Problem reported by Stephen Warren.
File: milter/milter8.c.
But this is about milter->fp, not qfile flushing.
While diffing milter/ and cleanup/ directories I
didn't find anything relevant too, so I'm not sure
the problem is fixed currently.
I'm not sure if milter8_message() is the right place
for that check - probably the caller should flush
the stream before going there, and in later versions
maybe it's fixed already, but it's difficult to say.
Thanks!
/mjt
