search

duesee / smtp-codec

Parsing and construction of SMTP messages
Apache License 2.0
6 stars 2 forks source link

Figure out guidelines for misuse-resistant types. #8

Open duesee opened 2 years ago

duesee commented 2 years ago

Having misuse-resistant types is (mostly) an all or nothing approach. Thus, the first thing would be to agree on this approach. The second thing would be to document it. More specifically, we would start to call the possibility to instantiate an invalid type a bug and treat it like so, i.e., resolve it.

Sometimes, however, there are many options to tighten a type with different pros and cons and it may not be obvious what to do.

There are also libraries for tight types that may be useful.

We should discuss and document this approach somewhere to reduce friction and make best use of this approach.

djc commented 2 years ago

My first question is: what's in scope of misuse-resistance? You seem to be focused on round-tripping at the parser/encoder level. How about what's semantically legal in terms of the standard? How much complexity do we allow in pursuit of misuse-resistance? How do we value robustness versus strictness?

duesee commented 2 years ago

what's in scope of misuse-resistance? You seem to be focused on round-tripping at the parser/encoder level. How about what's semantically legal in terms of the standard?

Part of why I would like to split-off an smtp-types crate is to focus solely on the standards. Ideally, smtp-types would become a strongly-typed version of the SMTP standard with as much "domain knowledge" encoded in the types as possible. (For example, that reply codes are all the same.)

I don't care too much about the parsers itself. It would be great If someone would, for example, implement a high-performance, or formally-verified SMTP parser leveraging the "collected knowledge" in smtp-types.

How much complexity do we allow in pursuit of misuse-resistance?

That's a tough one. I can only speak from personal experience with a somewhat "toy"e project without strict deadlines. My feeling is that even in cases where you have to define a handful of new types upfront the misuse-resistancy will pay out sooner than later for library developers. My concern would be more with API consumers but I have yet to find a case that would be convincing enough to relax tightness.

I also speculate a bit that SMTP is easier to handle than IMAP.

Having said that... if we can't reasonably provide misuse-resistance, i.e., because it would decrease usability (or developer happiness :-)), we would need to work around that. But keeping this property should certainly be high in the priority list.

How do we value robustness versus strictness?

Let's do what imap-proto does. Be strict until there is a good reason not to be. Email clients and servers have quirks. If we can't reasonably change something else -- looking at you, Microsoft -- we should evaluate how to do it in smtp-codec.