[Dovecot] Dovecot discards mail over quota

[Steffen Kaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

That's wrong.
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

"In either
    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 
bounce message.

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
    responsibility for:

    -  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
       MAIL command).
"

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 
phase succeeded.

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.

Bye,

- -- 
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBSXWxDHWSIuGy1ktrAQIAbggAt431hphUNLlhZn9M/kundiaqzFChjuTS
LxtsOa5csFFLwbLK+wy+G6tZXMZp/mcd2N8EzAeDz3VnZ8FrpZuMw4X2CxRz86ou
g1grQroWvBHAFJrMMQmjS9Nc8szWTFxo0cpjJ2nqCKs/bQ/ExDLOQd2XQxu4W0nd
CAYWKpB5CcfTJSEQ9FKY0W1Nx8OE1FbT6JX7fTnDWhPthcZXR2L5i3O/cAJl9TRu
rs2d7+/K4k3O8luDF+d47+uNXc5w/y2tPXcJs9AV+P4MkJkcMOPpsAeX7K54XVcm
JAKXYABbQC/QFr6LNY96BkW6wsW7IRSCTUHJrCrKBqBZI9+jwLVcig==
=XzBE
-----END PGP SIGNATURE-----