On 12/23/2016 04:29:11 PM, Albrecht Dreß wrote:
Hi all,
a while ago we introduced obfuscated message-id headers (see bugzilla
#738155 and related messages in the balsa list).
The message-id now is basically a base64-encoded hash value, which
may contain the '+' and '/' characters explicitly allowed by RFC
5322. However, I noticed that if a DSN is requested, some MTA's seem
to use this message-id verbatim as ENVID parameter (see RFC 3461).
In this parameter, though, the '+' character is /not/ allowed and
must be escaped. As a result, the receiving MTA /may/ reject the
message if the ENVID contains an unescaped +.
Although this is a bug in the sending MTA, IMO it would be better to
adjust the way the message-id is created. The attached patch uses
the first 240 bits (30 bytes) of the random hash to create a somewhat
formatted, base32-encoded message-id (see e.g. in this message).
Opinions?
The goal seems sane. Have you got an idea how often the unwarranted
rejection occurs?
Pawel
_______________________________________________
balsa-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/balsa-list
