Closed Bug 1883529 Opened 8 months ago Closed 7 months ago

SMTP "AUTH GSSAPI <1st token>" will fail if the first token sent is too long

Categories

(MailNews Core :: Networking: SMTP, defect)

Product:
MailNews Core
Component:
Networking: SMTP
Version:
Thunderbird 115
Type:
defect

Tracking

(thunderbird_esr115 affected, thunderbird125 fixed)

Status:
RESOLVED FIXED
Milestone:
126 Branch
Tracking Flags:
Tracking Status
thunderbird_esr115 --- affected
thunderbird125 --- fixed

People

(Reporter: keesvanvloten, Assigned: gds)

References

Details

Attachments

(1 file)

Bug 1883529 - Avoid AUTH GSSAPI error for SMTP due to line too long. r=mkmelin
48 bytes, text/x-phabricator-request
wsmwk
: approval-comm-beta+
Details | Review

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

Tested with TB 115.8.0 (on Debian bookworm) and 115.4.3 (on WIndows 10)
TB config:
Authentication method: Kerberos / GSSAPI
Connection Security: SSL/TLS
Port: 465

Create mail message and send it

Actual results:

TB opens a dialog:

Sending of the message failed.
The Kerberos/GSSAPI ticket was not accepted by Outgoing server (SMTP)
<server-name> Please check that you are logged on in the Kerberos/GSSAPI realm.

Then TB proposes to enter a password, which it should not do, since there is a valid ticket.

There is no issue with the kerberos ticket, I can read messages over imap and "klist" shows my ticket includes "imap/<server>@<realm>" and "smtp/<server>@<realm>"

TB error console:

mailnews.smtp: Command failed: 500 Line too long; currentAction=_actionAUTH_GSSAPI SmtpClient.jsm:578:19
mailnews.send: Sending failed; The Kerberos/GSSAPI ticket was not accepted by the Outgoing server (SMTP) strauss.composers.lan. Please check that you are logged in to the Kerberos/GSSAPI realm., exitCode=2153066806, originalMsgURI= MessageSend.jsm:337:32
mailnews.smtp: Authentication failed: Socket closed

Server side logging for the failing TB session:

submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: Connection created
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: Sent: 220 mail.example.com Dovecot ready.
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: Sending replies
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: No more commands pending
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: Received new command: EHLO [192.168.1.1]
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: command EHLO: New command
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: command EHLO: Execute command
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: command EHLO: Pipeline blocked
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: command EHLO: 250 reply: Submitted
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: command EHLO: Replied
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: command EHLO: Ready to reply
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: Trigger output
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: command EHLO: Next to reply
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: Sending replies
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: command EHLO: Next to reply
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: command EHLO: Completed
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: command EHLO: Pipeline unblocked
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: Connection state reset
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: command EHLO: 250 reply: Sent: 250-mail.example.com 8BITMIME AUTH GSSAPI GSS-SPNEGO PLAIN BURL imap CHUNKING ENHANCEDSTATUSCODES SIZE PIPELINING
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: command EHLO: Finished
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: command EHLO: Destroy
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: command EHLO: 250 reply: Destroy
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: Trigger output
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: No more commands pending
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: Sending replies
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: No more commands pending
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: Client sent invalid command: Command line is too long
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: command [unknown]: Invalid command
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: command [unknown]: 500 reply: Submitted
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: command [unknown]: Replied
submission-login: Debug: smtp-server: conn 192.168.1.1:33760 [1]: command [unknown]: Ready to reply
<more output redacted>

Compared to the below curl session, the server never logs: "Received new command: AUTH GSSAPI" and instead fails with "Client sent invalid command: Command line is too long"

Expected results:

The message should have been sent.
Which it did with dovecot-submissiond 2.3.13 (part of Debian Bullseye), after the upgrade to dovecot-submissiond 2.3.19 (Bookworm) the bug arose. However when I send an email with curl and kerberos authentication it works fine on bookworm.

