email package vs. mimify.mime_encode_header

**Tim Roberts** · Jul 18 '05, 03:41 AM

Re: email package vs. mimify.mime_enc ode_header

iny+news@iki.fi (Ilpo Nyyssönen) wrote:[color=blue]
>
>How do I do the same as mimify.mime_enc ode_header with the email
>package?[/color]

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.
[color=blue]
>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.[color=green][color=darkred]
>>>> import mimify
>>>> mimify.mime_enc ode_header('Ilp o Nyyssönen <my@address.exa mple>')[/color][/color]
>'Ilpo =?ISO-8859-1?Q?Nyyss=F6nen ?= <my@address.exa mple>'[color=green][color=darkred]
>>>> from email.Header import Header
>>>> Header('Ilpo Nyyssönen <my@address.exa mple>', 'iso-8859-1').encode()[/color][/color]
>'=?iso-8859-1?q?Ilpo_Nyyss= F6nen_=3Cmy=40a ddress=2Eexampl e=3E?='
>
>That doesn't work when I put it in the headers.[/color]

Well, "Header" did exactly what you asked it to. Unfortunately, you didn't
ask it to what you wanted it to do.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

**Tim Roberts** · Jul 18 '05, 03:55 AM

Re: email package vs. mimify.mime_enc ode_header

iny+news@iki.fi (Ilpo Nyyssönen) wrote:[color=blue]
>[color=green]
>> Well, "Header" did exactly what you asked it to. Unfortunately, you didn't
>> ask it to what you wanted it to do.[/color]
>
>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.[/color]

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.
[color=blue]
>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
>automaticall y, with Header I would need to do that by hand.[/color]

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.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

**Ilpo Nyyssönen** · Jul 18 '05, 04:00 AM

Re: email package vs. mimify.mime_enc ode_header

Tim Roberts <timr@probo.com > writes:
[color=blue][color=green]
>>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.[/color]
>
> 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.[/color]

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.[color=blue][color=green][color=darkred]
>>> import mimify
>>> mimify.mime_enc ode_header('Thi s is an ascii only header')[/color][/color][/color]
'This is an ascii only header'[color=blue][color=green][color=darkred]
>>> from email.Header import Header
>>> Header('This is an ascii only header', 'iso-8859-1').encode()[/color][/color][/color]
'=?iso-8859-1?q?This_is_an_ ascii_only_head er?='

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.

--
Ilpo Nyyssönen # biny # /* :-) */

**Barry Warsaw** · Jul 18 '05, 04:00 AM

Re: email package vs. mimify.mime_enc ode_header

On Sun, 2003-10-19 at 05:06, Ilpo Nyyssönen wrote:[color=blue]
> Tim Roberts <timr@probo.com > writes:
> [color=green][color=darkred]
> >>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.[/color]
> >
> > 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.[/color]
>
> 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.[color=green][color=darkred]
> >>> import mimify
> >>> mimify.mime_enc ode_header('Thi s is an ascii only header')[/color][/color]
> 'This is an ascii only header'[color=green][color=darkred]
> >>> from email.Header import Header
> >>> Header('This is an ascii only header', 'iso-8859-1').encode()[/color][/color]
> '=?iso-8859-1?q?This_is_an_ ascii_only_head er?='
>
> 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.
> [color=green]
> >From my point of view the encoding done by the Header is unusable.[/color][/color]

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.
[color=blue][color=green][color=darkred]
>>> from email.Header import Header
>>> Header('This is an ascii only header').encode ()[/color][/color][/color]
'This is an ascii only header'

mimify.mime_enc ode_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)

iQCVAwUAP5K6qnE jvBPtnXfVAQJ1ag P5AdUeGzeer8fpd saPOMvxkkVydid0 2EZX
fJfd6gyx+QSy+e1 rbQSEx6+pjbaSG7 cMdjqCXv7gEE0dU cGufjMabh7xxl7Y Oqvs
lnVjY1lmmhNfWzd qBqOfA5uFf2Mef3 rJ9ZzGMIx7aJDU6 2yBJfphrPHnN7jR cR/z
sCwiGgyY+m0=
=hJjj
-----END PGP SIGNATURE-----

**Ilpo Nyyssönen** · Jul 18 '05, 04:02 AM

Re: email package vs. mimify.mime_enc ode_header

Barry Warsaw <barry@python.o rg> writes:
[color=blue]
> 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.[/color]

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.)
[color=blue]
> mimify.mime_enc ode_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.[/color]

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.[color=blue][color=green][color=darkred]
>>> import mimify
>>> mimify.mime_enc ode_header('foo bär baz')[/color][/color][/color]
'foo =?ISO-8859-1?Q?b=E4r?= baz'[color=blue][color=green][color=darkred]
>>> from email.Header import Header
>>> Header('foo bär baz', 'iso-8859-1').encode()[/color][/color][/color]
'=?iso-8859-1?q?foo_b=E4r_b az?='

--
Ilpo Nyyssönen # biny # /* :-) */

**Barry Warsaw** · Jul 18 '05, 04:03 AM

Re: email package vs. mimify.mime_enc ode_header

On Mon, 2003-10-20 at 01:21, Ilpo Nyyssönen wrote:
[color=blue]
> 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.[/color]

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)

iQCVAwUAP5PgiHE jvBPtnXfVAQLkug P8CCXC4wpfQtTgh bbxTOlZ4ekbKSaH CFoh
9CtYgjdFvIFimUE peSywyglthVIkBy 4XDAHQJhi34bgwp piNSfsgCzHwZCdT b4Er
zl6mvD09Z02BQK0 1htL/6jWQOUh6RQDNAIC 6yKbA2Iqr+6eHlb DC+2wk8hBMxnGs
tL4gJWToG58=
=fAjx
-----END PGP SIGNATURE-----

**Tim Roberts** · Jul 18 '05, 04:04 AM

Re: email package vs. mimify.mime_enc ode_header

iny+news@iki.fi (Ilpo Nyyssönen) wrote:[color=blue]
>
>The point really is that the encoding should be done in such way that
>only the minimum amount is encoded.[/color]

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.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

email package vs. mimify.mime_encode_header

email package vs. mimify.mime_encode_header

Comment

Comment

Comment

Comment

Comment

Comment

Comment