Summary | Headers encoded wrongly when replying to certain senders |
Queue | Synchronization |
Queue Version | FRAMEWORK_5_2 |
Type | Bug |
State | No Feedback |
Priority | 1. Low |
Owners | mrubinsk (at) horde (dot) org |
Requester | alexh (at) boxed (dot) no |
Created | 10/16/2017 (2820 days ago) |
Due | |
Updated | 11/21/2018 (2419 days ago) |
Assigned | 10/28/2017 (2808 days ago) |
Resolved | 11/21/2018 (2419 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
explain it, and explains why you cannot reproduce it (you seem to run
exim from some bounce messages I've got):
problem and fully reproducible?
to explain it, and explains why you cannot reproduce it (you seem to
run exim from some bounce messages I've got):
explain it, and explains why you cannot reproduce it (you seem to run
exim from some bounce messages I've got):
"When the Postfix SMTP server receives a message WITHOUT the SMTPUTF8
request, Postfix handles the message as it has always done (at least
that is the default, see autodetection below). Specifically, the
Postfix SMTP server does not accept UTF-8 in the envelope sender
domain name or envelope recipient domain name, and the Postfix SMTP
client does not issue the SMTPUTF8 request when delivering that
message to an SMTP or LMTP server that announces SMTPUTF8 support
(again, that is the default). Postfix will accept UTF-8 in message
header values and in the localpart of envelope sender and recipient
addresses, because it has always done that."
The two first sentences seem to be the problem.
-A
down, clearly Horde generates something that the MTA can't parse
properly, though?
send you a test email directly and see if that makes your server
behave the same?
-A
down, clearly Horde generates something that the MTA can't parse
properly, though?
down, clearly Horde generates something that the MTA can't parse
properly, though?
-A
Priority ⇒ 1. Low
devices works as expected.
emails that exhibit this behaviour?
-A
commit 4d9db500eeb53f6939ccf736f5e485d5a1df800f
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date: Mon, 30 Oct 2017 20:55:29 +0100
Add (passing) test re:
bug: 14710M test/Horde/Mime/HeadersTest.php
https://github.com/horde/Mime/commit/4d9db500eeb53f6939ccf736f5e485d5a1df800f
emails that exhibit this behaviour?
Please provide the full source of an email that exhibits this behavior.
emails that exhibit this behaviour?
They have in common that the person I'm replying to have [帿ŨÆ] in
their names.
-A
State ⇒ Feedback
Please provide the full source of an email that exhibits this behavior.
commit a4cf059021fe2ccfdd6c520604230ab67db6634f
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date: Sat, 28 Oct 2017 16:40:00 -0400
Add (passing) test re:
bug: 14710M test/Horde/Mime/HeadersTest.php
https://github.com/horde/Mime/commit/a4cf059021fe2ccfdd6c520604230ab67db6634f
Assigned to Michael Rubinsky
between Horde and postfix:
[root@popper ~]# tshark -r utf8-fun.dump
Running as user "root" and group "root". This could be dangerous.
1 0 127.0.0.1 -> 127.0.0.1 TCP 74 50784 > submission
[SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1439637087
TSecr=0 WS=128
2 380105375 127.0.0.1 -> 127.0.0.1 TCP 74 submission > 50784
[SYN, ACK] Seq=0 Ack=1 Win=43690 Len=0 MSS=65495 SACK_PERM=1
TSval=1439637087 TSecr=1439637087 WS=128
3 0 127.0.0.1 -> 127.0.0.1 TCP 66 50784 > submission
[ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=1439637087 TSecr=1439637087
4 0 127.0.0.1 -> 127.0.0.1 SMTP 99 S: 220
mail.boxed.no ESMTP Postfix
5 0 127.0.0.1 -> 127.0.0.1 TCP 66 50784 > submission
[ACK] Seq=1 Ack=34 Win=43776 Len=0 TSval=1439637088 TSecr=1439637088
6 0 127.0.0.1 -> 127.0.0.1 SMTP 86 C: EHLO mail.boxed.no
7 0 127.0.0.1 -> 127.0.0.1 TCP 66 submission > 50784
[ACK] Seq=34 Ack=21 Win=43776 Len=0 TSval=1439637088 TSecr=1439637088
8 0 127.0.0.1 -> 127.0.0.1 SMTP 178 S: 250
mail.boxed.no | 250 PIPELINING | 250 SIZE 20480000 | 250 ETRN | 250
ENHANCEDSTATUSCODES | 250 8BITMIME | 250 DSN
9 0 127.0.0.1 -> 127.0.0.1 SMTP 178 C: MAIL
FROM:<alexh@boxed.no> SIZE=9623 | RCPT TO:<"=?utf-8?Q?\"Lanesskog"> |
RCPT TO:<Jorgen.Lanesskog@marinit.no>
10 0 127.0.0.1 -> 127.0.0.1 SMTP 195 S: 250 2.1.0 Ok
| 550 5.1.1 <=?utf-8?Q?"Lanesskog>: Recipient address rejected: User
unknown in local recipient table | 250 2.1.5 Ok
11 0 127.0.0.1 -> 127.0.0.1 SMTP 72 C: RSET
12 0 127.0.0.1 -> 127.0.0.1 SMTP 80 S: 250 2.0.0 Ok
13 0 127.0.0.1 -> 127.0.0.1 SMTP 72 C: QUIT
14 0 127.0.0.1 -> 127.0.0.1 SMTP 81 S: 221 2.0.0 Bye
15 0 127.0.0.1 -> 127.0.0.1 TCP 66 submission > 50784
[FIN, ACK] Seq=304 Ack=145 Win=43776 Len=0 TSval=1439637109
TSecr=1439637108
16 0 127.0.0.1 -> 127.0.0.1 TCP 66 50784 > submission
[FIN, ACK] Seq=145 Ack=305 Win=44800 Len=0 TSval=1439637109
TSecr=1439637109
17 0 127.0.0.1 -> 127.0.0.1 TCP 66 submission > 50784
[ACK] Seq=305 Ack=146 Win=43776 Len=0 TSval=1439637109 TSecr=1439637109
-A
Priority ⇒ 2. Medium
State ⇒ Unconfirmed
Patch ⇒ No
Milestone ⇒
Summary ⇒ Headers encoded wrongly when replying to certain senders
Type ⇒ Bug
Queue ⇒ Synchronization
#14456. Here is what postfix spits out when aniPhone tires to reply to a problematic email:
Oct 16 04:15:08 popper postfix/submission/smtpd[29358]: NOQUEUE:
reject: RCPT from localhost[127.0.0.1]: 550 5.1.1
<=?utf-8?Q?"Lanesskog>: Recipient address rejected: User unknown in
local recipient table; from=<alexh@boxed.no> to=<=?utf-8?Q?"Lanesskog>
proto=ESMTP helo=<mail.boxed.no>
The original From-header from the mail storage is this:
From: =?utf-8?B?TGFuZXNza29nLCBKw7hyZ2Vu?= <Jorgen.Lanesskog@marinit.no>