Curl command:
curl -v -s --login-options "AUTH=GSSAPI" -u : --url smtps://mail.example.com --mail-from "${ENVELOPE_SENDER}" --mail-rcpt "${ENVELOPE_RECIPIENT}" --upload-file $(MAIL_TEXT_FILE}

Server side logging for the curl session:

submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: Connection created
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: Sent: 220 mail.example.com Dovecot ready.
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: Sending replies
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: No more commands pending
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: Received new command: EHLO tmp98klok8m
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: command EHLO: New command
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: command EHLO: Execute command
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: command EHLO: Pipeline blocked
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: command EHLO: 250 reply: Submitted
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: command EHLO: Replied
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: command EHLO: Ready to reply
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: Trigger output
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: command EHLO: Next to reply
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: Sending replies
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: command EHLO: Next to reply
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: command EHLO: Completed
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: command EHLO: Pipeline unblocked
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: Connection state reset
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: command EHLO: 250 reply: Sent: 250-mail.example.com 8BITMIME AUTH GSSAPI GSS-SPNEGO PLAIN BURL imap CHUNKING ENHANCEDSTATUSCODES SIZE PIPELINING
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: command EHLO: Finished
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: command EHLO: Destroy
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: command EHLO: 250 reply: Destroy
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: Trigger output
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: No more commands pending
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: Sending replies
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: No more commands pending
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: Received new command: AUTH GSSAPI
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: command AUTH: New command
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: command AUTH: Execute command
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: command AUTH: Next to reply
auth: Debug: client in: AUTH#0111#011GSSAPI#011service=submission#011secured=tls#011session=4jx9aN0SCpzAqAoB#011lip=192.168.1.5#011rip=192.168.1.1#011lport=465#011rport=39946#011local_name=mail.example.com
auth: Debug: gssapi(?,192.168.1.1,<4jx9aN0SCpzAqAoB>): Obtaining credentials for submission@mail.example.com
auth: Debug: client passdb out: CONT#0111#011
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: Sent: 334 
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: Sending replies
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: command AUTH: Next to reply
submission-login: Debug: smtp-server: conn 192.168.1.1:39946 [1]: Received AUTH response: <ticket redacted>
auth: Debug: client in: CONT<hidden>
<more redacted>
<rest of session redacted>

