-----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-----