return receipt vs delivery notification?
Je...@nospam.fake
and "Delivery Status notification"?
Thank you.
Millwood
along, while return receipt asks the receiving mail client to send a
received acknowledgment.
Mike Easter
> What is the difference between the TB's email options "return receipt"
> and "Delivery Status notification"?
A return receipt is an 'exchange' which can occur between two mail user
agents based on the presence of a header in the mail.
So, if both clients are so configured, the sending client can request of
the receiving client an email acknowledging receipt of the mail from the
sending client.
It doesn't work if the sending client isn't configured to send the
request for receipt and it also doesn't work if the receiving client
isn't configured or chooses to not respond to a request for receipt.
A delivery status notification, which is most commonly delivery status
notification failed is a server generated message which is emailed
optimally to the 'sender' of an email to notify the sender that such and
such a mail could not be delivered by the server to the
intended/addressed mailbox.
The term 'bounce' is often used in this DSN-failed (NDR non-delivery
report) but I don't like the bounce word because it is so often used
ambiguously - so whenever there is an ambiguous word that needs to be
explained better because it is so commonly misused, like kilobyte^1,
then I prefer to use some other terms which are more specific.
A soft bounce is different from a hard bounce. The rejection of a mail
by a mailserver is not the same as the acceptance by the mailserver
followed by an email to the From address.
There are proposals to make the DSN system more extensive^2.
^1 (kilobyte != kibibyte)
^2 http://www.faqs.org/rfcs/rfc1891.html RFC1891 - SMTP Service
Extension for Delivery Status Notificatioon
--
Mike Easter
Je...@nospam.fake
When an email I send cannot be delivered I get that notification anyway
including explanation like recipient unknown, etc. This already happens
without my ever having selected "Delivery Status Notification". Seems
redundant to me.
Marcel Stör
> What is the difference between the TB's email options "return receipt"
> and "Delivery Status notification"?
The first is for the receiving mail client and its user. Usually (i.e.
default in most mail clients) the user is being asked something along
the lines of "the sender asked to be notified that you received this
email. Allow?". The receipt would then be sent from the recipients mail
client and he might see it in his "sent items" folder.
The second is an instruction for mail servers to notify you if and when
they were able to process the email. Please note that this is optional
and most mail servers only ever send notifications if the email couldn't
be delivered - regardless of what notifications you requested.
So, receiving the second means that your email was delivered to the
recipient's inbox while receiving the first means that the recipient
actually opened the email.
--
Marcel St�r, http://www.frightanic.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
-> I kill Google posts: http://twovoyagers.com/improve-usenet.org/
David E. Ross
RFC 1891 has been replaced by RFC 3461. Furthermore, RFC 3461 is
updated but not replaced by the following RFCs: 3798, 3885, and 5337. See:
<ftp://ftp.rfc-editor.org/in-notes/rfc3461.txt>
<ftp://ftp.rfc-editor.org/in-notes/rfc3798.txt>
<ftp://ftp.rfc-editor.org/in-notes/rfc3885.txt>
<ftp://ftp.rfc-editor.org/in-notes/rfc5337.txt>
Also see <http://www.rfc-editor.org/errata_search.php?rfc=3461>.
--
David E. Ross
<http://www.rossde.com/>
I am again filtering and ignoring all newsgroup messages posted
through GoogleGroups via Google's G2/1.0 user agent because of the
amount of spam from that source.
Mike Easter
> Mike Easter wrote:
>> Je...@nospam.fake wrote:
>>> What is the difference between the TB's email options "return receipt"
>>> and "Delivery Status notification"?
>> So, if both clients are so configured, the sending client can request of
>> the receiving client an email acknowledging receipt of the mail from the
>> sending client.
That is a configurable option in Tbird, to request return receipt on the
sending end; and separately to do something or nothing about a requested
return receipt on the receiving end.
>> A delivery status notification, which is most commonly delivery status
>> notification failed is a server generated message which is emailed
>> optimally to the 'sender' of an email to notify the sender that such and
>> such a mail could not be delivered by the server to the
>> intended/addressed mailbox.
This DSN/NDR I'm describing has nothing to do with the configuration of
Tbird.
> Thank you.
YW.
> When an email I send cannot be delivered I get that notification anyway
The DSN failure/ NDR described above requires no configuration of Tbird.
> including explanation like recipient unknown, etc. This already happens
> without my ever having selected "Delivery Status Notification". Seems
> redundant to me.
I don't/didn't know of any such thing as your configuring Tbird for DSN
until I read the article cited below.
This article sez:
http://kb.mozillazine.org/Figuring_out_whether_the_recipient_read_your_message
Another type of receipt is the Delivery Status Notification (DSN)
receipt ([2]). The only purpose of DSN receipts is to let a sender know
when the recipient's server received the message. The sender cannot be
sure the message will be read but DSN is less intrusive of the
recipient's privacy than MDN and nearly all servers support it.
Thunderbird 3 supports DSN receipts. Use "Options -> Delivery Status
Notification" when composing a message to request a DSN receipt.
... and I do see that option when I am composing a message in Tb3.1.6,
but I don't believe that it will work for confirming received messages
and I don't believe that 'any' or 'nearly all' servers support it.
--
Mike Easter
Millwood
The idea was that you could request notices on success as well as
failure - but it appears many MTA's don't support this.
Je...@nospam.fake
> On 04.11.10 17:57, Je...@nospam.fake wrote:
>> What is the difference between the TB's email options "return receipt"
>> and "Delivery Status notification"?
>
> The first is for the receiving mail client and its user. Usually (i.e.
> default in most mail clients) the user is being asked something along
> the lines of "the sender asked to be notified that you received this
> email. Allow?". The receipt would then be sent from the recipients mail
> client and he might see it in his "sent items" folder.
> The second is an instruction for mail servers to notify you if and when
> they were able to process the email. Please note that this is optional
> and most mail servers only ever send notifications if the email couldn't
> be delivered - regardless of what notifications you requested.
> So, receiving the second means that your email was delivered to the
> recipient's inbox while receiving the first means that the recipient
> actually opened the email.
>
John H Meyers
> What is the difference between the TB's email options "return receipt"
> and "Delivery Status notification"?
As to what the recipient receives, apparently no difference:
I just sent one of each (checking off only one option each time)
to my Gmail account, and then compared the received "source" of both.
Aside from time stamp differences, both messages are identical upon receipt.
Both messages contain the same single header
requesting a voluntary acknowledgment from the recipient:
Disposition-Notification-To: My Sending Name <m...@sending.address>
As specified in:
http://tools.ietf.org/html/rfc3798#section-2.1
Since Gmail ignores this header, no acknowledgment will be given.
Some client(s) will process this header
only at the time of closing an opened message,
to make an acknowledgment more meaningful,
although it never means much.
There was once a "Return-Receipt-To:" header,
the use of which appears deprecated:
http://en.wikipedia.org/wiki/Return_receipt
However, there is something completely different than message content itself,
apparently a "Delivery Status Notification service extension" to SMTP:
http://tools.ietf.org/html/rfc3461#section-3
http://tools.ietf.org/html/rfc3461#section-4.1
If I interpret correctly, SMTP servers which offer this service
may be asked to turn on or off, independently, each type of
notification (failure, delay, success) at each stage of forwarding
from server to server, or even to suppress all notifications,
whereas normally failures and delays are reported and successes are not.
If any SMTP server in the route does not support this extension,
then evidently things revert to the default from that point forward.
There's a whole lot more legalese in those RFCs,
which can be used as a substitute challenge to sharpen the mind
if a New York Times crossword happens to be unavailable,
but the last time I tried to sharpen mine, my point broke off.
--
Jay Garcia
--- Original Message ---
A bit simpler ..
DSN - Delivery Status Notification - either the mail has been delivered
or not.
Return Receipt - If the mail has been delivered (DSN) then a request is
made to acknowledge whether or not the recipient has actually received
the mail and returns an acknowldgement. However, it does not guarantee
that the message has actually been read much like receiving an envelope
in your mailbox and not opening it but it HAS been delivered.
--
*Jay Garcia - Netscape/Flock Champion*
www.ufaq.org
Netscape - Firefox - SeaMonkey - Flock - Thunderbird
Jay Garcia
--- Original Message ---
> ... and I do see that option when I am composing a message in Tb3.1.6,
> but I don't believe that it will work for confirming received messages
> and I don't believe that 'any' or 'nearly all' servers support it.
IIRC, DSN was not part of Sendmail and had to be patched into the
sendmail.mc file. DSN was added to version 8.7(?) I believe.
Mike Easter
>> What is the difference between the TB's email options "return receipt"
>> and "Delivery Status notification"?
>
> As to what the recipient receives, apparently no difference:
>
> I just sent one of each (checking off only one option each time)
> to my Gmail account, and then compared the received "source" of both.
My Win Tb 3.1.6 test did not give the same results.
> Both messages contain the same single header
> requesting a voluntary acknowledgment from the recipient:
>
> Disposition-Notification-To: My Sending Name <m...@sending.address>
Using Tools/ Options when composing a message:
Check 'return receipt' gives me a 'DNT' header.
Check 'DSN' gives me nothing, no DSN header, no DNT header.
The DSN test was performed twice.
Where DNT = Disposition-Notification-To
and DSN = Delivery-Status-Notification
Examination of the respective about:config sections for return_receipt
(5 items) and dsn (6 items) was not helpful.
I made a mistaken interpretation of what Tbird was saying about return
receipts earlier and assumed that it - in default mode - was using the
same kind of RRT behavior as OE, where RRT is Return-Receipt-To.
(Where mistaken interpretation means completely ignored what was written
at
http://kb.mozillazine.org/Figuring_out_whether_the_recipient_read_your_message#Return_Receipts
about MDN Message Disposition Notification which = DNT in the default
mode, which could be changed to RRT if one were communicating with OEs.)
--
Mike Easter
John H Meyers
JHM:
> I just sent one of each (checking off only one option each time)
> to my Gmail account, and then compared the received "source" of both.
> Both messages contain the same single header
> requesting a voluntary acknowledgment from the recipient:
> Disposition-Notification-To: My Sending Name <m...@sending.address>
Mike Easter:
> My Win Tb 3.1.6 test did not give the same results.
> Using Tools/ Options when composing a message
Do you mean just "Options" in the "write message" window,
under which "Return Receipt" and "Delivery Status Notification"
may be individually check-marked or not?
> Check 'return receipt' gives me a 'DNT' header.
> Check 'DSN' gives me nothing, no DSN header, no DNT header.
YMMV then; I did "view original" on each in my Gmail.
> Examination of the respective about:config sections for return_receipt
> (5 items) and dsn (6 items) was not helpful.
Are you referring to per-account "Return Receipts" settings
which indicate how to handle _incoming_ requests
for you to acknowledge "Disposition-Notification-To," per account?
Looking hastily through my global Tools > Options,
I did not spot anything global relating to RR or DSN --
do you see something there? Or any global setting
that's about _sending out_ "DNT" requests?
--
John H Meyers
> Mike Easter:
>> My Win Tb 3.1.6 test did not give the same results.
>> Check 'return receipt' gives me a 'DNT' header.
>> Check 'DSN' gives me nothing, no DSN header, no DNT header.
I forgot to add that there's no such thing as a "DSN header"
on outgoing requests; rather, it's something that's negotiated
in SMTP protocol, by commands which are no part of message content.
Repeating the RFC references:
"Delivery Status Notification service extension" to SMTP:
http://tools.ietf.org/html/rfc3461#section-3
http://tools.ietf.org/html/rfc3461#section-4.1
--
John H Meyers
>> What is the difference between the TB's email options "return receipt"
>> and "Delivery Status notification"?
> The first is for the receiving mail client and its user. Usually (i.e.
> default in most mail clients) the user is being asked something along
> the lines of "the sender asked to be notified that you received this
> email. Allow?". The receipt would then be sent from the recipients mail
> client and he might see it in his "sent items" folder.
> The second is an instruction for mail servers to notify you if and when
> they were able to process the email. Please note that this is optional
> and most mail servers only ever send notifications if the email couldn't
> be delivered - regardless of what notifications you requested.
> So, receiving the second means that your email was delivered to the
> recipient's inbox while receiving the first means that the recipient
> actually opened the email.
Receiving a "Delivery Status notification" of "success" ("the second")
means only that the message was delivered to one SMTP server
en route to the recipient. This may be the very first SMTP server
to which your personal client (TB) connects, or the next server
which that first server forwards the message, and so on.
As you also noted, any server which does not implement the
"Delivery Status Notification service extension" to SMTP
will not be able to acknowledge successful forwarding,
nor will any subsequent server along the delivery route,
so it's not that simple to conclude whether or not
any message was "delivered to the recipient's inbox,"
and even the meaning of "the recipient's inbox"
is a bit cloudy -- e.g. an IMAP Inbox?
A POP mailbox? A web-only "Inbox"?
was the mail ever collected from any of those
to be listed in an "Inbox"
on an end user's mail client or web browser?
Alternative (commercial) schemes like "DidTheyReadIt"
rely instead on "web bugs," and even, in the case of this vendor,
on a "web bug" which never stops receiving data
for as long as the message remains open
(if, and only if, images in the message are allowed
to be downloaded from the internet at that time):
http://www.oreillynet.com/onlamp/blog/2004/06/more_on_didtheyreaditcom.html
http://email.about.com/od/windowsreturnreceipts/gr/didtheyreadit.htm
Emails with links to click to view things may rely on unique IDs
within those URLs to identify not only your reading the individual email,
but what was clicked in it, and of course some images may always be used
by advertisers to keep tabs on whether you opened the emails at all.
--
Mike Easter
> Mike Easter wrote:
>
> JHM:
>> I just sent one of each (checking off only one option each time)
>> to my Gmail account, and then compared the received "source" of both.
>> Both messages contain the same single header
>> requesting a voluntary acknowledgment from the recipient:
>> Disposition-Notification-To: My Sending Name <m...@sending.address>
>
> Mike Easter:
>> My Win Tb 3.1.6 test did not give the same results.
>> Using Tools/ Options when composing a message
>
> Do you mean just "Options" in the "write message" window,
> under which "Return Receipt" and "Delivery Status Notification"
> may be individually check-marked or not?
Yes I misspoke. Options menu in Write, not the Tools menu.
>> Check 'return receipt' gives me a 'DNT' header.
>> Check 'DSN' gives me nothing, no DSN header, no DNT header.
>
> YMMV then; I did "view original" on each in my Gmail.
>
>> Examination of the respective about:config sections for return_receipt
>> (5 items) and dsn (6 items) was not helpful.
>
> Are you referring to per-account "Return Receipts" settings
> which indicate how to handle _incoming_ requests
> for you to acknowledge "Disposition-Notification-To," per account?
I was referring to about:config filter on return_receipt gives 5 items
and filter on dsn gives 6 items for various purposes, none of which
sounded like they would be helpful.
> Looking hastily through my global Tools > Options,
> I did not spot anything global relating to RR or DSN --
> do you see something there? Or any global setting
> that's about _sending out_ "DNT" requests?
No.
It sounds like the developers don't have Tbird3 configured correctly yet
in the DSN header business.
You are posting with 3.0.10 and you report that DSN gives you a DNT
instead of a DSN; that is, both Return receipt and DSN config give you a
DNT for your 3.0.10.
I was testing a 3.1.6 and I report/find that DSN gives me nothing
instead of a DSN. In both cases 3.0 and 3.1 Return receipt works
correctly, which RR has been present since at least the Tb2 I am using here.
So it sounds like your 3.0.x is misbehaving about DSN in one way, while
my 3.1.x is misbehaving about DSN in another way, which DSN is a new
function in Tb3.
Since observing the 'freaky' misbehavior about Tb3 when Win sticky keys
is enabled, I even did a separate test with sticky keys disabled - no
difference.
--
Mike Easter
Mike Easter
I've read these rfc 3461 sections now and I have logged the smtp
transaction with the earthlink server to try to determine whether or not
there is any difference in the transaction between a Tb 3.1.6 with DSN
enabled from a Tb 3.1.6 without DSN enabled - since I now understand
that the RFC doesn't say anything about headers.
section 3 above seems to say to me that the client says EHLO and if the
server is going to support DSN, then in the 250 response there is
mention of DSN. But that section 3 gives no clue to how Tbird would EHLO
differently with or without enabling DSN.
section 4.1 above seems to say to me that when the client is issuing the
RCPT command and intends DSN, that the RCPT should include the various
possibilities of NEVER, SUCCESS, FAILURE, and/or DELAY
The bottom line here is that I can't see any difference in the Tbird
part of the transaction with DSN enabled from DSN not enabled. So,
whether or not any servers are supporting DSN is immaterial if there is
no method by which Tbird is communicating that it has any interest in
DSN. Sending a EHLO to the server is not sufficient to communicate anything.
--
Mike Easter
John H Meyers
> So it sounds like your 3.0.x is misbehaving about DSN in one way...
It isn't misbehaving in any way, IMO.
--
John H Meyers
>>> Examination of the respective about:config sections for return_receipt
>>> (5 items) and dsn (6 items) was not helpful.
> I was referring to about:config filter on return_receipt gives 5 items
> and filter on dsn gives 6 items for various purposes, none of which
> sounded like they would be helpful.
A list of option names (and some explanations) may be found on:
http://kb.mozillazine.org/Mail_and_news_settings
--
John H Meyers
>> RFC references:
>> "Delivery Status Notification service extension" to SMTP:
>> http://tools.ietf.org/html/rfc3461#section-3
>> http://tools.ietf.org/html/rfc3461#section-4.1
> I've read these rfc 3461 sections now and I have logged the smtp
> transaction with the earthlink server to try to determine whether or not
> there is any difference in the transaction between a Tb 3.1.6 with DSN
> enabled from a Tb 3.1.6 without DSN enabled - since I now understand
> that the RFC doesn't say anything about headers.
>
> section 3 above seems to say to me that the client says EHLO and if the
> server is going to support DSN, then in the 250 response there is
> mention of DSN. But that section 3 gives no clue to how Tbird would EHLO
> differently with or without enabling DSN.
There's no "EHLO differently" -- just doing EHLO invites servers
to use more enhanced protocol features, and the response _by the server_
to EHLO will include the DSN capability, if the server offers it, e.g.:
telnet mail.my.domain 25 [contact mail server on port 25]
220 mail.my.domain ESMTP Sendmail ... [server supports ESMTP]
EHLO mail.example.com
250-mail.my.domain Hello [xx.xx.xx.xx], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE 30000000
250-DSN [===== DSN capability =====]
250 HELP [last response line is without "-"]
> section 4.1 above seems to say to me that when the client is issuing the
> RCPT command and intends DSN, that the RCPT should include the various
> possibilities of NEVER, SUCCESS, FAILURE, and/or DELAY
[continuing the SMTP session via telnet]
MAIL FROM: <m...@example.com>
250 2.1.0 <m...@example.com>... Sender ok
RCPT TO: <y...@example.net> NOTIFY=SUCCESS,FAILURE,DELAY
250 2.1.5 <y...@example.net>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
[headers and message]
.
250 2.0.0 oAE8IiIf003832 Message accepted for delivery
QUIT
--
Mike Easter
> Mike Easter wrote:
>
>> So it sounds like your 3.0.x is misbehaving about DSN in one way...
>
> It isn't misbehaving in any way, IMO.
I understood you to say earlier in this thread that when you checked DSN
and unchecked RR, that Tbird put a DNT header, the same as it did when
you checked RR and unchecked DSN. DSN deliverystatusnotification; RR
returnreceipt; DNT deliverynotificationto.
Message-ID: <4CD96ECC...@nomail.invalid>
Date: Tue, 09 Nov 2010 09:54:52 -0600
From: John H Meyers <jhme...@nomail.invalid>
> I just sent one of each (checking off only one option each time)
> to my Gmail account, and then compared the received "source" of both.
>
> Aside from time stamp differences, both messages are identical upon receipt.
>
> Both messages contain the same single header
> requesting a voluntary acknowledgment from the recipient:
>
> Disposition-Notification-To: My Sending Name <m...@sending.address>
--
Mike Easter
Mike Easter
> Mike Easter wrote:
>> I've read these rfc 3461 sections now and I have logged the smtp
>> transaction with the earthlink server to try to determine whether or not
>> there is any difference in the transaction between a Tb 3.1.6 with DSN
>> enabled from a Tb 3.1.6 without DSN enabled - since I now understand
>> that the RFC doesn't say anything about headers.
>>
>> section 3 above seems to say to me that the client says EHLO and if the
>> server is going to support DSN, then in the 250 response there is
>> mention of DSN. But that section 3 gives no clue to how Tbird would EHLO
>> differently with or without enabling DSN.
>
> There's no "EHLO differently" -- just doing EHLO invites servers
> to use more enhanced protocol features, and the response _by the server_
> to EHLO will include the DSN capability, if the server offers it, e.g.:
OK.
> EHLO mail.example.com
> 250-DSN [===== DSN capability =====]
My EL earthlink does not give a DSN response in that 250 conversation,
just...
SIZE 14680064
PIPELINING
AUTH PLAIN LOGIN CRAM-MD5
HELP
>> section 4.1 above seems to say to me that when the client is issuing the
>> RCPT command and intends DSN, that the RCPT should include the various
>> possibilities of NEVER, SUCCESS, FAILURE, and/or DELAY
> RCPT TO: <y...@example.net> NOTIFY=SUCCESS,FAILURE,DELAY
Just the plain vanilla checking DSN in Tbird does not result in Tbird
expressing a RCPT TO notify=successfailuredelay
That is, if I check DSN or if I don't check DSN, Tbird's RCPT TO is
exactly the same, no notify= anything, just the To address.
So apparently, if one is going to *actually* expect any kind of notify,
they must configure that notify= successfailuredelay somewhere else
other than just checking DSN in the Options, or else Tbird only gives
that notify= business if the server has given a DSN in the 250.
I'll have to see if I can find a server which answers DSN to find out if
Tbird actually does that.
My about:config is configured for all 3 successfailuredelay to be true
in its mail.dsn.request_xxx sections.
--
Mike Easter
John H Meyers
> I understood you to say earlier in this thread that when you checked DSN
> and unchecked RR, that Tbird put a DNT header, the same as it did when
> you checked RR and unchecked DSN.
I just tried again, and got no DNT header, so perhaps I erred earlier
(looked at the the same incoming message twice? Sent from an account
which said "use global RR" prefs?)
I also just checked my global "always RR" option, and it's now off.
Sorry for whatever mistake -- all's as expected, so far as appears now.
--
Mike Easter
>Mike Easter wrote:
>
>> I understood you to say earlier in this thread
> Sorry for whatever mistake -- all's as expected, so far as appears now.
Okeydokeytnx.
--
Mike Easter
John H Meyers
> My EL earthlink does not give a DSN response in that 250 conversation,
> just...
>
> SIZE 14680064
> PIPELINING
> AUTH PLAIN LOGIN CRAM-MD5
> HELP
Then this SMTP server won't support DSN,
which means it won't support NOTIFY in "RCPT TO"
> if I check DSN or if I don't check DSN, Tbird's RCPT TO is
> exactly the same, no notify= anything, just the To address.
Since your server won't support DSN,
it seems correct for TB not to try to use NOTIFY.
It's the same if you try to demand that TB "authenticate" (or use TLS/SSL)
to a server which doesn't support it -- you can't force a server
to do what it isn't configured (or capable) to do.
> or else Tbird only gives that notify= business [only] if the server
> has [included keyword DSN in the response from server after EHLO]
That's how things should be.
> I'll have to see if I can find a server which [advertises DSN capability]
> to find out if Tbird actually does that.
Exactly.
Verizon users could try outgoing.verizon.net on port 587.
If you have no restrictions on outgoing port 25,
you can try all the world's "MX" servers :)
--