1299430 - Delivery status notification (DSN) not working for second non-default identity

Status: RESOLVED INCOMPLETE

(MailNews Core :: Networking: SMTP, defect)

Description

[support]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

Steps to reproduce:

1: create an email account
2: add an alternative identities for that account
3: send an email using the new identity to an non existing address i.e. [e-mail]


Actual results:

no dsn receipt return


Expected results:

I expect Thunderbird ask for dsn receipt to the server. In fact if I send an email without using the identity with my first address it works. Moreover if I choose the option to customize the from field when I compose the email it works as expected

Comment 1

[Jorg K (CEST = GMT+2)]

Magnus, do you know how this is supposed to work?
If the user asks for a read receipt, we transmit Disposition-Notification-To: as a header.

If the user asks for a delivery receipt (DSN) from its outgoing SMTP server (or the recipient's MTA?), that is, the SMTP server (or recipient's MTA?) confirms that the message was delivered, the Return-Receipt-To: header is used. However, I don't see this header stored anywhere, so how is this supposed to work? Only sent with the message but not stored? It's stored in the X-Mozilla-Draft-Info: header as receipt=1; DSN=1;

I send all my mail with requesting both read and delivery receipt, but I never get a delivery receipt since my SMTP server doesn't support that.

Comment 2

[Magnus Melin [:mkmelin]]

Return-Receipt-To is just a non-standard header for return receipts.

AFAIK, for DSN, it's looking at the Return-Path, which would get get created from the SMTP MAIL FROM.

Comment 3

[support]

we tried (since we noticed the lack of the header) to force the return-path header using the mail.compose.other.header option but it didn't work either. We tried both with gmail and outlook.com services.

Comment 4

[Charles]

Just confirmed this problem after a discussion on the Thunderbird Support list.

Return Receipt adds the disposition-notification-to header, and seems to work as expected.

DSN however doesn't add the header, and does not seem to work.

I don't see the "X-Mozilla-Draft-Info: header as receipt=1; DSN=1;" header anywhere in either the Sent message in my Sent folkder, or the one received.

So, the problem appears to be that the header simply isn't getting added?

Comment 5

[Jorg K (CEST = GMT+2)]

From Google:
The delivery receipt (i.e. Return-Receipt-To) is a request for the receiving mail server to send a DSN (delivery status notification) as soon as it receives the email. The read receipt (i.e. Disposition-Notification-To) is a request for the receiving email client to send a DSN as soon as the person opens the email.

I don't think you'll see Return-Receipt-To as a header anywhere. You should test this with a server that is known to honour delivery status notification.

Or try SMTP logging. Wada, do you have more info?

Comment 6

[Charles]

Not sure I understand...

How does the email tell the server to send a DSN response, if not via a header?

Comment 7

[Jorg K (CEST = GMT+2)]

Via the protocol? No guarantee that the headers sent out are handed on by the servers. Anyway, I declare complete ignorance here. So get someone who knows or follow my suggestion: Use SMTP logging and/or a server that is known to honour the request.

Comment 8

[Jorg K (CEST = GMT+2)]

OK, I did what I suggested and used a server that is known to honour the request. This is the receipt I got:

The original message was received at Fri, 3 Mar 2017 18:11:21 +0000
from x55b386fb.dyn.telefonica.de [85.179.134.251]

   ----- The following addresses had successful delivery notifications -----
<[e-mail]>  (relayed to non-DSN-aware mailer)

   ----- Transcript of session follows -----
<[e-mail]>... relayed; expect no further notifications

However, I tried the same with a second identity, and there I didn't get the receipt, which is what this bug is about.

So I'm confirming the bug.

Comment 9

[Charles]

