Moin, On Thu, 2024-06-06 at 12:44 +1000, Viktor Dukhovni via mailop wrote: > The distinction is essential, because it would be a terrible mistake > to, for example, RFC2047-encode the "mailbox" construct in "From", > "To", ... headers. An RFC2047-ignorant MUA or MTA can still > correctly decode the addresses in those headers without caring about > the display name encoding.
Kind of a point; However, if I got John correctly, an SMTPUTF8 mail having to go through a system that does not support it should simply bounce? On Wed, 2024-06-05 at 11:00 +0200, John R Levine via mailop wrote: > Nope. You cannot downgrade a SMTUTF8 message to an ASCII message. > The experimental versions of EAI tried to do that and it never worked > so they took it out of the standards track EAI RFCs. To be fair... if my students working on 'normal' security stuff complain about things being to confusing, inconsistent, and complex... I threaten them with the proposition that they could _also_ be working on DNS. If those working on DNS complain, I suggest they could also do BGP instead. Now, if the ones working on BGP complain, I threaten them with the prospect of working on mail. And if the ones working on mail complain... I usually just say "I'm sorry; At least look at the bright side: It can't get worse." ;-) (This is a joke.) On Thu, 2024-06-06 at 12:44 +1000, Viktor Dukhovni via mailop wrote: > It seems to me, that you may not have thought through the issues > deeply enough. I would, indeed, argue that this issue has a few more facets that need to be discussed; With some of those potentially being somewhat supportive of Vsevolod's point. On Thu, 2024-06-06 at 12:44 +1000, Viktor Dukhovni via mailop wrote: > On Wed, 2024-06-05 at 17:29 +0100, Vsevolod Stakhov via mailop wrote: > > As Rspamd author, I will not change the existing logic, as it works > > with headers as with black boxes making the following steps: unfold > > -> rfc2047 decode -> process specific data. > > This, IMNSHO, is not a reasonable stance to take... I am not so sure, at least IMSSANSMBLAHSIDTO (in my somewhat-stupid- and-not-so-my-but-looking-at-how-some-implementations-do-this opinion) the sketched approach is also how, e.g., Python handles RFC2047 headers. In fact, it was somewhat messy to convince python to rewrite an RFC2047-ized DKIM header to not mime encoded text, as the email module would read the header correctly, print it in ASCII/UTF8, but writes it back mime encoded (this is for email-security-scans.org; So a specific case sometimes requiring doing weird things not advisable anywhere else, i.e., here the rewriting.). On Thu, 2024-06-06 at 12:44 +1000, Viktor Dukhovni via mailop wrote: > Such willful disregard of essential interoperability requirements... To be fair, rspamd was the _more_ interoperable mail handling software in this case. > I've heard "rspamd" otherwise has some appealing features, but this > is show-stopper. :-( It does. Especially when it comes to DKIM (ed25519 support, not injecting funny whitespaces breaking signatures), ARC (well, it _does_ ARC, contrary to many other implementations), DMARC reporting (which also tends to be more slim in other implementations) etcetc. And, contrary to many other milters, it is really scalable. So, personally, big fan of rspamd. So, the stance, which I would abbreviate as 'in case of doubt, I do anything to get an email reliably processed and delivered' is not only Vsevolod's; In fact, Gmail--for example--also tends to be 'a bit more lenient' to get an (outbound) email delivered. Including, up until recently, 'ignore DNSSEC being broken' (even though that _does_ seem to have changed, at least when testing this morning; Or it is attached to a timer for a domain, i.e., if a domain has been seen with working DNSSEC for $time, it starts to get enforced; Anyway, tangential.). My point here is, that 'deliverability' is often more of a priority for ESPs than 'following all documents to the letter'. Granted, for the bigger ones, usually more like 'outbound deliverability' than 'inbound deliverability', though. Hence, I am not completely sure if the stance is outright unreasonable, even if it disagrees with the documents. After all, the 'drift' between documents and 'what is being done on the wire' has been getting larger for some time already. And if I have the choice between 'no commits for six years' (OpenDKIM; Good candidate for next xz, imho, btw.), 'something involving python' (dkimpy), and rspamd, I am somewhat inclined to use rspamd, i.e., there is not that many alternatives to recommend, when recommending people not to use rspamd. (The last comment is observational concerning that drift, and not a suggestion to outright change the documents, a call for rspamd to change, or a statement in support for either direction; I am marveling the problem, suggesting that this drift might need some discussion (again), and ultimately, some form of approach to fix it.) With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
