[Dovecot] Dovecot discards mail over quota
skdovecot at smail.inf.fh-brs.de
Tue Jan 20 13:10:02 EET 2009
-----BEGIN PGP SIGNED MESSAGE-----
On Mon, 19 Jan 2009, Charles Marcus wrote:
> On 1/18/2009 5:47 PM, Gary V wrote:
>> The only functional difference I can see (at least as far
>> as 'over quota' is concerned) is who sends the bounce (and
>> subsequently - what message the bounce contains). If that's the case,
>> it's a matter of which notification the mail admin prefers.
> Again... the only unit responsible for sending actual bounce messages is
> the SENDERS MTA. Your (receiving) MTA should only either ACCEPT (if so,
> NEVER generate a 'bounce' later), DEFER or REJECT.
To "accept" means to take over the responsibility to deliver the mail
and/or notify the sender about its forthcoming. A failed delivery is just
a DSN as read or delivered DSNs are.
RFC2821 sec 2.1
case, a formal handoff of responsibility for the message occurs: the
protocol requires that a server accept responsibility for either
delivering a message or properly reporting the failure to do so."
either to deliver or to report failure.
Once SMTP dialogue is over, "to report failure" means sent a DSN aka
RFC2821 sec 2.4 in context of garbled message content
"Delivery SMTP systems MAY
reject ("bounce") such messages rather than deliver them."
The MTA may decide to not deliver, but bounce in that case.
RFC2821 sec 3.7 about relaying explicitly states bounces, too,
RC2821 sec 4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
When an SMTP server returns a positive completion status (2yz code)
after the DATA command is completed with <CRLF>.<CRLF>, it accepts
- delivering the message (if the recipient mailbox exists), or
- if attempts to deliver the message fail due to transient
conditions, retrying delivery some reasonable number of times at
intervals as specified in section 4.5.4.
- if attempts to deliver the message fail due to permanent
conditions, or if repeated attempts to deliver the message fail
due to transient conditions, returning appropriate notification to
the sender of the original message (using the address in the SMTP
permanent failure => appropriate notification of sender
Because no MTA I'm aware of delivers during SMTP DATA phase, permanently
failed delivery attempts have to generate a bounce message per RFC.
If the MTA can detect the temp or perm problem, if it will try to deliver
the mail into the pysical mailbox later, fine - it can send a 4xy or 5xy
response for DATA, but the lag between the detection and the actual
delivery, esp. if the mail is sent to more than one recipient or an aliase
/ list, may result in a failed delivery attempt, although the test in DATA
Actually it would be a GoodThing, if failed delivery attempts could be
routed to another account, e.g. local Postmaster, if a specific condition
is fullfilled, e.g. a is-SPAM tag is present.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the dovecot