[2010-12-07 12:33] Jon Steinhart <jon(_at_)fourwinds(_dot_)com>
Still trying to understand this. Decided to finally look at the code instead
of
relying on my fading memory.
:-) Thanks.
The existing code takes a non-ASCII message body and sends it as an attachment
of type application/octet-stream.
Your patch changes this behavior so that it is sent as type text/plain with
the
appropriately chosen character set.
Both correct.
In order to do this, you test the message body for non-ASCII characters in
attach(). If you find any, you write an entry directly into the composition
file instead of calling make_mime_composition_file_entry().
Correct.
This is changing existing behavior if I understand it correctly.
Behavior in what gets generated, yes, but this is of need when fixing
things.
Examples for what gets generated from mail *body text*:
The old code generates ...
... for ASCII:
Content-Type: text/plain; name="sendKi9x7j"; x-unix-mode="0644";
charset="us-ascii"
Content-ID: <4962(_dot_)1289589671(_dot_)1(_at_)argentina(_dot_)foo>
Content-Description: ASCII text
foo
... for non-ASCII (only if at least one attachment is present):
Content-Type: application/octet-stream; name="sendbRaV8T";
x-unix-mode="0644"
Content-ID: <5209(_dot_)1289589999(_dot_)1(_at_)argentina(_dot_)foo>
Content-Description: UTF-8 Unicode text
Content-Transfer-Encoding: base64
d2l0aCBKb24....
With my patch such MIME parts are generated ...
... for ASCII:
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5048(_dot_)1289589784(_dot_)1(_at_)argentina(_dot_)foo>
foo
... for non-ASCII:
Content-Type: text/plain; charset="UTF-8"
Content-ID: <5260(_dot_)1289590069(_dot_)1(_at_)argentina(_dot_)foo>
Content-Transfer-Encoding: quoted-printable
Umlauts: =C3=A4 and =C3=B6 and =C3=BC.
The function make_mime_composition_file_entry() gives us nothing but
information we don't need/want (temp file names, file permissions) and
it definately does not use the best possible CT and CTE for the body
text.
This is fine
with me provided that users must explicitly enable the change using an option.
An option to activate a fix???
Now that I'm actually looking at the code, I would suggest an option
(choose a better name) of binary-body-content-type. You could change the
make_mime_composition_file_entry() line
content_type = binary ? "application/octet-stream" : "text/plain";
to replace the "application/octet-stream" with the option value, or the
existing
value as a default if the option is not specified.
A user wanting this behavior would have a profile entry of
binary-body-content-type: text/plain
I think that this would be a simpler code change that would accomplish your
goal.
Sorry, but I really think you don't get the point. We don't need
config options if we already have the facilities to do it right
automatically. Why should any user need to tell nmh what content type
to use for the text he writes? The mhbuild facility can already find
out which is appropriate. My patch also divides between mail text and
attachments for which different things are relevant. Your comment
above does this not and would then use binary-body-content-type for
any non-ASCII attachment also.
I read your mails and ask myself if you really read what I write and
if you have had a look into the code we are talking about.
I very much value the work you did for nmh and you see that this patch
bases on what you created, but now it may be to point to either have a
close look at the problem and code or step back and let other people
talk. I do think you don't understand the situation and the relavant
code good enough (presumably due to lack of time).
Of course, I may be wrong. Currently, however, it rather seems to me
as if it's not me who is not understanding the whole thing. I really
spent much time in the code and doing tests. And I did my best
explaining everything.
I ask other people to take a look and express their opinion.
meillo
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers