starred/lldap-lldap
1
0
Fork 0
mirror of https://github.com/lldap/lldap.git synced 2026-04-25 16:25:55 +03:00
Code Issues 101 Projects Releases 10 Packages Wiki Activity

[GH-ISSUE #370] Strange formatting on password reset email link #140

New issue
Closed
opened 2026-02-27 08:15:28 +03:00 by kerem · 14 comments
kerem commented 2026-02-27 08:15:28 +03:00
Owner
Copy link

Originally created by @iplusplus42 on GitHub (Nov 15, 2022).
Original GitHub issue: https://github.com/lldap/lldap/issues/370

Hello! While testing my LLDAP configs, I found that the emailed password reset link isn't directly usable and appears to have been broken up by some kind of text wrapping. Below is the text from the email I received:

Hello Andy,
This email has been sent to you in order to validate your identity.
If you did not initiate the process your credentials might have been
compromised. You should reset your password and contact an administrator.

To reset your password please visit the following URL: http://lldap.exam=
ple.com/reset-password/step2/W11CIJ7nKr0LRp4UaYUgshRMf4RpsL5mzgLhJGIxyrCA=
P129DyO0HjMoxG5wj9wTuAZzSoxaSTIe2BvBw7FSCt7sYkcDDZRLGqlf

Please contact an administrator if you did not initiate the process.

I could have something misconfigured somewhere, but I'm not sure. I'm running LLDAP v0.4.2-alpha on the lldap:latest Docker image. Please let me know if you need more information. Thank you!

Originally created by @iplusplus42 on GitHub (Nov 15, 2022). Original GitHub issue: https://github.com/lldap/lldap/issues/370 Hello! While testing my LLDAP configs, I found that the emailed password reset link isn't directly usable and appears to have been broken up by some kind of text wrapping. Below is the text from the email I received: ``` Hello Andy, This email has been sent to you in order to validate your identity. If you did not initiate the process your credentials might have been compromised. You should reset your password and contact an administrator. To reset your password please visit the following URL: http://lldap.exam= ple.com/reset-password/step2/W11CIJ7nKr0LRp4UaYUgshRMf4RpsL5mzgLhJGIxyrCA= P129DyO0HjMoxG5wj9wTuAZzSoxaSTIe2BvBw7FSCt7sYkcDDZRLGqlf Please contact an administrator if you did not initiate the process. ``` I could have something misconfigured somewhere, but I'm not sure. I'm running LLDAP v0.4.2-alpha on the lldap:latest Docker image. Please let me know if you need more information. Thank you!
kerem 2026-02-27 08:15:28 +03:00
kerem commented 2026-02-27 08:15:29 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Nov 15, 2022):

The domain part is taken from your configuration, the "http_url". Can you
double check it?

On Tue, 15 Nov 2022, 06:00 Andy Merrill, @.***> wrote:

Hello! While testing my LLDAP configs, I found that the emailed password
reset link isn't directly usable and appears to have been broken up by some
kind of text wrapping. Below is the text from the email I received:

Hello Andy,
This email has been sent to you in order to validate your identity.
If you did not initiate the process your credentials might have been
compromised. You should reset your password and contact an administrator.

To reset your password please visit the following URL: http://lldap.exam=ple.com/reset-password/step2/W11CIJ7nKr0LRp4UaYUgshRMf4RpsL5mzgLhJGIxyrCA=
P129DyO0HjMoxG5wj9wTuAZzSoxaSTIe2BvBw7FSCt7sYkcDDZRLGqlf http://ple.com/reset-password/step2/W11CIJ7nKr0LRp4UaYUgshRMf4RpsL5mzgLhJGIxyrCA=P129DyO0HjMoxG5wj9wTuAZzSoxaSTIe2BvBw7FSCt7sYkcDDZRLGqlf

Please contact an administrator if you did not initiate the process.

I could have something misconfigured somewhere, but I'm not sure. I'm
running LLDAP v0.4.2-alpha on the lldap:latest Docker image. Please let me
know if you need more information. Thank you!

—
Reply to this email directly, view it on GitHub
https://github.com/nitnelave/lldap/issues/370, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGCPWNCDZLS66LKQ7E3Q5LWIMKGVANCNFSM6AAAAAASAQY4UI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

<!-- gh-comment-id:1314905943 --> @nitnelave commented on GitHub (Nov 15, 2022): The domain part is taken from your configuration, the "http_url". Can you double check it? On Tue, 15 Nov 2022, 06:00 Andy Merrill, ***@***.***> wrote: > Hello! While testing my LLDAP configs, I found that the emailed password > reset link isn't directly usable and appears to have been broken up by some > kind of text wrapping. Below is the text from the email I received: > > Hello Andy, > This email has been sent to you in order to validate your identity. > If you did not initiate the process your credentials might have been > compromised. You should reset your password and contact an administrator. > > To reset your password please visit the following URL: http://lldap.exam=ple.com/reset-password/step2/W11CIJ7nKr0LRp4UaYUgshRMf4RpsL5mzgLhJGIxyrCA= > P129DyO0HjMoxG5wj9wTuAZzSoxaSTIe2BvBw7FSCt7sYkcDDZRLGqlf <http://ple.com/reset-password/step2/W11CIJ7nKr0LRp4UaYUgshRMf4RpsL5mzgLhJGIxyrCA=P129DyO0HjMoxG5wj9wTuAZzSoxaSTIe2BvBw7FSCt7sYkcDDZRLGqlf> > > Please contact an administrator if you did not initiate the process. > > I could have something misconfigured somewhere, but I'm not sure. I'm > running LLDAP v0.4.2-alpha on the lldap:latest Docker image. Please let me > know if you need more information. Thank you! > > — > Reply to this email directly, view it on GitHub > <https://github.com/nitnelave/lldap/issues/370>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAGCPWNCDZLS66LKQ7E3Q5LWIMKGVANCNFSM6AAAAAASAQY4UI> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >
kerem commented 2026-02-27 08:15:29 +03:00
Author
Owner
Copy link

@iplusplus42 commented on GitHub (Nov 15, 2022):

http_url = "https://ldap.example.com"
That's what I have in my lldap_config.toml. It differs slightly from the link in my first comment, and that's because I noticed a few typos in the URL, but the issue still occurs. Thank you!

<!-- gh-comment-id:1315829729 --> @iplusplus42 commented on GitHub (Nov 15, 2022): `http_url = "https://ldap.example.com"` That's what I have in my lldap_config.toml. It differs slightly from the link in my first comment, and that's because I noticed a few typos in the URL, but the issue still occurs. Thank you!
kerem commented 2026-02-27 08:15:29 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Nov 16, 2022):

Okay, I went through the code, I don't see any way that it would create this message.

However, looking at the body of the email, I see that it's aligned at 80 columns: I suspect either your SMTP relay and/or your email client of wrapping the message and adding the "=" when splitting the URL. Can you try sending the message from a different account, to a different account, or reading it with a different email client?

<!-- gh-comment-id:1317349500 --> @nitnelave commented on GitHub (Nov 16, 2022): Okay, I went through the code, I don't see any way that it would create this message. However, looking at the body of the email, I see that it's aligned at 80 columns: I suspect either your SMTP relay and/or your email client of wrapping the message and adding the "=" when splitting the URL. Can you try sending the message from a different account, to a different account, or reading it with a different email client?
kerem commented 2026-02-27 08:15:29 +03:00
Author
Owner
Copy link

@ghost commented on GitHub (Jan 22, 2023):

I ran into this too. lldap is the only program I have that generates these emails with = signs like this. All through a mailbox.org SMTP server. Other services include:

I can't prove definitively that lldap is the issue...but other programs through the same SMTP server aren't doing this, so idk.

Ergo, for instance, sends a plaintext email for adding/changing an email to your account where the first line is 83 characters (with my server name) and this weird = thing does not happen.

Also on ergo: a password reset email (plaintext) contains a line that is 115 characters and, again, this weird = thing does not happen.

lldap seems to be doing line breaks with an equal sign (=) at 75 characters, for me.

Unfortunately, verbose logging doesn't turn up anything especially helpful:

2023-01-22T08:00:39.497692868+00:00 INFO     HTTP request [ 2.42s | 0.00% / 100.00% ]
2023-01-22T08:00:39.497705184+00:00 INFO     ┝━ ｉ [info]:  | uri: /auth/reset/step1/REDACTED
2023-01-22T08:00:39.497740664+00:00 DEBUG    ┝━ get_password_reset_step1 [ 2.42s | 99.97% / 100.00% ]
2023-01-22T08:00:39.497746115+00:00 DEBUG    │  ┝━ start_password_reset [ 320µs | 0.01% ]
2023-01-22T08:00:39.497754878+00:00 DEBUG    │  │  ┝━ 🐛 [debug]:  | user: UserId("REDACTED")
2023-01-22T08:00:39.497798554+00:00 DEBUG    │  │  ┝━ 🐛 [debug]:  | query: SELECT "user_id" FROM "users" WHERE "user_id" = ?
2023-01-22T08:00:39.498230948+00:00 DEBUG    │  │  ┕━ 🐛 [debug]:  | query: INSERT INTO "password_reset_tokens" ("token", "user_id", "expiry_date") VALUES (?, ?, ?)
2023-01-22T08:00:39.510712907+00:00 DEBUG    │  ┝━ get_user_details [ 240µs | 0.01% ]
2023-01-22T08:00:39.510727575+00:00 DEBUG    │  │  ┝━ 🐛 [debug]:  | user_id: UserId("REDACTED")
2023-01-22T08:00:39.510800210+00:00 DEBUG    │  │  ┝━ 🐛 [debug]:  | query: SELECT "user_id", "email", "display_name", "first_name", "last_name", "avatar", "creation_date", "uuid" FROM "users" WHERE "user_id" = ?
2023-01-22T08:00:39.511339168+00:00 DEBUG    │  │  ┕━ 🐛 [debug]:  | return: Ok(User { user_id: UserId("REDACTED"), email: "REDACTED@REDACTED", display_name: "REDACTED", first_name: "", last_name: "", avatar: JpegPhoto([]), creation_date: 2023-01-22T05:14:04.371524536Z, uuid: Uuid("f19a3b1e-92d9-30b3-b2ba-778aee6af15d") })
2023-01-22T08:00:39.511370399+00:00 DEBUG    │  ┝━ 🐛 [debug]: Sending email to 'REDACTED@REDACTED' as 'REDACTED <REDACTED@REDACTED>' via 'REDACTED@mailbox.org'@'smtp.mailbox.org':'465'
2023-01-22T08:00:39.658756884+00:00 DEBUG    │  ┝━ 🐛 [debug]: No cached session for DnsName(DnsName(DnsName("smtp.mailbox.org"))) | log.target: "rustls::client::hs" | log.module_path: "rustls::client::hs" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/rustls-0.20.6/src/client/hs.rs" | log.line: 56
2023-01-22T08:00:39.658876918+00:00 DEBUG    │  ┝━ 🐛 [debug]: Not resuming any session | log.target: "rustls::client::hs" | log.module_path: "rustls::client::hs" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/rustls-0.20.6/src/client/hs.rs" | log.line: 128
2023-01-22T08:00:39.960940522+00:00 DEBUG    │  ┝━ 🐛 [debug]: Using ciphersuite TLS13_AES_256_GCM_SHA384 | log.target: "rustls::client::hs" | log.module_path: "rustls::client::hs" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/rustls-0.20.6/src/client/hs.rs" | log.line: 584
2023-01-22T08:00:39.960981605+00:00 DEBUG    │  ┝━ 🐛 [debug]: Not resuming | log.target: "rustls::client::tls13" | log.module_path: "rustls::client::tls13" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/rustls-0.20.6/src/client/tls13.rs" | log.line: 127
2023-01-22T08:00:39.963332215+00:00 DEBUG    │  ┝━ 🐛 [debug]: TLS1.3 encrypted extensions: [] | log.target: "rustls::client::tls13" | log.module_path: "rustls::client::tls13" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/rustls-0.20.6/src/client/tls13.rs" | log.line: 392
2023-01-22T08:00:39.963357544+00:00 DEBUG    │  ┝━ 🐛 [debug]: ALPN protocol is None | log.target: "rustls::client::hs" | log.module_path: "rustls::client::hs" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/rustls-0.20.6/src/client/hs.rs" | log.line: 453
2023-01-22T08:00:40.256166960+00:00 DEBUG    │  ┕━ 🐛 [debug]: Ticket saved | log.target: "rustls::client::tls13" | log.module_path: "rustls::client::tls13" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/rustls-0.20.6/src/client/tls13.rs" | log.line: 1047
2023-01-22T08:00:41.931343636+00:00 INFO     ┕━ ｉ [info]:  | status_code: 200

Curious about the log.line lines with stuff about GitHub and cargo registries and such.

In fact, if I take the exact same email and just remove the = signs and send as plaintext via Thunderbird, it also sends correctly, with no weird line breaks.

Are we positive this isn't some weird default setting of some upstream library or something?

<!-- gh-comment-id:1399422707 --> @ghost commented on GitHub (Jan 22, 2023): I ran into this too. `lldap` is the only program I have that generates these emails with `=` signs like this. All through a `mailbox.org` SMTP server. Other services include: * https://github.com/ergochat/ergo * https://codeberg.org/forgejo/forgejo I can't prove definitively that `lldap` is the issue...but other programs through the same SMTP server aren't doing this, so idk. Ergo, for instance, sends a *plaintext* email for adding/changing an email to your account where the first line is `83` characters (with my server name) and this weird `=` thing does not happen. Also on ergo: a password reset email (*plaintext*) contains a line that is `115` characters and, again, this weird `=` thing does not happen. `lldap` seems to be doing line breaks with an equal sign (`=`) at 75 characters, for me. --- Unfortunately, verbose logging doesn't turn up anything especially helpful: ``` 2023-01-22T08:00:39.497692868+00:00 INFO HTTP request [ 2.42s | 0.00% / 100.00% ] 2023-01-22T08:00:39.497705184+00:00 INFO ┝━ ｉ [info]: | uri: /auth/reset/step1/REDACTED 2023-01-22T08:00:39.497740664+00:00 DEBUG ┝━ get_password_reset_step1 [ 2.42s | 99.97% / 100.00% ] 2023-01-22T08:00:39.497746115+00:00 DEBUG │ ┝━ start_password_reset [ 320µs | 0.01% ] 2023-01-22T08:00:39.497754878+00:00 DEBUG │ │ ┝━ 🐛 [debug]: | user: UserId("REDACTED") 2023-01-22T08:00:39.497798554+00:00 DEBUG │ │ ┝━ 🐛 [debug]: | query: SELECT "user_id" FROM "users" WHERE "user_id" = ? 2023-01-22T08:00:39.498230948+00:00 DEBUG │ │ ┕━ 🐛 [debug]: | query: INSERT INTO "password_reset_tokens" ("token", "user_id", "expiry_date") VALUES (?, ?, ?) 2023-01-22T08:00:39.510712907+00:00 DEBUG │ ┝━ get_user_details [ 240µs | 0.01% ] 2023-01-22T08:00:39.510727575+00:00 DEBUG │ │ ┝━ 🐛 [debug]: | user_id: UserId("REDACTED") 2023-01-22T08:00:39.510800210+00:00 DEBUG │ │ ┝━ 🐛 [debug]: | query: SELECT "user_id", "email", "display_name", "first_name", "last_name", "avatar", "creation_date", "uuid" FROM "users" WHERE "user_id" = ? 2023-01-22T08:00:39.511339168+00:00 DEBUG │ │ ┕━ 🐛 [debug]: | return: Ok(User { user_id: UserId("REDACTED"), email: "REDACTED@REDACTED", display_name: "REDACTED", first_name: "", last_name: "", avatar: JpegPhoto([]), creation_date: 2023-01-22T05:14:04.371524536Z, uuid: Uuid("f19a3b1e-92d9-30b3-b2ba-778aee6af15d") }) 2023-01-22T08:00:39.511370399+00:00 DEBUG │ ┝━ 🐛 [debug]: Sending email to 'REDACTED@REDACTED' as 'REDACTED <REDACTED@REDACTED>' via 'REDACTED@mailbox.org'@'smtp.mailbox.org':'465' 2023-01-22T08:00:39.658756884+00:00 DEBUG │ ┝━ 🐛 [debug]: No cached session for DnsName(DnsName(DnsName("smtp.mailbox.org"))) | log.target: "rustls::client::hs" | log.module_path: "rustls::client::hs" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/rustls-0.20.6/src/client/hs.rs" | log.line: 56 2023-01-22T08:00:39.658876918+00:00 DEBUG │ ┝━ 🐛 [debug]: Not resuming any session | log.target: "rustls::client::hs" | log.module_path: "rustls::client::hs" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/rustls-0.20.6/src/client/hs.rs" | log.line: 128 2023-01-22T08:00:39.960940522+00:00 DEBUG │ ┝━ 🐛 [debug]: Using ciphersuite TLS13_AES_256_GCM_SHA384 | log.target: "rustls::client::hs" | log.module_path: "rustls::client::hs" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/rustls-0.20.6/src/client/hs.rs" | log.line: 584 2023-01-22T08:00:39.960981605+00:00 DEBUG │ ┝━ 🐛 [debug]: Not resuming | log.target: "rustls::client::tls13" | log.module_path: "rustls::client::tls13" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/rustls-0.20.6/src/client/tls13.rs" | log.line: 127 2023-01-22T08:00:39.963332215+00:00 DEBUG │ ┝━ 🐛 [debug]: TLS1.3 encrypted extensions: [] | log.target: "rustls::client::tls13" | log.module_path: "rustls::client::tls13" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/rustls-0.20.6/src/client/tls13.rs" | log.line: 392 2023-01-22T08:00:39.963357544+00:00 DEBUG │ ┝━ 🐛 [debug]: ALPN protocol is None | log.target: "rustls::client::hs" | log.module_path: "rustls::client::hs" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/rustls-0.20.6/src/client/hs.rs" | log.line: 453 2023-01-22T08:00:40.256166960+00:00 DEBUG │ ┕━ 🐛 [debug]: Ticket saved | log.target: "rustls::client::tls13" | log.module_path: "rustls::client::tls13" | log.file: "/__w/lldap/lldap/${GITHUB_WORKSPACE}/.cargo/registry/src/github.com-1ecc6299db9ec823/rustls-0.20.6/src/client/tls13.rs" | log.line: 1047 2023-01-22T08:00:41.931343636+00:00 INFO ┕━ ｉ [info]: | status_code: 200 ``` Curious about the `log.line` lines with stuff about GitHub and cargo registries and such. --- In fact, if I take the exact same email and just remove the `=` signs and send as plaintext via Thunderbird, it also sends correctly, with no weird line breaks. Are we *positive* this isn't some weird default setting of some upstream library or something?
kerem commented 2026-02-27 08:15:29 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Jan 22, 2023):

Alright, this seems to be a case of Quoted-printable encoding, where lines over 76 characters are escaped with an equal sign. It's a technically valid, if a bit old, encoding, that is usually supported by big clients.

I'll have a look to see if I can change the encoding.

<!-- gh-comment-id:1399449672 --> @nitnelave commented on GitHub (Jan 22, 2023): Alright, this seems to be a case of [Quoted-printable encoding](https://en.wikipedia.org/wiki/Quoted-printable), where lines over 76 characters are escaped with an equal sign. It's a technically valid, if a bit old, encoding, that is usually supported by big clients. I'll have a look to see if I can change the encoding.
kerem commented 2026-02-27 08:15:29 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Jan 22, 2023):

Note for the future, or if someone wants to take this up: in mail.rs, instead of using body, we should use singlepart: https://docs.rs/lettre/0.10.0-alpha.1/lettre/message/index.html#single-part

<!-- gh-comment-id:1399450181 --> @nitnelave commented on GitHub (Jan 22, 2023): Note for the future, or if someone wants to take this up: in mail.rs, instead of using `body`, we should use `singlepart`: https://docs.rs/lettre/0.10.0-alpha.1/lettre/message/index.html#single-part
kerem commented 2026-02-27 08:15:29 +03:00
Author
Owner
Copy link

@ghost commented on GitHub (Jan 22, 2023):

I don't know if this information is any additional help or not, but this is the encoding bits for how Thunderbird seems to send plaintext emails:

Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

I see in github.com/nitnelave/lldap@32f28d664e/server/Cargo.toml (L67-L70) that we're using version 0.10.0-rc.3 of lettre. So relevant source code in lettre:

pub enum ContentTransferEncoding {
    /// ASCII
    SevenBit,
    /// Quoted-Printable encoding
    QuotedPrintable,
    /// base64 encoding
    Base64,
    /// Requires `8BITMIME`
    EightBit,
    /// Binary data
    Binary,
}

I don't know which encoding type would be the best to choose for compatibility (guessing SevenBit/ASCII), but just getting the info out there for anyone who wants to take a crack at this. :)

Edit: Maybe EightBit for future-proofing in case there's translations done for lldap at some point? Dunno.

Edit 2: Never mind. I don't think that would actually help any with translations. SevenBit probably still makes the most sense, I guess.

<!-- gh-comment-id:1399524678 --> @ghost commented on GitHub (Jan 22, 2023): I don't know if this information is any additional help or not, but this is the encoding bits for how Thunderbird seems to send plaintext emails: ``` Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ``` I see in https://github.com/nitnelave/lldap/blob/32f28d664e154e0569f0fa3bf4b85503530273e0/server/Cargo.toml#L67-L70 that we're using version `0.10.0-rc.3` of `lettre`. So [relevant source code in `lettre`](https://github.com/lettre/lettre/blob/47cad567b01db0c937293e9b04694234e78c1744/src/message/header/content.rs#L15-L26): ```rust pub enum ContentTransferEncoding { /// ASCII SevenBit, /// Quoted-Printable encoding QuotedPrintable, /// base64 encoding Base64, /// Requires `8BITMIME` EightBit, /// Binary data Binary, } ``` I don't know which encoding type would be the best to choose for compatibility (guessing `SevenBit`/`ASCII`), but just getting the info out there for anyone who wants to take a crack at this. :) --- Edit: Maybe `EightBit` for future-proofing in case there's translations done for `lldap` at some point? Dunno. Edit 2: Never mind. I don't think that would actually help any with translations. `SevenBit` probably still makes the most sense, I guess.
kerem commented 2026-02-27 08:15:30 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Jan 24, 2023):

The username can be UTF-8, so I'd like to have something that supports it.

Normally, lettre automatically chooses the appropriate encoding. I'm guessing here they went with QuotedPrintable for the long line, but even then, the client is supposed to support it correctly, that's a bog standard format.

I'm sorry for the users here, but it seems to be more of a SMTP server/email client problem than an LLDAP problem. Check with your email client whether they support the QuotedPrintable encoding, and if not, why not?

<!-- gh-comment-id:1401859921 --> @nitnelave commented on GitHub (Jan 24, 2023): The username can be UTF-8, so I'd like to have something that supports it. Normally, lettre automatically chooses the appropriate encoding. I'm guessing here they went with QuotedPrintable for the long line, but even then, the client is supposed to support it correctly, that's a bog standard format. I'm sorry for the users here, but it seems to be more of a SMTP server/email client problem than an LLDAP problem. Check with your email client whether they support the QuotedPrintable encoding, and if not, why not?
kerem commented 2026-02-27 08:15:30 +03:00
Author
Owner
Copy link

@ghost commented on GitHub (Jan 26, 2023):

I spent some time editing the source of the "problem" emails from lldap.

It looks like Thunderbird (and mailbox.org's webmail client, which I don't really use) seems to be upset that there's no Content-Type header coming in. The second I add something like Content-Type: text/plain then it immediately displays as expected.

As mentioned above, Tbird seems to set Content-Type: text/plain; charset=UTF-8; format=flowed by default, but I don't really know what format=flowed is supposed to do. Removing or adding it didn't have any effect on the emails.

Seems like simply adding Content-Type: text/plain; charset=UTF-8 might be the best bet to help clients that are expecting some sort of Content-Type.

<!-- gh-comment-id:1404458305 --> @ghost commented on GitHub (Jan 26, 2023): I spent some time editing the source of the "problem" emails from `lldap`. It looks like Thunderbird (and mailbox.org's webmail client, which I don't really use) seems to be upset that there's no `Content-Type` header coming in. The second I add something like `Content-Type: text/plain` then it immediately displays as expected. As mentioned above, Tbird seems to set `Content-Type: text/plain; charset=UTF-8; format=flowed` by default, but I don't really know what `format=flowed` is supposed to do. Removing or adding it didn't have any effect on the emails. Seems like simply adding `Content-Type: text/plain; charset=UTF-8` might be the best bet to help clients that are expecting some sort of `Content-Type`.
kerem commented 2026-02-27 08:15:30 +03:00
Author
Owner
Copy link

@codestation commented on GitHub (Feb 13, 2023):

Same problem, the email is broken on RoundCube (Webmail app) and Gmail (Android App). Consider adding the Content-Type header.

<!-- gh-comment-id:1428808276 --> @codestation commented on GitHub (Feb 13, 2023): Same problem, the email is broken on RoundCube (Webmail app) and Gmail (Android App). Consider adding the `Content-Type` header.
kerem commented 2026-02-27 08:15:30 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Feb 14, 2023):

Last time I tried, there was a problem with the library making it hard to
do this simple thing. I'll have another look when I have a minute.

On Mon, 13 Feb 2023, 23:47 codestation, @.***> wrote:

Same problem, the email is broken on RoundCube (Webmail app) and Gmail
(Android App). Consider adding the Content-Type header.

—
Reply to this email directly, view it on GitHub
https://github.com/nitnelave/lldap/issues/370#issuecomment-1428808276,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGCPWLIY7Q4KQ5EN2ZBYFLWXK2YLANCNFSM6AAAAAASAQY4UI
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

<!-- gh-comment-id:1429197426 --> @nitnelave commented on GitHub (Feb 14, 2023): Last time I tried, there was a problem with the library making it hard to do this simple thing. I'll have another look when I have a minute. On Mon, 13 Feb 2023, 23:47 codestation, ***@***.***> wrote: > Same problem, the email is broken on RoundCube (Webmail app) and Gmail > (Android App). Consider adding the Content-Type header. > > — > Reply to this email directly, view it on GitHub > <https://github.com/nitnelave/lldap/issues/370#issuecomment-1428808276>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAGCPWLIY7Q4KQ5EN2ZBYFLWXK2YLANCNFSM6AAAAAASAQY4UI> > . > You are receiving this because you modified the open/close state.Message > ID: ***@***.***> >
kerem commented 2026-02-27 08:15:30 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Feb 14, 2023):

Thanks @wkeiuluf , that really helped! Can someone confirm that it's working correctly with the latest image?

<!-- gh-comment-id:1429484363 --> @nitnelave commented on GitHub (Feb 14, 2023): Thanks @wkeiuluf , that really helped! Can someone confirm that it's working correctly with the latest image?
kerem commented 2026-02-27 08:15:30 +03:00
Author
Owner
Copy link

@iplusplus42 commented on GitHub (Feb 14, 2023):

I can confirm that the email is working correctly! Thank you to everyone involved!

<!-- gh-comment-id:1429887469 --> @iplusplus42 commented on GitHub (Feb 14, 2023): I can confirm that the email is working correctly! Thank you to everyone involved!
kerem commented 2026-02-27 08:15:30 +03:00
Author
Owner
Copy link

@codestation commented on GitHub (Feb 14, 2023):

Thank you. Can confirm is working with the email clients.

<!-- gh-comment-id:1430160859 --> @codestation commented on GitHub (Feb 14, 2023): Thank you. Can confirm is working with the email clients.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
dependabot/github_actions/codecov/codecov-action-6
copilot/fix-equality-filters-list-attributes
dependabot/github_actions/docker/build-push-action-7
dependabot/github_actions/docker/metadata-action-6
dependabot/github_actions/docker/setup-buildx-action-4
dependabot/github_actions/docker/login-action-4
copilot/update-download-artifact-action
copilot/fix-opensuse-warnings
copilot/fix-1268
copilot/fix-727
copilot/fix-898
copilot/fix-1256
copilot/fix-1251
copilot/fix-1249
copilot/fix-1206
user-attribute-form
user-ui
group-ui
server-user-attribute-schema
crates
haveibeenpwned
v0.6.2
v0.6.1
v0.6.0
v0.5.0
v0.4.3
v0.4.2
v0.4.1
v0.4.0
v0.3.0
v0.2.0
v0.0.1
Labels
Clear labels   
backend

   
blocked

   
bug

   
cleanup

   
dependencies

   
docker

   
documentation

   
duplicate

   
enhancement

   
enhancement

   
frontend

   
github_actions

   
good first issue

   
help wanted

   
help wanted

   
integration

   
invalid

   
ldap

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
rust

   
rust

   
tests

   
wontfix
No labels
backend
blocked
bug
cleanup
dependencies
docker
documentation
duplicate
enhancement
enhancement
frontend
github_actions
good first issue
help wanted
help wanted
integration
invalid
ldap
pull-request
question
rust
rust
tests
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/lldap-lldap#140
No description provided.