Sorry for bold messages, I guess something in my text triggered markdown bold :-(
Another minor thing: the last few lines were not properly redacted.

Component: Untriaged → Networking: SMTP
Product: Thunderbird → MailNews Core

I have downgraded dovecot-submissiond 2.3.19 (Debian Bookworm) to dovecot-submissiond 2.3.13 (Debian Bullseye) as a temporary workaround to prevent TB being useless for the users.
As a result I could record the (now successful) smtp conversation against dovecot-submissiond 2.3.13, here is the output:

auth: Debug: auth client connected (pid=777787)
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: Connection created
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: Sent: 220 mail.example.com Dovecot ready.
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: Sending replies
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: No more commands pending
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: Received new command: EHLO [192.168.1.1]
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: command EHLO: New command
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: command EHLO: 250 reply: Submitted
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: command EHLO: Replied
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: command EHLO: Ready to reply
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: Trigger output
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: command EHLO: Next to reply
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: Sending replies
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: command EHLO: Next to reply
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: command EHLO: Completed
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: Connection state reset
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: command EHLO: 250 reply: Sent: 250-mail.example.com 8BITMIME AUTH GSSAPI GSS-SPNEGO PLAIN BURL imap CHUNKING ENHANCEDSTATUSCODES SIZE PIPELINING
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: command EHLO: Finished
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: command EHLO: Destroy
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: command EHLO: 250 reply: Destroy
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: Trigger output
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: No more commands pending
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: Sending replies
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: No more commands pending
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: Received new command: AUTH GSSAPI <ticket redacted>
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: command AUTH: New command
submission-login: Debug: smtp-server: conn 192.168.1.1:57408 [1]: command AUTH: Next to reply
auth: Debug: client in: AUTH#0111#011GSSAPI#011<redacted>
<rest of session redacted>

It shows clearly that TB is not sending AUTH GSSAPI before sending the ticket. Without that SMTP RFC says that all commands, including sasl ir, must be at most 998 bytes.
The newer dovecot-submissiond (2.3.19) actually checks that and now TB cannot use smtp+krb5 anymore :-(

Reporter Kees,
Can you provide a temporary test account on the problem dovecot server? That way I can more easily debug the problem from here. I don't currently have kerberos/gssapi setup on my dovecot server. If that's possible, you can send any credentials to me at my BMO profile address.
-gene

Kees, thanks for the quick email reply. Sound like setting up a test account is fairly complex.
But re-reading your comments, I think you are saying that TB is concatenating the "AUTH GSSAPI" and the token/ticket into the same string and sending it, causing "line too long" response from the server. From what I can tell the transaction should look more like this (just an example I found somewhere):

C: AUTH GSSAPI
S: 334
C: YIICEQYJKoZIhvcSAQICAQBuggIAMIIB/KADAgEFoQMCAQ6iBwMFACAAAACjggETYYIBDzCCAQugAwIBBaENGwtOQURBLktUSC5TRaIjMCGgAwIBAaEaMBgbBHNtdHAbEHNtdHAubmFkYS5rdGguc2Wjgc8wgcygAwIBEKEDAgEJooG/BIG8msq2xygko4Lv0Agu5pW6SEundUbFK5swuopukvx9kTidWULb/Ab490wQbtnKx3lmM3BFvNFvuUyD3zvh9PHggwz7T7eZYSCDaovIL/QZ0ismF3lZejZBSwBhgLDADQuk4nZHbbeoU9Lk+1jzsMJguNh6Ot3G6o8WLqFZoe8pi3NuxzSdjutjg3O9s/fasuSB9T85bq6oIMWGr5HHRNBNUF4x11tK3ytpsVoMNpKng3d4bY8tLgnxxLCmREakgc8wgcygAwIBEKEDAgEBooG/BIG8SPCDQwKGzJfZGg+MgqQquBiGBXA2uy/08gPE19vuTBP7XyL2H4EaVqtl71MeVxExbat/CNAK
3dMXkNqR6VHxZqb+ky8MYMDo452Z1sN6BfIsKcsy2BcYTwFJMtgdn21vTWVHtMPH3wtXPuPFGn3jigjsXiAyytXi1Y4p4Tni+ox5ndlZuqBJGeThVxyZIpCEI+5rWflxDIYVa/8CAcRUPQqoDpQIs5zkwfoPQtTdfRLdph5VxQ79N9PnvnQ=
S: 334 YGwGCSqGSIb3EgECAgIAb10wW6ADAgEFoQMCAQ+iTzBNoAMCARCiRgRE2FBXYUbT0MVIicgLYE/FKy6CcrvfQxZaoxyt05qqxJBL13kqneza/TKe5i0mjsN0Nc90KW/l4rL0eQ76vWMenaE1Lw8=
S: 334
YD8GCSqGSIb3EgECAgIBBAD/////IGqNk7Rz3+kPdzT9oYPRWnQi/ESL0p3EeQ2yNLWArrmdOzxpBwAgAAQEBAQ=
C: Using system username `jas' as authentication identity.
YD8GCSqGSIb3EgECAgIBBAD/////JhNtx+GhzYe54NY92BltbUHD6i02upmatfXUnIGrBR5vT5yuAQAgAGphcwE=
235 OK Authenticated

But it appears TB is now (and has always) sent the command like this (so the AUTH GSSAPI command is potentially much too long):

C: AUTH GSSAPI YIICEQYJKoZIhvcSAQICAQBuggIAMIIB/KADAgEFoQMCAQ6iBwMFACAAAACjggETYYIBDzCCAQugAwIBBaENGwtOQURBLktUSC5TRaIjMCGgAwIBAaEaMBgbBHNtdHAbEHNtdHAubmFkYS5rdGguc2Wjgc8wgcygAwIBEKEDAgEJooG/BIG8msq2xygko4Lv0Agu5pW6SEundUbFK5swuopukvx9kTidWULb/Ab490wQbtnKx3lmM3BFvNFvuUyD3zvh9PHggwz7T7eZYSCDaovIL/QZ0ismF3lZejZBSwBhgLDADQuk4nZHbbeoU9Lk+1jzsMJguNh6Ot3G6o8WLqFZoe8pi3NuxzSdjutjg3O9s/fasuSB9T85bq6oIMWGr5HHRNBNUF4x11tK3ytpsVoMNpKng3d4bY8tLgnxxLCmREakgc8wgcygAwIBEKEDAgEBooG/BIG8SPCDQwKGzJfZGg+MgqQquBiGBXA2uy/08gPE19vuTBP7XyL2H4EaVqtl71MeVxExbat/CNAK
3dMXkNqR6VHxZqb+ky8MYMDo452Z1sN6BfIsKcsy2BcYTwFJMtgdn21vTWVHtMPH3wtXPuPFGn3jigjsXiAyytXi1Y4p4Tni+ox5ndlZuqBJGeThVxyZIpCEI+5rWflxDIYVa/8CAcRUPQqoDpQIs5zkwfoPQtTdfRLdph5VxQ79N9PnvnQ=
S: 500 Line too long!

So TB should wait for a 334 continuation response from the server before sending the token/ticket, it seems.
I think this (https://www.mail-archive.com/postfix-users@postfix.org/msg92908.html) describes the same problem. It involves TB and posfix. The responder "Viktor" points out that the problem is with the client (TB). The reporter was able to "fix" the problem by configuring postfix to allow longer lines. Apparently that's not possible with dovecot submitter.

Anyhow, if that's what the problem is, seems like it might not be too hard to fix. I'll take a look.

Edit: The links below may work. But the links in comment 6 are probably better.

Here's a "try" build which patches the current beta, 124.0b4. All it does is send the "AUTH GSSAPI" command separately and waits for the continuation response from the server "334". Then it obtains the "token" and sends it and waits for the next response before sending the next "token".
The token(s), I assume, at some point contain the "ticket" that kerberos needs to complete the authentication.
This doesn't alter the gssapi protocol but just changes when the first "token" is sent.

For linux, here's what you can unpack and then just run the "thunderbird" executable inside:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/CbbkIJTfSJu3yJwnfHddcw/runs/0/artifacts/public/build/target.tar.bz2

If you want to run the window64 version with the same fix, here's the installer:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/SoHbOXnHRlmLnPS0VJ9BCA/runs/0/artifacts/public/build/install/sea/target.installer.exe

For reference, here's the complete "try" build:
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=90adfb4900ab7e2deafad634e1712abaa09859d6
and the patch can be seen here:
https://hg.mozilla.org/try-comm-central/rev/90adfb4900ab7e2deafad634e1712abaa09859d6

Anyhow, I think this may fix the problem, but not sure. Let me know if this makes a difference.
Finally, when you run this it will show as "Daily" but Help|About TB should show 124.0b4 beta version.

Looks like the same bug was reported (maybe as just a potential problem, not sure) about 6 years ago. Re: bug 1485724
This was with c++ SMTP code still in effect and c++ handled the GSSAPI tokens the same way.
That bug could probably be marked as a duplicate of this (assuming I'm understanding the issue correctly).

Since I don't have a GSSAPI server setup (yet) I wasn't able to actually run and test the patch. I did see one possible problem in my original change so I've made another try build here: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=d533743c18052282b9a781283b5acffad1e44cfc

If you want to see if my changes help, you should probably just run these instead of my links in comment 5.
Linux: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Q--g67odSYCam-YipL28oQ/runs/0/artifacts/public/build/target.tar.bz2
Windows: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Dj9FGdiGSWGxQZwGbhmp3w/runs/0/artifacts/public/build/install/sea/target.installer.exe

See Also: → 1485724

Hi Gene,

Viktor from Postfix is one the core developers :-) I had a posting in the Dovecot mailing list in November and Aki (one of the developers there), said exactly the same as Viktor, however it confused me back then because the only thing I changed was the version of Dovecot and there were no changes to the TB version.

The good news is that I installed the above test version and I can confirm that I can send email using GSSAPI with it.
Here is the relevant part of the smtp conversation:

submission-login: Debug: smtp-server: conn 192.168.1.1:50278 [1]: command EHLO: 250 reply: Sent: 250-mail.example.com 8BITMIME AUTH GSSAPI GSS-SPNEGO PLAIN BURL imap CHUNKING ENHANCEDSTATUSCODES SIZE PIPELINING
submission-login: Debug: smtp-server: conn 192.168.1.1:50278 [1]: command EHLO: Finished
submission-login: Debug: smtp-server: conn 192.168.1.1:50278 [1]: command EHLO: Destroy
submission-login: Debug: smtp-server: conn 192.168.1.1:50278 [1]: command EHLO: 250 reply: Destroy
submission-login: Debug: smtp-server: conn 192.168.1.1:50278 [1]: Trigger output
submission-login: Debug: smtp-server: conn 192.168.1.1:50278 [1]: No more commands pending
submission-login: Debug: smtp-server: conn 192.168.1.1:50278 [1]: Sending replies
submission-login: Debug: smtp-server: conn 192.168.1.1:50278 [1]: No more commands pending
submission-login: Debug: smtp-server: conn 192.168.1.1:50278 [1]: Received new command: AUTH GSSAPI
submission-login: Debug: smtp-server: conn 192.168.1.1:50278 [1]: command AUTH: New command
submission-login: Debug: smtp-server: conn 192.168.1.1:50278 [1]: command AUTH: Execute command
submission-login: Debug: smtp-server: conn 192.168.1.1:50278 [1]: command AUTH: Next to reply
auth: Debug: client in: AUTH#0111#011GSSAPI#011service=submission#011secured=tls#011session=20F/bdfdaeqAqE#011lip=192.168.1.5#011rip=192.168.1.1#011lport=465#011rport=50278#011local_name=mail.example.com
auth: Debug: gssapi(?,192.168.1.1,<20F/bdfdaeqAqE>): Obtaining credentials for submission@mail.example.com
auth: Debug: client passdb out: CONT#0111#011
submission-login: Debug: smtp-server: conn 192.168.1.1:50278 [1]: Sent: 334 
submission-login: Debug: smtp-server: conn 192.168.1.1:50278 [1]: Sending replies
submission-login: Debug: smtp-server: conn 192.168.1.1:50278 [1]: command AUTH: Next to reply
submission-login: Debug: smtp-server: conn 192.168.1.1:50278 [1]: Received AUTH response: <kerberos-ticket redacted>
auth: Debug: client in: CONT<hidden>
Status: UNCONFIRMED → RESOLVED
Closed: 7 months ago
Resolution: --- → WORKSFORME

The good news is that I installed the above test version and I can confirm that I can send email using GSSAPI with it.

That is good news!
I see that you closed the bug as "works for me". Actually, I still need to submit a formal patch and have it approved before the bug can be closed. So I'm re-opening it.
I will probably also ask you to test again the final version when it is ready, if you don't mind.
Anyhow, thanks for testing the "try" build.

Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WORKSFORME → ---
Duplicate of this bug: 1485724

No problem, let me know when I can help :-)

Assignee: nobody → gds

A complete "try" build is here: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=727b17df0c186a3727fa096f3ece2de33ff0de78

I also looked at the POP3 and IMAP implementations of GSSAPI and it appears that they don't have the same potential problem. For those protocols, there is no token sent with the "AUTH GSSAPI" command and the tokens are all sent later as separate command lines.

Kees,
The linux and windows output from this build are here:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/EiEG5q5wSYqujOvggofrsw/runs/0/artifacts/public/build/target.tar.bz2
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/QUK1jiOxTo6cUcmiZJnppg/runs/0/artifacts/public/build/install/sea/target.installer.exe

The "try" build this time is based on the current daily version (as of 3/14). If you could check to make sure this still works with your dovecot server I would appreciate it. All I changed in this patch compared to your previous test* is some comments in the code.
Thanks!
* I'm assuming you tested the build referenced in comment 6.

Summary: SMTP GSSAPI does not send AUTH GSSAPI resulting in auth failure → SMTP "AUTH GSSAPI <1st token>" will fail if the first token sent is too long

IMAP is used here, indeed it does not have an issue. That means users can read mail and save concepts but they can't send anything.

For the previous test I used a Windows machine, mainly because on Linux it finds and loads the shared libraries from the installed release version instead of the attached test version.

On the Windows machine I uninstalled the released TB before installing your test version. Now I want to uninstall the previous test version before installing the one you just posted. However TB is not listed under installed applications in Windows settings. There does not seem to be an uninstaller in "c:\program files\Thunderbird Daily", and google does not seem to help either...
What is the best way to uninstall it in Windows?
Can just remove the directory "c:\program files\Thunderbird Daily"?

Just to confirm: I did test the build in comment 6.

The question in the previous comment is how get that version uninstalled and to be sure that I only run code from comment 12 in the next test.

On linux when I unzip the file into Downloads and just run ~/Downloads/thunderbird/thunderbird it seem to work OK and run the the changed version, at least I thought it did. Didn't notice that it was really running installed lib code (but maybe it is). Maybe you have to cd ~/Downloads/thunderbird and then run thunderbird from command line?

Edit:
I can rename any of the libs under ~/Downloads/thunderbird, e.g. mv libxul.so libxul---.so and it won't run and complains about missing libxul.so.
Also, I can do cd ; ~/Download/thunderbird/thunderbird (with the correctly named libxul.so, of course), obtain the thunderbird process ID and look at
/proc/<tb-processID>/maps and see in that read-only system file that it is using the local library files, e.g.,

:
7f0d5ca22000-7f0d5ca24000 r--p 00000000 fd:00 277453                     /home/gene/Downloads/thunderbird/libmozwayland.so
7f0d5ca28000-7f0d5ca42000 r--p 00000000 fd:00 276811                     /home/gene/Downloads/thunderbird/libssl3.so
7f0d5cbfe000-7f0d5cc02000 rw-p 00170000 fd:00 276556                     /home/gene/Downloads/thunderbird/libmozsqlite3.so
7f0d5cc03000-7f0d5cc11000 r--p 00000000 fd:00 277896                     /home/gene/Downloads/thunderbird/libsmime3.so
:

<End edit>

Anyhow, not sure about windows uninstall either, I'm on linux right now. I've installed betas and daily in windows and I thought there were uninstall entries for them. If not, I would just delete c:\program files\Thunderbird Daily like you ask. Don't know what else you can do...???

I just ran the build from comment 12.
It works fine, I can send over smtp using the kerberos ticket (gssapi).

(In reply to Kees van Vloten from comment #16)

I just ran the build from comment 12.
It works fine, I can send over smtp using the kerberos ticket (gssapi).

Thanks a lot!

Reporter Kees, Just to let you know, I was finally able to set up a dovecot/postfix SMTP server that supports kerberos/gssapi and was able to duplicate the bug as you reported it. Also, using my setup, I was able verify that the patch referenced in comment 11 (now having some modifications to what you tested) fixes it.

Keywords: checkin-needed-tb
status-thunderbird125: --- → affected
status-thunderbird_esr115: --- → affected
Target Milestone: --- → 126 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/dd8917662019
Avoid AUTH GSSAPI error for SMTP due to line too long. r=mkmelin

Status: REOPENED → RESOLVED
Closed: 7 months ago → 7 months ago
Keywords: checkin-needed-tb
Resolution: --- → FIXED

good for beta?

yes, should be OK.

Comment on attachment 9391335 [details]
Bug 1883529 - Avoid AUTH GSSAPI error for SMTP due to line too long. r=mkmelin

[Triage Comment]
Approved for beta

Attachment #9391335 - Flags: approval-comm-beta+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: