--KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Berry! Thanks for your prompt answer! > Actually, because the email package was designed to be used with > something like smtplib for the actual sending of the message to an > SMTP server, it always uses native line endings. It's the job of [...] Got it.. > smtplib to convert from native to RFC 2821 line endings (and in fact, > it does just that!). Similarly, your mail server would be responsible > for converting from RFC 2821 line endings to native line endings if it > were going to store a message in a mailbox, for example, that you'd > want to parse using email.Parser. That made me wonder how signed messages would be rebuilt to their original state so that they could be checked at the other side. The answer is obvious: they don't. That breaks an old precept I used to have. Signed content *may* differ in some aspects from the original content. At least EOLs are modifiable. > I'll make sure this is clarified in the email package's documentation. Thanks. > GN> As a side note, I'd like to suggest the inclusion of some kind > GN> of "raw_input". There are cases where you want to see the raw > GN> message (or just part of it), instead of regenerating it. This > GN> happens, for example, when you want to check a signed > GN> multipart message. >=20 > I'm not sure I understand what you mean by "raw_input". Do you mean > something like the HeaderParser class? Let me try again. Here's how multipart signed message works: you have two parts, one is the whole signed message (maybe another multipart message, perhaps with more signatures), the other is the signature. In order to check if the second part is a good signature for the first part, it must contain exactly the same thing as it used to have when the signature was created (besides EOLs ;-). Something like a Message.raw_input could be used in these cases. You'd still have the same structure as you have now, with the headers, and the parsed payload. But the message, and more important, the payload of each multipart message (which is a message, of course), would contain the original and unparsed content of that part. Since this information is redundant, this behavior could be turned on with an option. Unfortunately, if I understood the algorithm correctly, HeaderParser wouldn't help in that case for two reasons: first, the header structure must stay intact as well; and second, you still want to walk into multiparts. I'm thinking about using something like this for an email bot I'm working on. Users will have to authenticate themselves trough gpg. Of course, maybe I'm the only human being wanting something so bizzare, so if you choose not to implement, I'll understand. :-) Creating a custom parser won't be hard as well. Thank you! --=20 Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ] --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE79d52IlOymmZkOgwRAjncAKCR8owJkIP7TuO34UL29SzDVRiXEACePZtm tWXcMp+7NNv+89XYqWhBtP0= =t0+8 -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy--
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4