(In reply to Jorg K (GMT+1) from comment #7)
> Via the protocol? No guarantee that the headers sent out are handed on by
> the servers. Anyway, I declare complete ignorance here. So get someone who
> knows or follow my suggestion: Use SMTP logging and/or a server that is
> known to honour the request.

Ok, so, what does TB set for the header when requesting DSN?

As I said, in my testing, TB does not set a header - so, if it doesn't request it by adding a header, how does it request it?

Oh... maybe by including the request during the SMTP session when sending the message? If so, does that mean that there will never be any way to tell, by examining the source of a message in the Sent folder, whether a DSN was requested or not? That would at least explain why I don't see anything when looking there.

(In reply to Jorg K (GMT+1) from comment #8)
> OK, I did what I suggested and used a server that is known to honour the
> request. This is the receipt I got:
> 
> The original message was received at Fri, 3 Mar 2017 18:11:21 +0000
> from x55b386fb.dyn.telefonica.de [85.179.134.251]
> 
>    ----- The following addresses had successful delivery notifications -----
> <[e-mail]>  (relayed to non-DSN-aware mailer)
> 
>    ----- Transcript of session follows -----
> <[e-mail]>... relayed; expect no further notifications
> 
> However, I tried the same with a second identity, and there I didn't get the
> receipt, which is what this bug is about.
> 
> So I'm confirming the bug.

I tested using two of my gmail accounts - but was unable to receive a DSN sending to/from either one, using the primary Identity, so, for me, it isn't working at all - unless gmail really doesn't support DSNs.

Comment 10

[Jorg K (CEST = GMT+2)]

(In reply to Charles from comment #9)
> does that mean that there will never be any way to tell,
> by examining the source of a message in the Sent folder, whether a DSN was
> requested or not?
Yes.

I don't know how delivery status notification works, but I can confirm that it does work for the first identity and not the second as reported here.

IMHO delivery status notification is next to useless, since most servers ignore it, amongst them Google servers. In most cases you get DNS from your outgoing SMTP server that it handed the message on. Useless. Also, it's added overhead that is not provided for non-paying clients. In my web hosting package what includes e-mail hosting, the servers do *not* send delivery status notification, however, if I use the outgoing SMTP server of my local ISP, I do get it as shown in comment #8.

I kindly request to stop the discussion about delivery status notification in general. If you want to find out more, use SMTP logging with a *working* server.

Comment 11

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Adding tracking flag to document a bug reported in 1344233. Ignore.

Comment 12

[WADA:World Anti-bad-Duping Agency]

(In reply to support from comment #0)
> Steps to reproduce:
> 1: create an email account
> 2: add an alternative identities for that account
> 3: send an email using the new identity to an non existing address
> i.e. [e-mail]
> Actual results:
> no dsn receipt return

Unable to reproduce such problem using Thunderbird 45.8.0 and @yahoo.co.jp.

(0) Setting
  Yahoo! Japan account. 
  [e-mail](main identity in Tb),
  [e-mail](alias of mail_1 in Yahoo! Japan, second identity in Tb)
  smtp.yahoo.co.jp is used.
(1) Send mail with From: [e-mail], with Options/DNS checked,
    to [e-mail]
    => mail of "Failure notice" is returned.
    => The notice was held in "Bulk Mail" folder of the Yahoo! Japan IMAP account by Yahoo! Japan,
       because mail addresses are newly created ones,
       as saved in "Bulk Mail" in World Wide Yahoo!.(1) Send mail with From: [e-mail], with DNS request
(2) Send mail with From: [e-mail], with Options/DNS checked,
    to [e-mail]
    => mail of "Failure notice" is returned.
    => The notice was held in "Bulk Mail" folder of the Yahoo! Japan IMAP account by Yahoo!,
       because mail addresses are newly created ones,
       as saved in "Bulk Mail" in World Wide Yahoo!.(1) Send mail with From: [e-mail], with DNS request

Delivery Status Notofication is feature in SMTP mail transfer, and it's absolutely irrelevant to "main identity in Thunderbird" nor "non-main identity in Thunderbird".

Comment 13

[Jorg K (CEST = GMT+2)]

Please don't test the error case. Send an e-mail to a valid address hosted by a DNS aware server. I got, for example:

===
Your message was successfully delivered to the destination(s)
listed below. If the message was delivered to mailbox you will
receive no further notifications. Otherwise you may still receive
notifications of mail delivery errors from other systems.

Please direct further questions regarding this message to your e-mail
administrator.

--AOL Postmaster

<[e-mail]>: alias expanded
===

You must make sure that your local SMTP server hands on the DNS request, most free servers don't, I am in the lucky situation where I can test with such a server.

It works with the first identity but not the second, see comment #10.

Comment 14

[Wayne Mery (:wsmwk)]

Version 91 has all new smtp backend code. If you can still reproduce this issue, please file a new bug report https://bugzilla.mozilla.org/enter_bug.cgi?product=MailNews%20Core&component=Networking%3A%20SMTP