troubles to receive email with password recovery link: maximum allowed line length is 998

Question

Hello @atlassian-Postmaster,

It's mostly related to your way to generate password recovery link.

In short: couldn't receive password recovery email link because message line length is longer 998 ASCII bytes, which not complaint SMTP RFCs.

Long story: By standards, line length shouldn't exceed 998 ASCII bytes. But "Set password" line is about 1152 bytes in my case. And, my local email service is rejecting it.

I assume, mail services like AWS SES you're using, O365, Gmail etc are protecting their customers by allowing these faults. #metoo have fixed configuration as well. But, your clients might be affected.

Link length needs fix in text part of the email.

Log message from mail Exim mail service.

2025-06-09 01:51:18 1uOOrG-00000000LKz-0B45 H=(c147-139.smtp-out.us-west-2.amazonses.com) [76.223.147.139] I=[192.168.5.10]:25 X=TLS1.3:TLS_AES_128_GCM_SHA256:128 CV=no F=<0101019751bd47c0-16edd844-92fe-4aa1-b950-e69cbc94badb-000000@atlassian-bounces.atlassian.com> rejected after DATA: maximum allowed line length is 998 octets, got 1153

Alexander Ignatyev · Answer

It's really good explanation. Thank you Dirk.

But, the wheel is already invented :)

The proper Content-Transfer-Encoding: quoted-printable is already used right on next message after password reset (Subject: Your Atlassian account password has changed). Here are long URLs separated by '='s.

Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

^^^ with text message part.

What Jira dev teams need to do, it's just sync experience :)

Dirk Lachowski_b0vz9b · Answer

Nah, not that easy.

* Exim is implementing RFC 2822 / 5322 that states "There are two limits that this specification places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF." and mostly the same for header fields
* AWS SES implements RFC 5321 that says "4.5.3.1.6. Text Line: The maximum total length of a text line including the <CRLF> is 1000 octets (not counting the leading dot duplicated for transparency). This number may be increased by the use of SMTP Service Extensions."

While both are roughly the same (including / excluding CRLF), RFC 5321 (SMTP) allows longer lines ("MAY be increased"), so the ones behind IMF maybe should talk with the SMTP guys.

When the SES docs say "The length of any single line of text in the message can't exceed 1,000 characters. This restriction is defined in RFC 5321", this is only an SES requirement when sending in Raw format (and of course "characters" aren't octets but code points, so this is kinda useless and also not defined, or even recommended, in RFC 5321) . If you opt to send in simple or templated, there is no such limitation, so what Atlassian is doing here is likely well within what's specified by RFC 5321 and SES. And we maybe also see an implementation error in SES when transforming simple to raw or just someone not knowing the difference between octets and code points. That's where the SHOULD part in 5322 comes in handy.

That's the problem with RFCs vs. standards, you can have multiple RFC with mutually exclusive specifications. And of course it's also a problem with the guys from the "there's an RFC for this, bend down to it" faction. The internet is about interoperability, not about following rules for rules sake.

Long story short: AWS missed the job and the Exim guys also suck.

As it says: "Strict when sending, lenient when receiving" and both parties managed to do the opposite.

Alexander Ignatyev · Answer

Agree, it's a major idea of a RFC - to provide guidance in variety of developer's ideas. For others, it's a just a good will to follow, disobey, or just never know about it :)

Still keep lit a little hope, just because it's easy fix.