[Dovecot] Dovecot discards mail over quota

[Robert Schetterer]

Hi Steffen,

Steffen Kaiser schrieb:
> 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.

anyway by this rfc discussion, this feature would be  a very nice to have !

> 
> Bye,
> 
> -- Steffen Kaiser

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria