Using this "name": "ﻩﺍ ﺲﻧﺩ"
results in From: "ها سند" <no-reply@email.ahasend.com>
But using "name": "آها سند"
restults in From: "آها سند" <no- reply@email.ahasend.com>
Using this "name": "ﻩﺍ ﺲﻧﺩ"
results in From: "ها سند" <no-reply@email.ahasend.com>
But using "name": "آها سند"
restults in From: "آها سند" <no- reply@email.ahasend.com>
Of course that also changes the word.
But this character seems to behave like a control character آ
Hmm, but آ is probably not the only character causing this issue, the same issue happens with رهنما کالج as well which doesn’t contain آ
Still looking. SMTP injection seems fine, I am only seeing these errors with HTTP injection. Are you able to confirm that, or do you only inject with HTTP?
Yes, works with SMTP injection, the issue only happens with HTTP injection
Thanks, I’ll upgrade to the latest dev when the new builds are ready!
Just received another report about SMTP injection with UTF-8 filename header:
... while talking to send.ahasend.com.:
>>> DATA
<<< 552-5.6.0 invalid header: 0: at line 5, in Eof:
<<< 552- filename*3*=%D0%BD%D1%8
<<< 552- ^_
<<< 552 554 5.0.0 Service unavailable
The reporter says the message was constructed using Thunderbird:
--------------jH9RdGzXomZKhFXF1pcz4wcS
Content-Type: text/plain; charset=UTF-8;
name="=?UTF-8?B?0KfQsNGB0YLQuNC90LAg0LLQutC70LDQtNC10L3QvtCz0L4g0L/QvtCy?=
=?UTF-8?B?0ZbQtNC+0LzQu9C10L3QvdGP?="
Content-Disposition: attachment;
filename*0*=UTF-8''%D0%A7%D0%B0%D1%81%D1%82%D0%B8%D0%BD%D0%B0%20%D0%B2;
filename*1*=%D0%BA%D0%BB%D0%B0%D0%B4%D0%B5%D0%BD%D0%BE%D0%B3%D0%BE%20;
filename*2*=%D0%BF%D0%BE%D0%B2%D1%96%D0%B4%D0%BE%D0%BC%D0%BB%D0%B5%D0%BD;
filename*3*=%D0%BD%D1%8F
Content-Transfer-Encoding: base64
DQoNCtCd0LDQtNGW0YHQu9Cw0L3QviDQtyDQvNC+0LHRltC70YzQvdC+0LPQviDQt9Cw0YHQ
vtCx0YM=
--------------jH9RdGzXomZKhFXF1pcz4wcS--
not sure if this is related?
sounds different to me; the first issue was with constructing a header in code through a generic function, the second one sounds like a parsing issue. It’s weird that the F is missing from the end of the header in the rejection.
Thanks, let me see if I can get more information to a reproduce this issue, I’ll create a new ticket
Not sure if this is related to the same ticket or not, but when from.name includes the @ character, the injection fails:
{"success_count":0,"fail_count":1,"failed_recipients":["hf.farhad@gmail.com"],"errors":["hf.farhad@gmail.com: invalid header: 0: at line 1, in Eof:\nnoreply@email.ahasend.com <noreply@email.ahasend.com>\n ^__________________________\n\n\nstack traceback:\n\t[C]: in method 'from_header'\n\t/opt/kumomta/etc/policy/dkim_sign.lua:244: in upvalue 'do_dkim_sign'\n\t/opt/kumomta/etc/policy/dkim_sign.lua:423: in upvalue 'dkim_signer'\n\t[string \"/opt/kumomta/etc/policy/init.lua\"]:454: in function <[string \"/opt/kumomta/etc/policy/init.lua\"]:370>\n"]}
Payload:
{
"envelope_sender": "no-reply@email.ahasend.com",
"content": {
"text_body": "test",
"html_body": "test",
"subject": "sample subject",
"from": {
"email": "noreply@email.ahasend.com",
"name": "noreply@email.ahasend.com"
}
},
"recipients": [
{
"email": "hf.farhad@gmail.com",
"name": "hf.farhad@gmail.com"
}
]
}
I know this is an absurd corner case, the sender already knows their own name, and can even leave it empty, but received a report from a customer ![]()
Does this work when injected with SMTP?
Yes
Ok thanks. Then this points to UTF-8 handling in HTTP Injection. Will try to get some deeper testing done here