[Python-Dev] Re: CRLF in email.Generator

[Gustavo Niemeyer]

--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--