Should quirks enabling really be compile-time?

[ajanvrin]

After reading the code a bit, there's something that bothers me slightly.

imap-codec goes a long way to be strictly standards-compliant, but then you added compile-time quirks to deal with other non-standards-compliant MTA.
Doesn't that defeat the purpose a bit?

I mean, someone who wants a truly standards-compliant imap-codec can compile it from source disabling quirks, but that's out of reach of most users.

I think, there would be value in a standards-compliant cli tool like himalaya, based on imap-codec, that would be able to degrade to a "lenient" mode at run time, perhaps through a cli flag.

Granted, this value would be rather niche, I guess it would mostly be valuable for MTA developers, as a testing means. And these MTA developers would be able to build himalaya and imap-codec from source, if they really want to.

Anyways, I know making it a run-time flag would require a large amount of work, I only wanted to share that thought. Certainly, if you want to implement such a change, it will become harder as imap-codec grows.

[duesee]

Hey @ajanvrin! You basically said everything relevant :-) Allowing quirks at runtime would complicate imap-codec quite a bit. This is why I would avoid it.

My experience so far with keeping quirks as a feature is that it helped a few people already in finding and fixing violations in their code. We did this by compiling w/o the quirks and shoveling traces through the parsers pinpointing some offending messages.

I think that the right way for imap-codec could be to keep the feature-flags, allow all quirks by default, and emit warnings when violations are detected. We have one or two quirks already where it was necessary to do a more fundamental change, e.g., when a server reported a length of "-1" we needed to rectify to "0" to not reproduce the fault. In this case we emit a warning but this is not done for minor quirks -- maybe it should.