On Thu, Jun 06, 2024 at 08:38:48AM +0100, Vsevolod Stakhov via mailop wrote:
> > Such willful disregard of essential interoperability requirements in
> > "rspamd" means I will not use it unless you back off from your current
> > position, and will strongly discourage others (e.g. postfix-users list
> > readers) from using it. I've heard "rspamd" otherwise has some
> > appealing features, but this is show-stopper. :-(
> >
>
> I'm sorry but I do not accept the interoperability argument in this context.
> Rspamd is not an MTA - it is a spam filtering system.
It is also, IIRC, a DKIM *signer* and verifier. DKIM signing and
verification needs to interoperate.
> Hence, it has to work *somehow* with broken and non-conformant emails.
> I've seen so many messages with bad mime structure, bad headers
> encoding, broken received traces etc.
To a degree, but not to the point of accepting total garbage
(RFC2047-encoded DKIM-Signature headers), or especially, generating
total garbage (producing RFC2047-encoded DKIM-Signature headers).
> What I wanted to say by this message is that complications in the standards
> lead to ambiguity in the implementations (as they , which, in turn, lead to
> the possibilities for spammers to exploit those implementation issues. I'm
> not even talking about the standard that are ambiguous by design, e.g. DKIM
> simple canonicalization.
I am well aware of the issues. I wrong a MIME-normaliser circa Y2K that
too questionable MIME in, and produced unambiguous MIME out. But
unambiguous did not mean bending over backwards to accommodate total
garbage. Rather, in many cases, just neuter it so that downstream tools
are not going to be confused. And certainly, not to produce output that
violates the specs.
--
Viktor.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
