>>>>> "GN" == Gustavo Niemeyer <niemeyer@conectiva.com> writes:
GN> Hello Barry!!
Hello Gustavo!
GN> First, I'd like to thank you for implementing the email
GN> package. It seems very complete and will be useful for sure.
Thanks!
GN> I've been looking at the Generator module. It seems to be
GN> writing the message with:
GN> print >> self._fp, "text"
GN> This should probably be replaced by:
GN> self._fp.write("text"+"\r\n")
GN> Print's end of line will depend on the system where python is
GN> being run. If you run it in Linux, it will output just a
GN> "\n". This breaks RFC2822:
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
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.
I'll make sure this is clarified in the email package's documentation.
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.
I'm not sure I understand what you mean by "raw_input". Do you mean
something like the HeaderParser class?
Cheers,
-Barry
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