email package vs. mimify.mime_encode_header

[=?iso-8859-1?q?Ilpo_Nyyss=F6nen?=]

How do I do the same as mimify.mime_encode_header with the email
package?

The problem:

Python 2.3.2 (#1, Oct 11 2003, 11:13:40)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2
Type "help", "copyright", "credits" or "license" for more information.'=?iso-8859-1?q?Ilpo_Nyyss=F6nen_=3Cmy=40address=2Eexample=3E?='

That doesn't work when I put it in the headers.

 

[Tim Roberts]

How do I do the same as mimify.mime_encode_header with the email
package?

You split the address yourself into "nickname" and "address", then encode
only the "nickname" part and put the two back together.

Only the nickname is encoded.

The problem:

Python 2.3.2 (#1, Oct 11 2003, 11:13:40)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2
Type "help", "copyright", "credits" or "license" for more information.'=?iso-8859-1?q?Ilpo_Nyyss=F6nen_=3Cmy=40address=2Eexample=3E?='

That doesn't work when I put it in the headers.

Well, "Header" did exactly what you asked it to. Unfortunately, you didn't
ask it to what you wanted it to do.

 

[=?iso-8859-1?q?Ilpo_Nyyss=F6nen?=]

How do I do the same as mimify.mime_encode_header with the email
package?

You split the address yourself into "nickname" and "address", then encode
only the "nickname" part and put the two back together.

Only the nickname is encoded.
[...]

Well, "Header" did exactly what you asked it to. Unfortunately, you didn't
ask it to what you wanted it to do.

But with mimify doing the extra work is not necessary. And other point
is that the Header encodes the whole string and mimify encodes only
when necessary. This makes the encoded stuff more readable when looked
without decoding.

From my point of view this looks like dropping an important feature. I
really do not want to encode an ascii only header, but if the encoding
is needed, it needs to be there. With mimify this is handled
automatically, with Header I would need to do that by hand.

 

[Tim Roberts]

But with mimify doing the extra work is not necessary. And other point
is that the Header encodes the whole string and mimify encodes only
when necessary. This makes the encoded stuff more readable when looked
without decoding.

Nevertheless, the fact that mimify happens to produce a valid RFC-822
header is purely an accident, and relying on it could be considered a flaw.
The CORRECT procedure is to parse the address into separate tokens, and
encode only the nickname.

From my point of view this looks like dropping an important feature. I
really do not want to encode an ascii only header, but if the encoding
is needed, it needs to be there. With mimify this is handled
automatically, with Header I would need to do that by hand.

You OUGHT to be doing it by hand in both cases. You'll need to parse the
name anyway to get the addresses for SMTP.

 

[=?iso-8859-1?q?Ilpo_Nyyss=F6nen?=]

You OUGHT to be doing it by hand in both cases. You'll need to parse the
name anyway to get the addresses for SMTP.

OK, that might be true, but lets look the actually encoded parts:

Python 2.3.2 (#1, Oct 11 2003, 11:13:40)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2
Type "help", "copyright", "credits" or "license" for more information.'=?iso-8859-1?q?This_is_an_ascii_only_header?='

Encoding that is unnecessary. It is harder to read that as raw without
decoding.

It will cause problems in programs that do something automatically,
but do not decode it. A good example is filtering that is done based
on subject prefixes.

From my point of view the encoding done by the Header is unusable.

 

[Barry Warsaw]

You OUGHT to be doing it by hand in both cases. You'll need to parse the
name anyway to get the addresses for SMTP.

OK, that might be true, but lets look the actually encoded parts:

Python 2.3.2 (#1, Oct 11 2003, 11:13:40)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2
Type "help", "copyright", "credits" or "license" for more information.'=?iso-8859-1?q?This_is_an_ascii_only_header?='

Encoding that is unnecessary. It is harder to read that as raw without
decoding.

It will cause problems in programs that do something automatically,
but do not decode it. A good example is filtering that is done based
on subject prefixes.

From my point of view the encoding done by the Header is unusable.

I'm only seeing the tail end of this discussion, but you're not really
comparing apples to apples here. If you know the string going into your
header is ASCII, and you don't want it RFC 2047 encoded, then don't
provide a charset argument (or use the default == 'us-ascii'). I.e.
'This is an ascii only header'

mimify.mime_encode_header() really only helps you when the header is
Latin-1, otherwise you still need to know what charset you want to
encode the header to. Besides, mimify's CHARSET is a module global, so
that really sucks.

-Barry


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iQCVAwUAP5K6qnEjvBPtnXfVAQJ1agP5AdUeGzeer8fpdsaPOMvxkkVydid02EZX
fJfd6gyx+QSy+e1rbQSEx6+pjbaSG7cMdjqCXv7gEE0dUcGufjMabh7xxl7YOqvs
lnVjY1lmmhNfWzdqBqOfA5uFf2Mef3rJ9ZzGMIx7aJDU62yBJfphrPHnN7jRcR/z
sCwiGgyY+m0=
=hJjj
-----END PGP SIGNATURE-----

 

[=?iso-8859-1?q?Ilpo_Nyyss=F6nen?=]

I'm only seeing the tail end of this discussion, but you're not really
comparing apples to apples here. If you know the string going into your
header is ASCII, and you don't want it RFC 2047 encoded, then don't
provide a charset argument (or use the default == 'us-ascii'). I.e.

But I do not know it.

The point really is that the encoding should be done in such way that
only the minimum amount is encoded. Now it always encodes the whole
given text. And mimify does it like I want. (But it doesn't handle
other charsets, so is not that way enough.)

mimify.mime_encode_header() really only helps you when the header is
Latin-1, otherwise you still need to know what charset you want to
encode the header to. Besides, mimify's CHARSET is a module global, so
that really sucks.

Yes, I need to know the charset, but the Header should not encode the
whole string. It should encode just the parts that need it.

Python 2.3.2 (#1, Oct 11 2003, 11:13:40)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2
Type "help", "copyright", "credits" or "license" for more information.'=?iso-8859-1?q?foo_b=E4r_baz?='

 

[Barry Warsaw]

Yes, I need to know the charset, but the Header should not encode the
whole string. It should encode just the parts that need it.

That might be an interesting option. Feel free to file a request in the
Python SourceForge tracker, or bring it up on the email-sig. It might
be something we'll want to add for email 3.0.

-Barry


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iQCVAwUAP5PgiHEjvBPtnXfVAQLkugP8CCXC4wpfQtTghbbxTOlZ4ekbKSaHCFoh
9CtYgjdFvIFimUEpeSywyglthVIkBy4XDAHQJhi34bgwppiNSfsgCzHwZCdTb4Er
zl6mvD09Z02BQK01htL/6jWQOUh6RQDNAIC6yKbA2Iqr+6eHlbDC+2wk8hBMxnGs
tL4gJWToG58=
=fAjx
-----END PGP SIGNATURE-----

 

[Tim Roberts]

The point really is that the encoding should be done in such way that
only the minimum amount is encoded.

Maybe, but that's just one opinion. What if there are several special
characters separated around the string? Do you include the =?iso-8859-1?q?
string several times, or do you enclose the whole string? That's a
difficult decision to make.

Plus, in the final analysis, those encoded headers are not particularly
designed for human consumption, anyway. The assumption is that a mailer at
the other end is going to convert the name into something in the native
character set for presentation. Given that, it seems kind of silly to try
to optimize the encoding anyway.