1180209 - Since the update of Thunderbird 31.7.0 to 38.0.1 I can not send approval e-mail commands to majordomo (using mail.compose.other.header)

Status: RESOLVED WORKSFORME

(Thunderbird :: Untriaged, defect)

Description

[zivi]

Attachment: screenshots.zip

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

Steps to reproduce:

I updated Thunderbird from 31.7.0 to 38.0.1


Actual results:

I can not send e-mails to our Hoststar e-mail distribution system "Marjordomo" with downgrade to 31.7.0 it works again. Only an E-Mail with empty subject and empty receiver will be sent. 
I think this is A Bug in Thunderbird.. I called the Hoststar Support and they told me nothing changed in their Server-System. The E-Mail distribution system "Marjordomo" is an external application and will not be supported.


Expected results:

please fix it.

Comment 1

[mherger]

I'm seeing the same (mailman in my case). The messages stored in the Sent folder lack any header information. 

Here's what I posted to the Thunderbird support site (https://support.mozilla.org/en-US/questions/1076053):

IMHO this is a problem starting with version 38 (I didn't test any beta versions). I don't see this with 31.8.

I'm subscribed to some mailing lists (mailman). Sometimes when I try to respond to a message, my outgoing message would be invalid, lack of subject line and other headers. Mailman would refuse to process the message, obviously. Instead I'd get this message back:

"Your mail to 'XYZ' with the subject

   (no subject)
Is being held until the list moderator can review it for approval.

The reason it is being held:

   Message has implicit destination
Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL:"

Checking the message in the sent folder would show it without any header information (see screenshot).

This does not happen with all messages or mailing lists. Unfortunately I haven't found a rule. But if you have me precise step-by-step instructions I could even investigate on the mailman host.

I have three Mac computers (2x Yosemite, 1x El Capitan). I only noticed the issue on one of them, until I realized it was the only one running Thunderbird 38.1. The others still were on 31.8. I then updated one of the latter to the latest 38.1 and immediately experienced the same issue. Went back to 31.8 on all machines, and I was able to send my mails as before again.

Comment 2

[mherger]

FWIW: here's all the source code Thunderbird shows me for one such mail.

8<---------------------------------------------------------------------

From - Wed Aug 05 14:07:09 2015
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00800000
X-Mozilla-Keys:                                                                                 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

> Strange situation. Has anybody tried installing Windows 10, DISABLING
> User Account Control, and then installing LMS 7.9?

I've been testing with a plain installation, no tweaks applied 
whatsoever. Would you expect disabled UAC to cause _more_ problems or less?

-- 

Michael

Comment 3

[mherger]

FWIW: just happened again in 38.2.0. Back to v31.

Comment 4

[Wayne Mery (:wsmwk)]

is ths from jsmime / or we don't know what caused the regression?

Comment 5

[Jorg K (CEST = GMT+2)]

As per the dependents added after comment #: bug 1250376 and bug 1260073.

Comment 6

[Jorg K (CEST = GMT+2)]

As per the dependents added after comment #3: bug 1250376 and bug 1260073.

Comment 8

[Alfred Peters [:infofrommozilla]]

The Problem is caused by:
https://dxr.mozilla.org/comm-central/rev/2a29ee0adb310b54a6a2df72034953fed8f2b043/comm/mailnews/mime/jsmime/jsmime.js#167

// From RFC 5536:
addHeader("Approved", parseAddress, writeAddress);

This requires the Approved header to be an email address.

This is correct for newsgroup posts as described in RFC 5536:

https://www.rfc-editor.org/rfc/rfc5536.html#section-3.2.1

   The Approved header field indicates the mailing addresses (and
   possibly the full names) of the persons or entities approving the
   article for posting.  Its principal uses are in moderated articles
   and in group control messages; see [RFC5537].

   approved        =  "Approved:" SP mailbox-list CRLF

However, it is wrong for emails to mailing lists, since there the header must contain the required password.

Comment 9

[nugatritter]

Does this mean that we will not be able to use our Majordomo email list provider in the future?

Comment 10

[Alfred Peters [:infofrommozilla]]

(In reply to nugatritter from comment #9)

Does this mean that we will not be able to use our Majordomo email list provider in the future?

What do you mean by "will not"? this bug is about TB38?

So does it actually work for you? Which TB?

I've no experience with Majordomo.
What are the requirements for using them?

Bug 1658890 is about setting custom headers in general. This is broken in current TB78 but should be fixed in the next sub release (TB78.3?).
Then this Bug should be fixed also.
It would be nice, if someone could test it then.

Comment 11

[nugatritter]

Actually TB 68.12.0 works fine but TB 78.2.1 don't.
The requirements for using Majordomo is an additional header entry called "approved".
I'll test next release with Majordomo and post results here.

Comment 12

[Magnus Melin [:mkmelin]]

I think the approved header for majordomo is not ultimately a requirement. The more "standard" way is to add Approved: on the first line of the message. At least this is what the documentation I've found seem to say.

Comment 13

[nugatritter]

I've just tested this, and you're right.
Adding "Approved: ListPassword" on the first line of the message works fine.
Thank you for this alternative way.

Comment 14

[Magnus Melin [:mkmelin]]

It's a bit wrong of them to use a non X- prefixed header for special purposes :/

Comment 15

[Wayne Mery (:wsmwk)]

Should this be marked confirmed?

Comment 16

[Alfred Peters [:infofrommozilla]]

(In reply to Wayne Mery (:wsmwk) from comment #15)

Should this be marked confirmed?

It should be fixed already - see Comment #10.

Once someone with a current TB (TB78.2.1 is too old) confirms it works, we can close the bug as dupe of Bug 1658890.

Comment 17

[Magnus Melin [:mkmelin]]

On trunk this now works yes.
Set mail.compose.other.header to "Approved" (or e.g. "Approved,X-Foo") and then you can select the header in the composition area.