On Fri, Sep 09, 2005 at 02:20:28AM +0100, Tony Finch wrote:
On Fri, 9 Sep 2005, Alex van den Bogaerdt wrote:
I'd like to see this changed into "sending a DSN" (or something
similar) in stead of "bouncing". A bounce is like hitting a wall
(not getting in), not a notification message.
(1) DSNs are an extension so cannot be required by the base spec.
Ack. Scrap DSN, substitute with "notification message"
(2a) I think that it is excessively short-termist to care too much about
when a rejection occurs and where the bounce message is generated. If
spammers are driven to use smart hosts or submission servers as their
delivery mechanism instead of direct-to-MX spamming, then early rejection
will go back to being just an optimisation.
(2b) Having said that it's unimportant, I still wish to say that in my
experience, the terms "reject" or "SMTP-time reject" are used for 5xy
error replies, whereas "bounce" or "accept-and-bounce" are used for a
message that is accepted but subsequently results in an error message
being sent to the return path.
Your preference is noted. Are we writing an entire new RFC or are we
consolidating previous ones, not modifying existing semantics?
RFC821 defines "bounce". RFC2821bis alters this definition. As RFC821
is still the standard, I don't think the subject is unimportant.
It's like using "subdomain" when one means "label". It confuses the
hell out of people that do know the difference. All others need to
do a lookup either way.
Alex