Jump to content

Talk:Bounce message

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by N0w8st8s (talk | contribs) at 03:32, 21 August 2016 (→‎Request for History of term "Mailer-Daemon"). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

WikiProject iconComputing Unassessed
WikiProject iconThis article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
???This article has not yet received a rating on Wikipedia's content assessment scale.
???This article has not yet received a rating on the project's importance scale.

Proposal to merge the two "bounce" articles

Most links to bounce address are redirections of the various aliases, they can as well end up at bounce message, with a short explanation of the concept, and links to relevant articles (especially SMTP, VERP, SPF, BATV). Besides "bounce address" is not the "official" name of this beast, the standards use "reverse path" (for the old SMTP with source routes) or "envelope sender" (for the modern SMTP without source routes). --217.184.142.38 (talk) 16:20, 28 May 2008 (UTC)[reply]

When I created the bounce address article, I considered putting the subject into a section here, but I felt it would be clearer in a separate article to clear up the many names for a single concept. In particular, I was concerned for readers of other articles who come across another alias for this subject that they hadn't heard of before. They would want to know that yes, "reverse path" is the same as "envelope from", not about what a bounce message is. The "bounce message" article already has enough to clear up with the many different names for it (DSN, NDN, etc.), I didn't think adding more naming confusion about a separate subject would help. As far as the "official name" goes, I know of no place that defines it. The various RFCs use many of the different aliases, often several within a single RFC. I think I'll go and list the RFCs that use the different aliases, that might be useful. Wrs1864 (talk) 16:59, 28 May 2008 (UTC)[reply]

Okay, you have a plan, I wasn't sure if the article is a dupe. I explained the historical concept (reverse path) in the SRS article, maybe not the best place. 2821bis eliminates all ambiguous uses of "bounce", 2821 used it as synonym for "reject". The DSN RFCs (draft standard) use "envelope sender address", 2821bis sticks to "reverse path", and 2822upd sticks to its "Return-Path" header field. The important thing is IMO that it is not only about a (potentially) arbitrary bounce address, but also about a really responsible envelope sender. It's not only used for bounces, but also for other auto replies (RFC 3834), MDNs, and SPF. I'll remove the merge tags --17:59, 28 May 2008 (UTC) (greets from FE ;-) —Preceding unsigned comment added by 217.184.142.38 (talk)


references to VERP

I don't have time to edit this right now, but the "not widely used compared to VERP" comment seems gratuitous, misleading, unsupportable, and inappropriate for what is essentially a reference section of this article. VERP is orthogonal to SMTP DSN requests and the two can be used independently of one another. VERP is a way of using unique return addresses to aid in sorting out of nondelivery reports (whether in DSN format or some other format), while the SMTP DSN extension is a way of requesting specific features of the DSN service (including e.g. positive delivery reports) and arranging for information to be included in DSNs that make the DSNs more usable. VERP is a useful idea and it certainly seems appropriate to mention it in this article, but it shouldn't be mentioned in a "my idea is better" fashion. Keithmoore (talk) 19:36, 6 June 2008 (UTC)[reply]

It's also beside the point for a "related RFCs" section, I've removed it again. As it happens I know exactly what the March 2006 edits were about. --217.184.142.35 (talk) 08:53, 16 June 2008 (UTC)[reply]

Split Disposition-Notification-To topic

So charitable of you all to redirect Delivery Status Notification here. Just lumping Disposition-Notification-To: in here as if it was all the same. Jidanni (talk) 02:47, 2 June 2009 (UTC)[reply]


Request for History of term "Mailer-Daemon"

Can anybody enlighten us with the history of this name for bounce messages? Why is it that no matter what email system is sending the bounce, the message is sent from mailer-daemon? Who chose this name?

I find the name cute and anthropomorphic, but I do not know why it is universally applied.

Any help out there?

67.160.120.194 (talk) 19:57, 15 July 2009 (UTC)[reply]

I read the entire article and still don't know what a daemon is....I know what it does, but I don't know what it is, nor where it resides, nor what its code consists of or anything about it. N0w8st8s (talk) 03:31, 21 August 2016 (UTC)n0w8st8s[reply]

Page moved back to "Bounce message"

Looks like this article was unilaterally moved to "Non delivery report" in 2010. That's a horrible title for a couple reasons: "non" must be hyphenated or joined directly to the following word, not spaced, and "non-delivery report" is nowhere near the most common term for an automated email rejection message. I've moved it back to "Bounce message". —Darkwind (talk) 05:02, 1 June 2013 (UTC)[reply]