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
