Scope of this project?

[Ekleog]

Hello,

I've just recently come across rustyknife, and it looks really nice :) I'm considering dropping my own SMTP parsing library in favor of rustyknife, as you appear to have already implemented things that were in the long list of things I still have to do.

This being said, I wonder a bit about the scope of rustyknife: is it's only aim to parse the things that are useful for an SMTP receiver (as appears to be currently implemented), or would you be open to (PRs) adding support for parsing SMTP replies, as well as generation of SMTP commands and replies based on the data?

Also, my current code, while not at all able to do all the parsing you do, makes sure it doesn't allocate. How would you feel about making the parsing commands generic on their types, so that it would become possible to use Bytes instead of &[u8] and String? The drawback of this approach is, that in the &[u8] approach, the return value would be eg. Email<Vec<u8>> instead of Email, and to get the current Email one would have to call .to_string() or similar. The idea is that the data would just be validated at parsing time, and then when someone wants to actually recover the data in a format that's not just for relaying to another SMTP server, it would get converted and allocated.

As all of that would certainly result in pretty wide-spread changes, I'd like to get feedback from you before starting work on this :) (also, full disclosure: I can't guarantee I'll be timely to deliver the API changes -- the ones that interest me most right now are the SMTP parsing series, though they're also the ones I've actually already implemented with my noalloc parser I still haven't upgraded from nom3; so I'd most likely be pretty fast in doing the port of those, but would also likely be much slower to port the other parsers to the new generic API)

So… what do you think about all these ideas? Do you think they are in-scope or out-of-scope for this project?

[jothan]

I'd say go ahead for submitting a PR for SMTP client side parsing. Not allocating is not currently a goal for this project, rather it is to provide rich data structures that encode the subtleties of email parsing. I have made a conscious effort to avoid needless copies and allocations and some parts are zero-copy internally. I am open to code that would improve on the number of allocations though.

That said, I am still ambivalent about a few points:

• Unification of SMTP and internet mail format address types.
• Header folding/unfolding: in the current state of affairs, comments are eliminated from the output and folding whitespace is returned folded. It would be nice to avoid losing information for it to be possible to have lossless roundtripping.
• nom error handling in general.
• using streaming instead of complete parsers in certain cases.

In the current state of affairs, rustyknife is used in my day job for an internal SMTP server based on smtpbis and to provide a support Python module for other internal tools. I would say the focus for the library is to be robust, correct and modern in that order.

I am not great at designing APIs, don't hesitate to submit any code that makes your life easier. Adding more syntax is definitively in scope.

Thanks for your time and interest,
Jonathan

[Ekleog]

Well, thank you for making your code public in the first place! I'll start seeing what I can do as soon as I have some time, and see if I can make an API that'd be OK with us both :) (just a disclaimer that I'm doing this on my personal time, not work time, so there's no real timeline guarantee)