jothan / rustyknife Goto Github PK

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?

Is it possible to parse AUTH commands as well?

For example, sending mail to a local serving using the following command fails because SMTP AUTH extension not supported by server:

import smtplib
from email.mime.multipart import MIMEMultipart
from email.mime.text import MIMEText

# SMTP server details
smtp_server = "localhost"
smtp_port = 8025

# Sender and recipient details
sender = "[email protected]"
recipient = "[email protected]"

# Create a message object
message = MIMEMultipart()
message["From"] = sender
message["To"] = recipient
message["Subject"] = "Test email"

# Add message content
message.attach(MIMEText("This is a test email.", "plain"))

# Connect to the SMTP server with TLS
smtp_obj = smtplib.SMTP(smtp_server, smtp_port)
smtp_obj.starttls()  # Enable TLS

# Send the email
smtp_obj.login(sender, "some_password") # <--- THIS LINE BREAKS THE SERVER
smtp_obj.sendmail(sender, recipient, message.as_string())

# Disconnect from the server
smtp_obj.quit()

print("Email sent successfully!")

Hi, I've just successfully integrated rustyknife into samotop as a second parser. I'd like to make it the default and swap out the PEG parser I've written.

One thing I'm missing is the LHLO command so that server can serve local delivery. With that perhaps also SEND, SOML SAML variants of MAIL to be feature complete for rfc821.

I suspect it should be trivial to add as the syntax is otherwise identical with EHLO/MAIL.

It would be simpler for me to include code under BSD or MIT. Would you be open to switch the current GPL license to BSD/MIT? Thanks

Hey,

do you have an opinion on reformatting the code to match common code style?

I could run

$ cargo fmt -- --config imports_granularity=Crate

and open a PR. But as this changes a lot, you might probably prefer to do it yourself and be sure that I havn't introduced bad code on the way ;-)

For me this would be helpful, because I always use the format on save feature of my IDE to speed up coding. Parts which should not be subject to reformatting can also be annotated with #[rustfmt::skip]. What do you think?

Thank you for your amazing work, btw!