Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Return receipt and Delivery status notification
978 views
Skip to first unread message
Jeff Layman
Aug 14, 2013, 4:22:27 AM8/14/13
to
Win7HPx64. TB17.0.8
Have sent a couple of test emails (one to myself) with "return receipt"
and "delivery status notification" checked.
AFAICS these have done nothing. I didn't get the confirmation that
email had been delivered on sending it, and in the email I sent to
myself there was no receipt request.
Anyone else seen this?
--
Jeff
Have sent a couple of test emails (one to myself) with "return receipt"
and "delivery status notification" checked.
AFAICS these have done nothing. I didn't get the confirmation that
email had been delivered on sending it, and in the email I sent to
myself there was no receipt request.
Anyone else seen this?
--
Jeff
Mike Easter
Aug 14, 2013, 10:13:25 AM8/14/13
to
Jeff Layman wrote:
> Win7HPx64. TB17.0.8
>
> Have sent a couple of test emails (one to myself) with "return receipt"
> and "delivery status notification" checked.
Mostly that stuff doesn't serve the purpose you would like because
> Win7HPx64. TB17.0.8
>
> Have sent a couple of test emails (one to myself) with "return receipt"
> and "delivery status notification" checked.
'other entities' such as the recipient or the server are in control of
part of the process, not you.
> AFAICS these have done nothing. I didn't get the confirmation that
> email had been delivered on sending it, and in the email I sent to
> myself there was no receipt request.
Disposition-Notification-To and if you will examine the mail you
received which you sent yourself with the receipt request, you should
find that header.
How Tb handles its behavior toward you the recipient when it receives an
email with that header depends on the settings in the mail account in
the return receipts section. The default setting is to use the global
preferences which can be configured to never send return receipts or to
ask or to always send return receipts for particular kinds of addressing.
In the past I have configured to never send return receipts; now I am
configured to ask whether to send return receipts. If you are
configured for never, you aren't going to be asked even though the
header appears in the received mail. Likewise if an other recipient
receives such a mail you might or might not get a return receipt
depending on how the recipient is configured - what the recipient's mail
agent 'wants to do' with that header and/or what the recipient hirself
wants to do about it.
In my opinion, the return receipt business (or its facsimile) should be
a courtesy which is worked out between the sender and the recipient and
not configured into their mail agents. For example, the
sender/recipient could have an agreement with each other that when a
mail is received that the recipient hits reply and sends an empty or
nearly empty mail message with the same subject (and maybe top line)
indicating the recipient is in receipt of the message.
Regards the delivery status notification; that is a server response when
it receives such a message to put into the recipient's mailbox, which
isn't exactly the same as a recipient opening the mail. The moz kb
article says that servers support that header, but it is my opinion
(based on not much) that servers don't do that extra little bit of work,
that the server software is configure to ignore it even though the
server software could be configured to respond to it. (And for good
reason, see spam below.)
So, since (I believe) servers and recipients don't 'routinely' behave in
the way you might like, I believe that you and the recipient should have
some kind of agreement between you about your being notified when the
recipient gets your mail.
Incidentally, it is a big spam no-no for a recipient to be configured to
always send return receipts, because that functions to the spam system
as an address confirmation and spam-reader status for any such spams
that are opened as would be the delivery status notification by the
server confirming the spammed email address.
--
Mike Easter
Mike Easter
Aug 14, 2013, 10:37:38 AM8/14/13
to
Mike Easter wrote:
> How Tb handles its behavior toward you the recipient when it receives an
> email with that header depends on the settings in the mail account in
> the return receipts section. The default setting is to use the global
> preferences which can be configured to never send return receipts or to
> ask or to always send return receipts for particular kinds of addressing.
The global settings can also be accessed from the preferences/options
> How Tb handles its behavior toward you the recipient when it receives an
> email with that header depends on the settings in the mail account in
> the return receipts section. The default setting is to use the global
> preferences which can be configured to never send return receipts or to
> ask or to always send return receipts for particular kinds of addressing.
advanced section/ general tab/ return receipts button.
--
Mike Easter
Jeff Layman
Aug 14, 2013, 2:25:40 PM8/14/13
to
In reply to some of the points raised:
There is a header for Disposition-Notification-To in the email I received.
"Return Receipts" is configured as follows:
When sending messages always request a return receipt - unchecked
When a receipt arrives - leave it in my inbox
When I receive a request for a return receipt - allow for some messages
(all "Ask me")
I haven't changed these (since I started using TB about three years ago).
I am sure these were working a few months ago, and I used DSN and RR
successfully on a few emails. Other than possible changes to TB, the
main change since that time is that my ISP went from POP/SMTP to IMAP,
but I can't remember if I was using DSN or RR after the change or not.
Any reason that IMAP might behave differently?
This all came about because I sent a relative an email and got no reply.
When I saw him he said that his mail (from his own registered domain)
was being blocked by my ISP, probably because it had been spoofed by
spammers. Unfortunately my ISP didn't tell me they were blocking his
mail. He gave me a completely new address to try (not related to the
previous domain), and I thought it best to check if my mail was getting
through ok to him using DSN, and a reply would get through from him
using RR.
I haven't checked yet to see if he did receive my mail or not, but if he
didn't I wouldn't know if DSN and/or RR aren't working.
--
Jeff
Mike Easter
Aug 14, 2013, 3:17:20 PM8/14/13
to
Jeff Layman wrote:
> "Return Receipts" is configured as follows:
> When sending messages always request a return receipt - unchecked
> When a receipt arrives - leave it in my inbox
> When I receive a request for a return receipt - allow for some messages
> (all "Ask me")
Then Tb should have asked you unless it is trying to be an extra smart
black box and not ask you about a return receipt if the mail is from you
and to you like a test mail - unless you used an alternate address.
> I haven't changed these (since I started using TB about three years ago).
>
> I am sure these were working a few months ago, and I used DSN and RR
> successfully on a few emails. Other than possible changes to TB, the
> main change since that time is that my ISP went from POP/SMTP to IMAP,
> but I can't remember if I was using DSN or RR after the change or not.
> Any reason that IMAP might behave differently?
I seem to recall that gmail's IMAP works differently in some way on
mails addressed to yourself.
> This all came about because I sent a relative an email and got no
> reply. When I saw him he said that his mail (from his own registered
> domain) was being blocked by my ISP, probably because it had been
> spoofed by spammers. Unfortunately my ISP didn't tell me they were
> blocking his mail.
One would need to know exactly what he meant by 'blocked'.
The ideal way for mail to be 'blocked' by a server is for it to be
properly rejected including terse explanation such as blocklist during
the transaction, thereby the sending server knows what is wrong with his
server's listing and is able to take some steps to fix whatever is
causing the problem.
The absolute worst way for mail to be blocked by a server is for it to
be dropped on the floor -- accepted for delivery and then something or
other bad being done with it such as nothing/discarded -or- accepted for
delivery but instead autoresponding to the email's From with some kind
of non-delivery new mail sometimes referred to as a soft bounce.
If the former, he would be receiving the hard bounce information and if
he were paying attention to what so bounced (was rejected) and if there
were a return receipt which his agent sent, then he would know what he
didn't successfully send to you -- not be in the dark about it.
If he were in a worst way situation because of your having an ISP which
is improperly handling its mail server (accepting instead of rejecting
blocklisted mail) then he might not know much.
> He gave me a completely new address to try (not related to the
> previous domain), and I thought it best to check if my mail was
> getting through ok to him using DSN, and a reply would get through
> from him using RR.
Except now you know that I think/say/opine that servers don't always do
the DSN business.
> I haven't checked yet to see if he did receive my mail or not, but if
> he didn't I wouldn't know if DSN and/or RR aren't working.
I think that via whatever channel is working consistently for your
communication with him that you should establish a 'routine' such as I
described; whenever he receives an email from you he echoes its receipt
with some kind of reply signal. If the transmission problem/disturbance
is only one-way, it wouldn't be necessary for you to echo his mail echo,
but if it is both ways it can become problematic to decide when to echo
the echoes and when to not.
--
Mike Easter
> Mike Easter wrote:
>> In my opinion, the return receipt business (or its facsimile) should be
>> a courtesy which is worked out between the sender and the recipient and
>> not configured into their mail agents.
>> In my opinion, the return receipt business (or its facsimile) should be
>> a courtesy which is worked out between the sender and the recipient and
>> not configured into their mail agents.
>> article says that servers support that header, but it is my opinion
>> (based on not much) that servers don't do that extra little bit of work,
>> (based on not much) that servers don't do that extra little bit of work,
> In reply to some of the points raised:
> There is a header for Disposition-Notification-To in the email I received.
So you are properly sending the header.
> There is a header for Disposition-Notification-To in the email I received.
> "Return Receipts" is configured as follows:
> When sending messages always request a return receipt - unchecked
> When a receipt arrives - leave it in my inbox
> When I receive a request for a return receipt - allow for some messages
> (all "Ask me")
black box and not ask you about a return receipt if the mail is from you
and to you like a test mail - unless you used an alternate address.
> I haven't changed these (since I started using TB about three years ago).
>
> I am sure these were working a few months ago, and I used DSN and RR
> successfully on a few emails. Other than possible changes to TB, the
> main change since that time is that my ISP went from POP/SMTP to IMAP,
> but I can't remember if I was using DSN or RR after the change or not.
> Any reason that IMAP might behave differently?
mails addressed to yourself.
> This all came about because I sent a relative an email and got no
> reply. When I saw him he said that his mail (from his own registered
> domain) was being blocked by my ISP, probably because it had been
> spoofed by spammers. Unfortunately my ISP didn't tell me they were
> blocking his mail.
The ideal way for mail to be 'blocked' by a server is for it to be
properly rejected including terse explanation such as blocklist during
the transaction, thereby the sending server knows what is wrong with his
server's listing and is able to take some steps to fix whatever is
causing the problem.
The absolute worst way for mail to be blocked by a server is for it to
be dropped on the floor -- accepted for delivery and then something or
other bad being done with it such as nothing/discarded -or- accepted for
delivery but instead autoresponding to the email's From with some kind
of non-delivery new mail sometimes referred to as a soft bounce.
If the former, he would be receiving the hard bounce information and if
he were paying attention to what so bounced (was rejected) and if there
were a return receipt which his agent sent, then he would know what he
didn't successfully send to you -- not be in the dark about it.
If he were in a worst way situation because of your having an ISP which
is improperly handling its mail server (accepting instead of rejecting
blocklisted mail) then he might not know much.
> He gave me a completely new address to try (not related to the
> previous domain), and I thought it best to check if my mail was
> getting through ok to him using DSN, and a reply would get through
> from him using RR.
the DSN business.
> I haven't checked yet to see if he did receive my mail or not, but if
> he didn't I wouldn't know if DSN and/or RR aren't working.
communication with him that you should establish a 'routine' such as I
described; whenever he receives an email from you he echoes its receipt
with some kind of reply signal. If the transmission problem/disturbance
is only one-way, it wouldn't be necessary for you to echo his mail echo,
but if it is both ways it can become problematic to decide when to echo
the echoes and when to not.
--
Mike Easter
Dave Royal
Aug 14, 2013, 3:23:08 PM8/14/13
to
On Wed, 14 Aug 2013 09:22:27 +0100, Jeff Layman wrote:
> Win7HPx64. TB17.0.8
>
> Have sent a couple of test emails (one to myself) with "return receipt"
> and "delivery status notification" checked.
Unless it's changed in the last year or so, TB ignores read receipt
> Win7HPx64. TB17.0.8
>
> Have sent a couple of test emails (one to myself) with "return receipt"
> and "delivery status notification" checked.
requests that come from the same address - i.e. that you send to yourself.
--
(Remove any numerics from my email address.)
Jeff Layman
Aug 14, 2013, 6:09:59 PM8/14/13
to
On 14/08/2013 20:17, Mike Easter wrote:
> Jeff Layman wrote:
>
> Jeff Layman wrote:
>
>> I haven't checked yet to see if he did receive my mail or not, but if
>> he didn't I wouldn't know if DSN and/or RR aren't working.
>
> I think that via whatever channel is working consistently for your
> communication with him that you should establish a 'routine' such as I
> described; whenever he receives an email from you he echoes its receipt
> with some kind of reply signal. If the transmission problem/disturbance
> is only one-way, it wouldn't be necessary for you to echo his mail echo,
> but if it is both ways it can become problematic to decide when to echo
> the echoes and when to not.
Well, he did receive the email, but still no DSN or RR.
>> he didn't I wouldn't know if DSN and/or RR aren't working.
>
> I think that via whatever channel is working consistently for your
> communication with him that you should establish a 'routine' such as I
> described; whenever he receives an email from you he echoes its receipt
> with some kind of reply signal. If the transmission problem/disturbance
> is only one-way, it wouldn't be necessary for you to echo his mail echo,
> but if it is both ways it can become problematic to decide when to echo
> the echoes and when to not.
Out of interest I just sent an email to myself using an old version of
Windows Live Mail, requesting a "read receipt" (I don't think WLM has an
equivalent to DSN, so I couldn't try that).
No problem - I got the "Read receipt requested" message box as soon as I
opened it to read in WLM. It didn't appear when I opened the email in
TB. The "Disposition-Notification-To" header was exactly the same as
the one sent by TB when I tried that earlier.
Is it a bug (or bugs)? Is TB not reading (and/or sending) the read request?
--
Jeff
Dave Royal
Aug 15, 2013, 3:59:45 AM8/15/13
to
On Wed, 14 Aug 2013 23:09:59 +0100, Jeff Layman wrote:
>
> Is it a bug (or bugs)? Is TB not reading (and/or sending) the read
> request?
I've investigated this in the past. It's not a bug, it's a feature. It
>
> Is it a bug (or bugs)? Is TB not reading (and/or sending) the read
> request?
makes sense - why would you want to send yourself a read receipt?
Jeff Layman
Aug 15, 2013, 6:39:19 AM8/15/13
to
On 15/08/2013 08:59, Dave Royal wrote:
> On Wed, 14 Aug 2013 23:09:59 +0100, Jeff Layman wrote:
>
>>
>> Is it a bug (or bugs)? Is TB not reading (and/or sending) the read
>> request?
>
> I've investigated this in the past. It's not a bug, it's a feature. It
> makes sense - why would you want to send yourself a read receipt?
To check that it's working. If Delivery Status Notification and Return
> On Wed, 14 Aug 2013 23:09:59 +0100, Jeff Layman wrote:
>
>>
>> Is it a bug (or bugs)? Is TB not reading (and/or sending) the read
>> request?
>
> I've investigated this in the past. It's not a bug, it's a feature. It
> makes sense - why would you want to send yourself a read receipt?
Receipt are not working, you would not know if an email got through to
the recipient. It might be important to know that somebody received the
email (and opened it - whether they read it or not).
If I want to stop emails to myself (eg spammers spoofing my address and
sending me mail apparently from my address) it's not exactly difficult
to set up a filter. If it is a TB "feetcha" it's one I can do without.
It would be useful to be able to change it in about:config, but I
doubt that it's there - and even if it is what the preference name would be.
--
Jeff
0 new messages