multipart/alternative

[Nick Wilson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

'ello
What kind of monster is would a message containing multipart/alternative
be? Is there somewhere that gives idiots guides to mime types?

Cheers...
- -- 

Nick Wilson

Tel:+45 3325 0688
Fax:+45 3325 0677
Web:www.explodingnet.com



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

iD8DBQE8TyrwHpvrrTa6L5oRAsfHAKC1nv2xXD7VXtplYFnLREckpB/zgwCdG6L0
G76LcgMG9xppQK018yKKFfc=
=7zCx
-END PGP SIGNATURE-

multipart/alternative formatting

[Anton Graham]

There seems to be some "funkiness" in the handling of
multipart/alternative messages.  In particular, the attachments
which are Content-Type: text/plain and Content-Transfer-Encoding:
quoted-printable.  These frequently come from Outlook (Express) users.

This is how mutt displays a single line of the message:

i'm using linux mandrake about 3 month it like me, the firts time install LM in
+a machine with Win98, now i want to install it with WinNT,


This is how the same line looks in the message:

i'm using linux mandrake about 3 month it like me, the firts time =
install LM in a machine with Win98, now i want to install it with WinNT,

The '=' sign is a sort of "soft-return" that gets dropped in the
decoding process, resulting in abnormally long lines.

At present, I am dealing with the problem via procmail (see below),
but I guess my question is, "Shouldn't these soft returns be preserved
by the receiving client (i.e. mutt)?"

# Force multipart/alternative to appropriate column widths
:0
* ^Content-Type.*multipart/alternative
{
:0 fbBw
* ^Content-Transfer-Encoding:.*quoted-printable
| sed -e "s/=$//g"
}

-- 
   _
 _|_|_
  ( )   *Anton Graham
  /v\  / <[EMAIL PROTECTED]>
/(   )X
 (m_m)   GPG ID: 18F78541
Penguin Powered!

Re: multipart/alternative

[JT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 23 Jan 2002, Nick Wilson wrote:
> 'ello
> What kind of monster is would a message containing multipart/alternative
> be? Is there somewhere that gives idiots guides to mime types?

multipart alternative messages are those which have multiple renditions 
(say text and html) of the exact same content.

As to an idiots guide to mime types, I don't think so.  The best you can 
get is ... 'read the RFCs' and 'pray' :)

- --JT

- -- 
[-]
[ Practice random kindness and senseless acts of beauty.  ]
[ It's hard to seize the day when you must first grapple with the morning ]
[-]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8T08OlZQYYI16LJQRApi2AKCRE++hz03th0J6Dy6KBrjscNjYYgCgw41N
/FGPO2WF/C6jKojahfydteU=
=r9t9
-END PGP SIGNATURE-

Re: multipart/alternative

[David Champion]

On 2002.01.23, in <[EMAIL PROTECTED]>,
    "Nick Wilson" <[EMAIL PROTECTED]>
wrote:
> 'ello
> What kind of monster is would a message containing multipart/alternative
> be? Is there somewhere that gives idiots guides to mime types?
It's a multipart type that provides multiple alternative views of what
the sender alleges to the the same content, using two different presentation
types. For example, I can send you a message in text and HTML by
using a multipart/alternative part containing within its envelope a text/plain
part and a text/html part.
 
(But, as you see, I can hoodwink you by placing
different material in one part than in the other.)
--
 -D.    [EMAIL PROTECTED]   
NSIT    University of Chicago
 

Re: multipart/alternative

[Nick Wilson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* and then JT blurted
> As to an idiots guide to mime types, I don't think so.  The best you can 
> get is ... 'read the RFCs' and 'pray' :)

Yeah. Thanks guys, reason I asked was that I've gotten a couple of odd
mails from one of the w3c lists i'm on. multipart/alternative and when I
open if it's just full of stuff that looks very much like a pgp sig,
only *much* longer?

- -- 

Nick Wilson

Tel:+45 3325 0688
Fax:+45 3325 0677
Web:www.explodingnet.com



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

iD8DBQE8T8UzHpvrrTa6L5oRAuk7AJ9lCbdyTb8LUB4BdChYzHxLgdc8jACeOlVK
8UtrpHceJ4fer8AI6iH/Bkk=
=JR+r
-END PGP SIGNATURE-

Re: multipart/alternative

[JT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 24 Jan 2002, Nick Wilson wrote:
> Yeah. Thanks guys, reason I asked was that I've gotten a couple of odd
> mails from one of the w3c lists i'm on. multipart/alternative and when I
> open if it's just full of stuff that looks very much like a pgp sig,
> only *much* longer?

Sounds like someone sent a part that got base-64 encoded.  There should be 
something like a filename or some information in the Content-headers for 
that part which tell you something about it.

- --JT

- -- 
[-]
[ Practice random kindness and senseless acts of beauty.  ]
[ It's hard to seize the day when you must first grapple with the morning ]
[-]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8UEBplZQYYI16LJQRAujxAJ0ds+fW6ldAQ8PgD6KT3xQe7GsnLgCeP2yS
feEATbpmw/Zvqs5k26jOFDQ=
=BHoi
-END PGP SIGNATURE-

Re: multipart/alternative

[Nick Wilson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* and then JT blurted
> Sounds like someone sent a part that got base-64 encoded.  There should be 
> something like a filename or some information in the Content-headers for 
> that part which tell you something about it.

Yes, it was base-64 encoded.
- -- 

Nick Wilson

Tel:+45 3325 0688
Fax:+45 3325 0677
Web:www.explodingnet.com



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

iD8DBQE8UEIkHpvrrTa6L5oRAk1DAJ9y8G4PfEbs1srBek1d808AN0BXBgCghzEL
m0Qkdq8X3pcYLj/bTHbAbAA=
=lkYI
-END PGP SIGNATURE-

create multipart/alternative

[Sebastian Tramp]

Hi mutt users,

is it possible to create mulitpart/alternative message parts in the compose
screen?

I need to write text/html mails (please don't ask ...) as
multipart/alternative. My idea is to write markdown with vim and then convert
it to text/html and add it to the message. Currently I'm using this macro for
this:

macro compose 'M' "cat >~/.cache/mutt/md2html.md && cat 
~/.cache/mutt/md2html.md | markdown 
>~/.cache/mutt/md2html.html~/.cache/mutt/md2html.html"

It works fine but the html part is not included as an alternative part for the
text/plain part.

There exists some post send filter to achieve this but they do not work in
combination with encryption (and I do not have the sent copy in my archive)

Another idea: Is it possible to put the complete message to a tool from the
compose screen (which can parse and change it completely) and re-read it
afterwards? I thinks is would allow a lot of other feature too.

Best regards

Sebastian Tramp

-- 
WebID: http://sebastian.tramp.name


pgpwGyJmdp77u.pgp
Description: PGP signature

multipart/alternative question

[Tim Gray]

I have my alternative_order set to text/plain text/html.  All works as 
expected.  However I have some people who use a mailer (Apple Mail) that 
send multipart/alternative messages with attachments.  So the two parts of 
the message are a text/plain and a multipart/mixed.  The multipart/mixed 
consists of said file attachment and a text/html part.  Since mutt is set to 
prefer text/plain, all I see is the plain text message, with no indication 
that there is an attachment (or even an html part).


I don't know if this is normal behavior for multipart/alternative messages 
with attachments, or a quirk of Apple Mail.  I would have thought that the 
text/plain and text/html part of the messages should make up the multi/alt 
part, with other file attachments living at the same level as the multi/alt 
part, not buried in *one* of the alternative components


So, what is the best way to deal with this?  Is there anyway to just prefer 
the text/plain but look for attachments in the text/html branch?  Or have an 
indication that there is a text/html branch onscreen so I know to look 
there?  Or is the only route to set my alternative_order to prefer text/html 
first...


Thanks

Re: multipart/alternative formatting

[David T-G]

Anton --

...and then Anton Graham said...
% 
% There seems to be some "funkiness" in the handling of
% multipart/alternative messages.  In particular, the attachments
% which are Content-Type: text/plain and Content-Transfer-Encoding:
% quoted-printable.  These frequently come from Outlook (Express) users.

... and that's because they are most frequently the ones who need the
most help.  Even though it's marked text/plain, that doesn't mean that
LookOut! users aren't depending on their mailer to autoformat their lines
based on fluctuating window width and such...


% 
% This is how mutt displays a single line of the message:
% 
% i'm using linux mandrake about 3 month it like me, the firts time install LM in
% +a machine with Win98, now i want to install it with WinNT,

Right; that '+' char is to let you know that mutt had to break the line
for display but it's actually connected to the apparent one above.  See
sections 6.3.80 and 6.3.181 of the manual.


% 
% 
% This is how the same line looks in the message:
% 
% i'm using linux mandrake about 3 month it like me, the firts time =
% install LM in a machine with Win98, now i want to install it with WinNT,

Yep; that's the Q-P encoding.


% 
% The '=' sign is a sort of "soft-return" that gets dropped in the
% decoding process, resulting in abnormally long lines.

Well, yes and no; it indicates that the mailer which sent it had to break
the line there because it wanted to try to keep it at a reasonable
length, and mutt [properly] reassembles the lines into one long one.


% 
% At present, I am dealing with the problem via procmail (see below),
% but I guess my question is, "Shouldn't these soft returns be preserved
% by the receiving client (i.e. mutt)?"

The answer is that they are :-)


% 
% # Force multipart/alternative to appropriate column widths
% :0
% * ^Content-Type.*multipart/alternative
% {
% :0 fbBw
% * ^Content-Transfer-Encoding:.*quoted-printable
% | sed -e "s/=$//g"

Are you sure that that shouldn't be "s/= $//" (and you certainly don't
need the /g if you're targeting the end of the line!)?  When I have q-p
messages whose lines have been broken, that's what I get...


% }
% 
% -- 
%_
%  _|_|_
%   ( )   *Anton Graham
%   /v\  / <[EMAIL PROTECTED]>
% /(   )X
%  (m_m)   GPG ID: 18F78541
% Penguin Powered!

HTH & HAND


:-D
-- 
David T-G   * It's easier to fight for one's principles
(play) [EMAIL PROTECTED]  * than to live up to them. -- fortune cookie
(work) [EMAIL PROTECTED]
http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg!
The "new millennium" starts at the beginning of 2001.  There was no year 0.
Note: If bigfoot.com gives you fits, try sector13.org in its place. *sigh*


 PGP signature

Re: multipart/alternative formatting

[Anton Graham]

On Fri, 14 Jul 2000, David T-G wrote:

> ... and that's because they are most frequently the ones who need the
> most help.  

Of course :p

> Even though it's marked text/plain, that doesn't mean that LookOut!
> users aren't depending on their mailer to autoformat their lines
> based on fluctuating window width and such...

I still think that text/plain should be just that: plain :)
 
> Right; that '+' char is to let you know that mutt had to break the line
> for display but it's actually connected to the apparent one above.  See
> sections 6.3.80 and 6.3.181 of the manual.
 
Yes, I understand that, and appreciate it when receiving preformatted
data as it shows me that the line is a continuation of the previous
without requiring me to scroll right through a 230 character line.

> % 
> % # Force multipart/alternative to appropriate column widths
> %:0
> % * ^Content-Type.*multipart/alternative
> % {
> %:0 fbBw
> % * ^Content-Transfer-Encoding:.*quoted-printable
> % | sed -e "s/=$//g"
> 
> Are you sure that that shouldn't be "s/= $//" (and you certainly don't
> need the /g if you're targeting the end of the line!)?  When I have q-p
> messages whose lines have been broken, that's what I get...


Actually, the '=' seems to be hanging at the end without a trailing
space on the ones I receive.  (And you're right, I don't need the /g,
it's there through force of habit :)

-- 
   _
 _|_|_
  ( )   *Anton Graham
  /v\  / <[EMAIL PROTECTED]>
/(   )X
 (m_m)   GPG ID: 18F78541
Penguin Powered!

 PGP signature

Re: multipart/alternative formatting

[Byrial Jensen]

On Fri, Jul 14, 2000 at 21:00:21 -0700, Anton Graham wrote:

> I still think that text/plain should be just that: plain :)

It is.

The Quoted Printable encoding must not have lines longer than 76
characters, and the encoder have to insert the soft breaks when
it encodes longer lines then that. The receiving end must remove
these soft breaks to recreate the original long line. See RFC
2045 section 6.7 for a precise description of this.

> Yes, I understand that, and appreciate it when receiving preformatted
> data as it shows me that the line is a continuation of the previous
> without requiring me to scroll right through a 230 character line.

In fact there is a proposal for a standard to send plain text in
which each paragraph may be rewrapped by the receiving MUA. It
uses the context type "text/plain; format=flowed". Mutt doesn't
support this, but it may be a good idea to implement it.

"The Text/Plain Format Parameter" is described in RFC 2646.

> Actually, the '=' seems to be hanging at the end without a trailing
> space on the ones I receive.  (And you're right, I don't need the /g,
> it's there through force of habit :)

There should not be trailing space on any line encoded with
Quoted Printable, and if the decoder anyhow sees trailing space
on a line, it must delete it. Mutt's QP decoder is unfortunately
buggy with respect to this.

-- 
Byrial
http://home.worldonline.dk/~byrial/

Re: multipart/alternative formatting

[Suresh Ramasubramanian]

Byrial Jensen proclaimed on mutt-users that:

>which each paragraph may be rewrapped by the receiving MUA. It
>uses the context type "text/plain; format=flowed". Mutt doesn't
>support this, but it may be a good idea to implement it.
>"The Text/Plain Format Parameter" is described in RFC 2646.

The only MUAs I've seen generating this header are  Eudora Pro 4.x,
Netscape 6 / Mozilla and MSN Hotmail.

-- 
Suresh Ramasubramanian + [EMAIL PROTECTED]
The first myth of management is that it exists.  The second myth of
management is that success equals skill.
-- Robert Heller

Sending multipart/alternative attachments

[Gary Johnson]

I've RTFM and haven't seen a way for mutt to send (not display)
multipart/alternative attachments.  Is there an external program that
can be used with mutt to do this?  I was considering using an existing
message as a template, but I thought I read where the boundary string
has to be unique and I'd rather not have to guess at a unique sequence
and edit the boundary manually.  Besides, it would be much easier to
have the attachments assembled automatically and after all, that's what
computers are for.

Before this degenerates into a discussion of "Why would you ever want to
do that?" and "Mail should be text/plain":  The reason I want this is
that as secretary for an organization, I need to regularly distribute a
form to the members.  The form was written as a Word document, and I'm
sure that most members would like it in that format, but I would like to
also distribute a text/plain version.

Thanks,
Gary

-- 
Gary Johnson   | Agilent Technologies
[EMAIL PROTECTED]   | Spokane, Washington, USA
http://www.spocom.com/users/gjohnson/mutt/ |

Re: create multipart/alternative

[David Champion]

* On 27 Feb 2014, Sebastian Tramp wrote: 
> Hi mutt users,
> 
> is it possible to create mulitpart/alternative message parts in the compose
> screen?

This patch adds what you need:
https://bitbucket.org/dgc/mutt-dgc/raw/42d6f8d629ad3f0ceb7f4790013d3cec665d0df6/dgc.groupalts

The  binding for the componse menu (where you press
's' to send) combines selected attachments into a multipart/alternative
group.  The  and  bindings then allow you to change
their order.

> 
> There exists some post send filter to achieve this but they do not work in
> combination with encryption (and I do not have the sent copy in my archive)
> 
> Another idea: Is it possible to put the complete message to a tool from the
> compose screen (which can parse and change it completely) and re-read it
> afterwards? I thinks is would allow a lot of other feature too.

I don't know offhand how you would generate the content.  MIME is not
that hard to write if you know the structure, but I don't know a tool
off the top of my head that will generate it for you.  However, if you
have one: a trick I have used for things of this flavor is to:

* postpone the message
* open your postponed folder as a regular mutt mailbox
* find the postponed message
* edit the raw mesage
* save
* sync
* go back to your regular mutt session
* recall the postponed message
* finish and send

(It's not as hard as it looks on paper.  Usually I do this when I find
I've written a trmendously long message and I want to split it into
two messages.  In that case, after editing the message I exit without
syncing in order to preserve both copies of the original, then I recall
and send each copy.)

-- 
David Champion • d...@bikeshed.us

Re: create multipart/alternative

[Sebastian Tramp]

On Thu, Feb 27, 2014 at 07:18:31AM -0600, David Champion wrote:

> > is it possible to create mulitpart/alternative message parts in the compose
> > screen?
> 
> This patch adds what you need:
> https://bitbucket.org/dgc/mutt-dgc/raw/42d6f8d629ad3f0ceb7f4790013d3cec665d0df6/dgc.groupalts

Great! Thanks a lot. Will try it and give feedback later ...

> The  binding for the componse menu (where you press 's'
> to send) combines selected attachments into a multipart/alternative group.
> The  and  bindings then allow you to change their order.

Sounds like its possible to do exactly what I want with this.

> > There exists some post send filter to achieve this but they do not work in
> > combination with encryption (and I do not have the sent copy in my archive)
> > 
> > Another idea: Is it possible to put the complete message to a tool from the
> > compose screen (which can parse and change it completely) and re-read it
> > afterwards? I thinks is would allow a lot of other feature too.
> 
> I don't know offhand how you would generate the content. MIME is not that
> hard to write if you know the structure, but I don't know a tool off the top
> of my head that will generate it for you.

Since I would like to add more than just a html alternative based on markdown
(e.g. semantic annotation of parts of the message) - I will not use a ready
tool but a library. I've experimented with the Swift Mailer PHP Library and its
easy enough to use to have fast results.

> However, if you have one: a trick I have used for things of this flavor is
> to: * postpone the message * open your postponed folder as a regular mutt
> mailbox * find the postponed message * edit the raw mesage * save * sync * go
> back to your regular mutt session * recall the postponed message * finish and
> send

Do you think this can be encoded in a macro?

Best regards

Sebastian Tramp

-- 
WebID: http://sebastian.tramp.name

Re: create multipart/alternative

[Mark H. Wood]

On Thu, Feb 27, 2014 at 07:18:31AM -0600, David Champion wrote:
> I don't know offhand how you would generate the content.  MIME is not
> that hard to write if you know the structure, but I don't know a tool
> off the top of my head that will generate it for you.

I would try maildrop's 'makemime' tool.

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Machines should not be friendly.  Machines should be obedient.


signature.asc
Description: Digital signature

Re: multipart/alternative question

[lee]

On Wed, Jul 15, 2009 at 11:02:38PM -0400, Tim Gray wrote:
> So, what is the best way to deal with this?  Is there anyway to just 
> prefer the text/plain but look for attachments in the text/html branch?  
> Or have an indication that there is a text/html branch onscreen so I know 
> to look there?

And more general, is there a way to get an indication that a mail does
have an attachment or attachments? I would give them a different color
in the list; that would prevent me from opening such messages without
checking them before.

Other than that, if I get a mail that isn't readable, I delete it. If
someone sends me a mail but makes it difficult to read, he obviously
doesn't care if I read it or not, so why should I waste my time with
it.

Re: multipart/alternative question

[Tim Gray]

On Wed 15, Jul'09 at 10:08 PM -0600, lee wrote:

And more general, is there a way to get an indication that a mail does
have an attachment or attachments? I would give them a different color
in the list; that would prevent me from opening such messages without
checking them before.


You could set up a coloring rule using the ~X matching pattern.  Something 
like:


color index red default "~X 1-"

should work.  You can also use the %X sequence in your index_format 
definition to display the number of attachments in a message.  However, I 
don't think either of those methods pick up on inline attachments.



Other than that, if I get a mail that isn't readable, I delete it. If
someone sends me a mail but makes it difficult to read, he obviously
doesn't care if I read it or not, so why should I waste my time with
it.


Unfortunately I have collaborators whom I must work with who aren't 
particularly email savvy.  I can't just toss their emails.

Re: multipart/alternative question

[lee]

On Thu, Jul 16, 2009 at 12:31:26AM -0400, Tim Gray wrote:
> On Wed 15, Jul'09 at 10:08 PM -0600, lee wrote:
>> And more general, is there a way to get an indication that a mail does
>> have an attachment or attachments? I would give them a different color
>> in the list; that would prevent me from opening such messages without
>> checking them before.
>
> You could set up a coloring rule using the ~X matching pattern.  
> Something like:
>
> color index red default "~X 1-"
>
> should work.

Hm, I was reading the manual, and there's an object "attachment" that
can be used with "color". But I don't understand what that is for:


color attachment brightred black


doesn't do what I thought it might.

> You can also use the %X sequence in your index_format  
> definition to display the number of attachments in a message.  However, I 
> don't think either of those methods pick up on inline attachments.

Hm, I would expect that attachments are attachments and count as
such ...


  I 1   [multipa/alternativ, 7bit, 2.0K]
  I 2 > [text/plain, quoted, iso-8859-1, 0.7K]
  I 3 > [text/html, quoted, iso-8859-1, 1.0K]
  I 4   [text/plain, 7bit, us-ascii, 0.2K]


For that one, %X says the mail has 1 (one) attachment. But apparently
it has 4 attachments, so what's %X for?

>> Other than that, if I get a mail that isn't readable, I delete it. If
>> someone sends me a mail but makes it difficult to read, he obviously
>> doesn't care if I read it or not, so why should I waste my time with
>> it.
>
> Unfortunately I have collaborators whom I must work with who aren't  
> particularly email savvy.  I can't just toss their emails.

Perhaps you can help them to fix their MUAs? If you can find out if
what they are doing is compliant with RFCs or not, you could act
accordingly. Unfortunately that's a difficult task, but if they are
compliant, you need to change something on your side.

It's hard to examine the problem without having an example email
... What happens when you notice that you got such a mail and have
mutt display what attachments there are? Can you view the attachments
from there?

Re: multipart/alternative question

[Tim Gray]

On Wed 15, Jul'09 at 11:59 PM -0600, lee wrote:

Hm, I was reading the manual, and there's an object "attachment" that
can be used with "color". But I don't understand what that is for:


That colors the attachment in message display, like this:

[-- Attachment #1 --]
[-- Type: multipart/alternative, Encoding: 7bit, Size: 3.7K --]

would show up as colored.


Hm, I would expect that attachments are attachments and count as
such ...


 I 1   [multipa/alternativ, 7bit, 2.0K]
 I 2 > [text/plain, quoted, iso-8859-1, 0.7K]
 I 3 > [text/html, quoted, iso-8859-1, 1.0K]
 I 4   [text/plain, 7bit, us-ascii, 0.2K]


For that one, %X says the mail has 1 (one) attachment. But apparently
it has 4 attachments, so what's %X for?


Well, on my setup it counts attachments that aren't inlined, i.e. A. 
However I see in the manual there is an attachments command which lets you 
configure what is counted.  I need to read up on it but it might answer some 
of my questions.



Perhaps you can help them to fix their MUAs? If you can find out if
what they are doing is compliant with RFCs or not, you could act
accordingly. Unfortunately that's a difficult task, but if they are
compliant, you need to change something on your side.


Once I figure out a bit more I'll probably send a bug report to Apple. 
It'll probably be easier to get them to change it then to get all the users 
of Apple Mail to change.



It's hard to examine the problem without having an example email
... What happens when you notice that you got such a mail and have
mutt display what attachments there are? Can you view the attachments
from there?


Yes I can do that.  It's more of an issue of not realizing there is an 
alternative view, and since the attachment is buried in that alternative,  I 
don't realize it's there.  If I hit 'v' and look, it all shows up.


Playing around last night, I see if I set add 'multipart/related 
multipart/mixed' to the front of my alternative order, it does pick up these 
messages from Apple Mail and display them.

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wednesday, July 15 at 11:02 PM, quoth Tim Gray:
> I have my alternative_order set to text/plain text/html.

So do I.

> However I have some people who use a mailer (Apple Mail) that send 
> multipart/alternative messages with attachments.

How bizarre.

> Since mutt is set to prefer text/plain, all I see is the plain text 
> message, with no indication that there is an attachment (or even an 
> html part).

First, of course there's no obvious indication that there's an html 
part. Why should there be? Unless you press v to view the MIME 
hierarchy of the message, mutt doesn't tell you about alternative 
components to your email.

As for an indication that there is an attachment... what do you mean 
by "indication"? Do you mean some sort of inline thing like mutt does 
for more usefully structured emails? Because you CAN put %X in your 
$pager_format string to let you know how many attachments there are in 
the current email.

> I don't know if this is normal behavior for multipart/alternative 
> messages with attachments, or a quirk of Apple Mail.

It's a quirk of Apple Mail.

The thing is that Apple realized that the concept of an "attachment" 
is somewhat artificial, given how MIME works. So they started building 
messages as multipart/alternative where you could put "attachments" in 
the middle of text blocks. And when they send a TEXT message, this 
works just fine. However, from what I can tell, when someone composes 
an HTML message, Apple Mail falls down on the conversion job, and 
rather than maintain the original (for example, 
htmlpart-filepart-htmlpart) structure, it simply glues the html parts 
together, and builds a single alternative text version of the whole 
message. It's technically correct, but not especially useful.

> I would have thought that the text/plain and text/html part of the 
> messages should make up the multi/alt part, with other file 
> attachments living at the same level as the multi/alt part, not 
> buried in *one* of the alternative components

If they did that, mutt would certainly be happier, yes.

> So, what is the best way to deal with this?  Is there anyway to just 
> prefer the text/plain but look for attachments in the text/html 
> branch?  Or have an indication that there is a text/html branch 
> onscreen so I know to look there?  Or is the only route to set my 
> alternative_order to prefer text/html first...

It depends on what you're going for. I recommend an attachment counter 
in $pager_format.

~Kyle
- -- 
Whenever you have an efficient government, you have a dictatorship.
  -- Harry Truman, lecturing at Columbia University, April 28, 1959
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKXzMkAAoJECuveozR/AWetyYP/3Jq3FGE9iFngrKqteXBwvfD
pjoW1Qxt39Ncer26d7CPLu9R37A/HEcX1ClZqF2467EyZgYgqcjHhdcSUG5vTNPJ
IK34TgCWX35zxIP4J78MKXVldP0xjtnl/jcTZiXZ8B98T402nWFLn6Ik3q3Y9q7l
9SOGyQRE0PiWwWDjtwsnMNz1CZ3qicR/S/KcA6BXGRIbSpk7TLl5XofbH5Mkm24b
qUT3LtV1Oq7cTdBo0WCrHE8GDmsYU/s2m+4PA93AKPN7r1CTwK23xKaFcsYE/NfH
/wMsKAkgj+lfXXNZShnBCaP6ID0UQ9xF2UCxdQIBBoxqbZtQntg3o4YH+WlK6Ev1
85t7tLwoTMMxWx1r81pqKVyCNAxZGTlH5AYOnY3p0HJVFPDIAEDlwHQT6flJAJ8O
tcLODohXLuaP1Twna99DSShpc+QSJef6ZXa7V5U5sqVIC5I82Yiz/FEnVfsWBmtC
8BTqawNCpnun/Ij+dpGVmHjg2uOsaKL20fm1jXH529pplPgYxKReUW2Eb1zbm0yM
NV9xg3PgQe850/DVM6KGwuLuFXL7D3n3Fr56jUw5DMiqGeorw9HbNRJHFfPg1ZI4
0N7ABCSkjfHC8n/KM54R/zENNp59MrAKFxyr7Tbv9Ih5pnz6lr3XmXLpEbNQA93+
8CdRuN0OKg4Ugsm+BmW7
=7eHI
-END PGP SIGNATURE-

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wednesday, July 15 at 11:59 PM, quoth lee:
>> You can also use the %X sequence in your index_format definition to 
>> display the number of attachments in a message.  However, I don't 
>> think either of those methods pick up on inline attachments.
>
> Hm, I would expect that attachments are attachments and count as 
> such ...

The definition of "attachment" is not as clear as you would think. For 
example, we tend to think of MIME components whose type is text/* as 
not being "attachments", but sometimes they can be (e.g. if I sent you 
a txt file). The same problem exists with pictures in GUI mailers: 
they can display the picture, or treat it as a file, or both. This is 
what RFC 2813 (the Content-Disposition header) is designed to help 
with. And when multipart/alternative is involved... it gets nutty.

>  I 1   [multipa/alternativ, 7bit, 2.0K]
>  I 2 > [text/plain, quoted, iso-8859-1, 0.7K]
>  I 3 > [text/html, quoted, iso-8859-1, 1.0K]
>  I 4   [text/plain, 7bit, us-ascii, 0.2K]
>
>
> For that one, %X says the mail has 1 (one) attachment. But apparently 
> it has 4 attachments, so what's %X for?

Here's a wacky message structure my mom sent me (using Apple Mail):

 I   1 [multipa/alterna, 7bit, 653K]
 I   2 |-> [text/plain, utf-8, 2.0K]
 I   3 `-> [multipa/mixed, 7bit, 651K]
 I   4   |->   [text/html, quoted, windows-1252, 3.0K]
 I   5   |->Typeface Ideas.pdf [applica/pdf ...]
 I   6   `->   [text/html, 7bit, us-ascii, 0.2K]

I haven't set up attachment detection properly, so %X says this 
message has 0 attachments.

Details of how this works and why it's hard are here: 
http://www.mutt.org/doc/devel/manual.html#attachments

> If you can find out if what they are doing is compliant with RFCs or 
> not, you could act accordingly. Unfortunately that's a difficult 
> task, but if they are compliant, you need to change something on 
> your side.

It *is* (or at least, can be) compliant.

~Kyle
- -- 
Arguing with an engineer is like wrestling with a pig in mud, after a 
while you realize the pig is enjoying it.
 -- Unknown
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKXzbiAAoJECuveozR/AWeaP8P/Rwy5pNNGsYF1z18i3mnV+lz
qUH0msZ+/EyG/zpSOKHZFNCADT9AXvN1nWp6uRzolYwJccsz2hTCGAk9GxlYM4uB
YZow4vHAXpJ3Opk7q1aHOk6eg3U7nPUPKCGTA2FjNYaJNVavsQ00JhfAeqxfwrDF
kBq3YSJBxXK5rLh+Eikpu9hMQUL6ZKDtd+bDgEA+oRAmWejovN57AHaQ+jDbkwBd
POiu7aVbKslfy/ftNRkTR5NiUg2RQBPoVx/YeELjezNUx25wvvppufVu65dpi20I
mF/SSNu/q0BYPb91jozi8u2m123a1xIqHMZyKtfJjfOsiLTUuCg4DyeysiyW3P8b
vrQw3ajWSEBv7+sDjFi99tMOq9+k5G+Uz2tDuDApI5qJwpiTjN4MVIXrEq8d5KbP
znb3l4Nt4E2QGSK36CXP/NGbIk0PxD37tpDKHv3YcK3++SzJmP54QSLedi7lDVND
PaB7lKMdMwMcL+qBb0tMa7lHopHwNVV0mphPssDmPCZY/zv8fBHd0ve4NePtq0VE
Ciej5z62xBjSrYN8CmzIR6FjLsg6A1RwGQAQDYib+GlNsfNHjtL7E7lkOL9IbFhj
GVH4i3wdSAyIhvdNk+wCdfdmG7mbAMT5piMOwcOWyDAvsGUFxcwg36+ZnlYk63tL
PIqaZoZX9Cx6bhd8t7Dx
=W066
-END PGP SIGNATURE-

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thursday, July 16 at 08:17 AM, quoth Tim Gray:
> Playing around last night, I see if I set add 'multipart/related 
> multipart/mixed' to the front of my alternative order, it does pick 
> up these messages from Apple Mail and display them.

Huh! Interesting solution...

~Kyle
- -- 
A lot of the truths we cling to depend greatly on our own point of 
view.
  -- Obi Wan Kenobi
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKXzdMAAoJECuveozR/AWedw4QAIVE8oZa7gc28DIs//r5m0mN
OB5Xqxw1rRox6ln8A0RFhsDoe42NZKDTHtkhQ+eUqH3QtqUmxJNPh+sSuA9HmESk
cKyK6oYvLesF5TSxR6Re756dVA/hfX1fPRfWKRFvGondbanLo863dpkBLu606Dv1
hscY3b+K9XcQV/tqQiU0s//96EpS868FbJBSF4iRoV92GoWtZ83Mp9i5L9X/MZij
KPQIFc/eYeFL8FkKu1lumxSJMn43/4yOrPxBtQ5bpvkzOTaQaAWrIRm+VPNVQlo+
4eA3OZfLX55VJhcGFWYq4Sg6OLB4Od31+aPhvcXJHXC421d4XcDMlIkS6HZM33l+
MKcOpVhHRzgvi2sXTMnz6Yw8XG5vKRAcziEwMkpmWklE1ci/Ntp4ARVJTtpHsZjQ
m4Wmv0Bdx4gALSflqPfzj//LpN1a5KahOTayvfHPFta9ajupuqhgiQlDk746CeU0
LJ9AXL+08CK8YAQtccN3t9bCmlMukxhJ+Rc4Ey0Ps3iaoOzZsLl2NWsi3pU8k38U
HjjGwJj6py4Il7XdT+H4K0ettXwQgDowpGuIbA9AWPA+augRzxqa3xwcx7lYGsbu
u0Ha5q0RHHI32PI0z0QjopH7MJuwyLMEXdHd0igi7hC3do1akeNnzUmv9bmjyGB3
ah+dt6uBxyLusthucE8L
=VbL3
-END PGP SIGNATURE-

Re: multipart/alternative question

[Tim Gray]

On Thu 16, Jul'09 at  9:19 AM -0500, Kyle Wheeler wrote:

Here's a wacky message structure my mom sent me (using Apple Mail):

I   1 [multipa/alterna, 7bit, 653K]
I   2 |-> [text/plain, utf-8, 2.0K]
I   3 `-> [multipa/mixed, 7bit, 651K]
I   4   |->   [text/html, quoted, windows-1252, 3.0K]
I   5   |->Typeface Ideas.pdf [applica/pdf ...]
I   6   `->   [text/html, 7bit, us-ascii, 0.2K]

I haven't set up attachment detection properly, so %X says this message has 
0 attachments.


Details of how this works and why it's hard are here: 
http://www.mutt.org/doc/devel/manual.html#attachments


This is exactly what I'm dealing with.  Though sometimes it's not 
multipart/mixed but multipart/relative.  Regardless, I was not able to set 
up attachment detection properly to pick up the application/pdf.


attachments +I application/.*

was not enough.

Re: multipart/alternative question

[Tim Gray]

On Thu 16, Jul'09 at  9:03 AM -0500, Kyle Wheeler wrote:
It depends on what you're going for. I recommend an attachment counter in 
$pager_format.


I didn't realize this was there.  I think that's what I was asking for. 
Thanks.


I'll also start hitting them with some bug reports.  I have an outlet for 
that, so I might actually get to interact with some engineers on the matter.

Re: multipart/alternative question

[David Champion]

* On 16 Jul 2009, Tim Gray wrote: 
> >
> >I   1 [multipa/alterna, 7bit, 653K]
> >I   2 |-> [text/plain, utf-8, 2.0K]
> >I   3 `-> [multipa/mixed, 7bit, 651K]
> >I   4   |->   [text/html, quoted, windows-1252, 3.0K]
> >I   5   |->Typeface Ideas.pdf [applica/pdf ...]
> >I   6   `->   [text/html, 7bit, us-ascii, 0.2K]
> 
> This is exactly what I'm dealing with.  Though sometimes it's not
> multipart/mixed but multipart/relative.  Regardless, I was not able
> to set up attachment detection properly to pick up the
> application/pdf.

It's actually not possible in this case.  Message and multipart are the
two major MIME categories which are containers.  All other types are
atomic, but these two always exist to contain other components (which
may themselves be atomic or containers).  The attachment-counting
algorithm has a flag that decides whether to traverse (recurse) the
container types while looking for attachments that qualify by your
"attachments" rules.

Multipart/alternative containers are specifically excluded from ever
being traversed.  Why?  Because mutt at this stage has no way of knowing
which alternative in a multipart/alternative you want looked at.  It
either needs to count all attachments within the multipart/alternative,
which is most assuredly exactly the thing you least want, or it needs
to guess which alternative represents the view that you want counted.
So it ignores multipart/alternatives.

However, I think that when mailers are behaving well, that's a fine
decision.  How often should an attachment that you're truly interested
in actually be part of the multipart/alternative enclosure?  I would
argue that Apple's arrangement here, while valid MIME, is not a faithful
representation of what the sender intended to send.  She has a letter
with an inlined PDF in the middle of it.  If Apple Mail is honoring
her intent, the children of the mp/alternative part should be two
multipart/mixed parts, each containing two text parts with a PDF
sandwiched in the middle.  It eats space (unless you cite content by
reference, as with cid: naming), but what Apple Mail has done excludes
the PDF content from visibility in the text/plain view.  So does that
exist as an "attachment" or not?  It depends on whether you're reading
text or HTML.

The best combination of efficiency and accuracy for this message would
have been:

multipart/mixed
|-> multipart/alternative
| |-> multipart/mixed
| | |-> text/plain
| | |-> application/pdf (reference, no content)
| | `-> text/plain
| `-> multipart/mixed
|   |-> text/html
|   |-> application/pdf (reference, no content)
|   `-> text/html
`-> application/pdf (referent)

... but mutt doesn't support cid: references, so this wouldn't help
us. :/

If you have ideas for how mutt could deal with this conundrum in a way
that's compliant, consistent, and user-centered, I'm interested to hear.
I'm not sure whether I'll have time to update the code, but it would be
good to get the ideas onto the table.

-- 
 -D.d...@uchicago.eduNSITUniversity of Chicago

Re: multipart/alternative question

[Tim Gray]

On Thu 16, Jul'09 at 10:49 AM -0500, David Champion wrote:

The best combination of efficiency and accuracy for this message would
have been:

multipart/mixed

-> multipart/alternative

-> multipart/mixed

-> text/plain
-> application/pdf (reference, no content)

`-> text/plain

`-> multipart/mixed
  |-> text/html
  |-> application/pdf (reference, no content)
  `-> text/html

`-> application/pdf (referent)

... but mutt doesn't support cid: references, so this wouldn't help
us. :/

If you have ideas for how mutt could deal with this conundrum in a way
that's compliant, consistent, and user-centered, I'm interested to hear.
I'm not sure whether I'll have time to update the code, but it would be
good to get the ideas onto the table.


Unfortunately, I interact with a lot of people who use Apple Mail.  And I'm 
not sure what the default setting is in it, but I think it's to prefer rich 
text (html).  So there are a lot of people out there sending out problematic 
messages.

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thursday, July 16 at 10:49 AM, quoth David Champion:
> The attachment-counting algorithm has a flag that decides whether to 
> traverse (recurse) the container types while looking for attachments 
> that qualify by your "attachments" rules.
>
> Multipart/alternative containers are specifically excluded from ever 
> being traversed.  Why?  Because mutt at this stage has no way of knowing 
> which alternative in a multipart/alternative you want looked at.

Well, it's not an issue of "which alternative I want to look at", 
because even if the attachment counter obeyed my alternative_order 
rules, I prefer to look at the text alternative.

> It either needs to count all attachments within the 
> multipart/alternative, which is most assuredly exactly the thing you 
> least want, or it needs to guess which alternative represents the 
> view that you want counted. So it ignores multipart/alternatives.

I think we can do better than that, by looking to the MIME RFC for 
guidance.

> How often should an attachment that you're truly interested in 
> actually be part of the multipart/alternative enclosure?  I would 
> argue that Apple's arrangement here, while valid MIME, is not a 
> faithful representation of what the sender intended to send.

I agree, to a point. The MIME RFC (1521) describes the 
multipart/alternative type with a recognition that the alternatives 
are not *equivalent*. To wit:

 As with multipart/mixed, the order of body parts is significant.
 In this case, the alternatives appear in an order of increasing
 faithfulness to the original content. In general, the best choice
 is the LAST part of a type supported by the recipient system's
 local environment.

By that logic, Apple is not even required to provide an especially 
faithful representation of the email in the first alternative, as long 
as it has a very faithful representation in the last alternative. 
Often we think that the difference is primarily formatting, but the 
RFC doesn't say that.

Thus, for attachment counting purposes, we can reasonably decide to 
ALWAYS count *only* the attachments within the last alternative in a 
multipart/alternative MIME section. That's the one that should best 
reflect the "original" content, and thus that's the one that best 
reflects the intention of the user. It's technically possible to have 
attachments in other parts of the multipart/alternative, but by 
definition they are supposed to be somewhat less-faithful 
representations of the sender's original content, and so I don't think 
they should count toward the grand attachment total. But any 
attachments in that last alternative *SHOULD* count.

If you want to add a config option to allow it to count ALL 
alternatives, that's fine by me, but I think counting only the last 
alternative is perfectly reasonable and compliant.

The thing I like about this idea is that if someone sends a 
multipart/alternative that has the attachment in an earlier component 
but not a later component, we can point to the RFC and say "you're 
doing it wrong; the LAST component is the one that's supposed to have 
all the fancy stuff." (I.e. the choice to count only the last 
alternative is a defensible one.)

> She has a letter with an inlined PDF in the middle of it.  If Apple 
> Mail is honoring her intent, the children of the mp/alternative part 
> should be two multipart/mixed parts, each containing two text parts 
> with a PDF sandwiched in the middle.

I think it all depends on what you mean by "intent". Another way of 
looking at it is that Apple sent me her original content, formatted 
exactly the way she wanted, and additionally sent me a text-like 
representation of what she sent, just in case I can't render HTML.

> but what Apple Mail has done excludes the PDF content from 
> visibility in the text/plain view.  So does that exist as an 
> "attachment" or not?  It depends on whether you're reading text or 
> HTML.

Granted, mutt will only *display* the attachment inline if you view 
the message as text/html, but whether it's displayed or not should 
have nothing to do with whether it counts as an attachment. I think t 
should counts as an attachment if a) I consider inlined PDFs to be 
attachments and b) it is in the last component of the 
multipart/alternative.

> The best combination of efficiency and accuracy for this message 
> would have been:
>
> multipart/mixed 
> |-> multipart/alternative 
> | |-> multipart/mixed 
> | | |-> text/plain 
> | | |-> application/pdf (reference, no content) 
> | | `-> text/plain 
> | `-> multipart/mixed 
> |   |-> text/html 
> |   |-> appl

Re: multipart/alternative question

[David Champion]

* On 16 Jul 2009, Kyle Wheeler wrote: 
> >
> > Multipart/alternative containers are specifically excluded from ever 
> > being traversed.  Why?  Because mutt at this stage has no way of knowing 
> > which alternative in a multipart/alternative you want looked at.
> 
> Well, it's not an issue of "which alternative I want to look at", 
> because even if the attachment counter obeyed my alternative_order 
> rules, I prefer to look at the text alternative.

I mean which alternative you want the attachment counter to look at.


> Thus, for attachment counting purposes, we can reasonably decide to 
> ALWAYS count *only* the attachments within the last alternative in a 
> multipart/alternative MIME section. That's the one that should best 
> reflect the "original" content, and thus that's the one that best 
> reflects the intention of the user. It's technically possible to have 

I think the RFC is leaves a lot of room for ambiguity, and this isn't
necessarily what anyone wants to happen, but I'll agree that it seems
like the most defensible last effort possible.

> If you want to add a config option to allow it to count ALL 
> alternatives, that's fine by me, but I think counting only the last 
> alternative is perfectly reasonable and compliant.

When this code was a patch, long back in the 1.3 days, there was a
means of instructing mutt how to descend containers while counting
attachments.  IIRC we decided to drop that in favor of simplicity.
It was more important to me to get the code pushed upstream than to
maintain options.


> The thing I like about this idea is that if someone sends a 
> multipart/alternative that has the attachment in an earlier component 
> but not a later component, we can point to the RFC and say "you're 
> doing it wrong; the LAST component is the one that's supposed to have 
> all the fancy stuff." (I.e. the choice to count only the last 
> alternative is a defensible one.)

Not necessarily.  The RFC says that if the alternatives are unequal
(whatever that might mean), then the last is the richest.  What if the
first is HTML with an inline addition, and the second is a PDF with all
content inlined within the PDF?  This isn't incorrect because the HTML
is not richer, fancier, or more faithful than the PDF.  It just requires
more parts (in this hypothetical case; certainly this is not necessary
for any hypothetical case.).


> I think it all depends on what you mean by "intent". Another way of 
> looking at it is that Apple sent me her original content, formatted 
> exactly the way she wanted, and additionally sent me a text-like 
> representation of what she sent, just in case I can't render HTML.

OK, instead of "intent" let me amend my previous statement to say "best
representation in an unintended encoding of what she meant for you to
see".  I don't think it changes anything dramatically.


> > The best combination of efficiency and accuracy for this message 
> > would have been:
> >
> > multipart/mixed 
> > |-> multipart/alternative 
> > | |-> multipart/mixed 
> > | | |-> text/plain 
> > | | |-> application/pdf (reference, no content) 
> > | | `-> text/plain 
> > | `-> multipart/mixed 
> > |   |-> text/html 
> > |   |-> application/pdf (reference, no content) 
> > |   `-> text/html 
> > `-> application/pdf (referent)
> 
> Yeah, but... that's so ugly and inefficient, I don't blame Apple for 
> sending a smaller, simpler message (that complies with the letter and 
> original spirit of the RFC).

It's not really.  Maybe it's ugly if you don't like looking at structure
documents and suddenly you have to, but this is very straightforward and
reasonable and not at all inefficient for a computer to process.  A MIME
boundary is very cheap.  Maybe it looks cleaner to consider it as:

















That's not very ugly or inefficient, as XML documents go.


> By the way... would mutt's attachment counting view that as three 
> attachments or only one? (Yes, I know multipart/alternatives are 
> ignored, but let's say the structure was flattened a bit.) In other 
> words, does mutt's attachment counting understand references?

Nothing in mutt understands references.  When being counted, a
MIME component is evaluated strictly by its Content-type and
Content-disposition.

-- 
 -D.d...@uchicago.eduNSITUniversity of Chicago

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thursday, July 16 at 01:40 PM, quoth David Champion:
>> Thus, for attachment counting purposes, we can reasonably decide to 
>> ALWAYS count *only* the attachments within the last alternative in 
>> a multipart/alternative MIME section. That's the one that should 
>> best reflect the "original" content, and thus that's the one that 
>> best reflects the intention of the user. It's technically possible 
>> to have
>
> I think the RFC is leaves a lot of room for ambiguity, and this isn't 
> necessarily what anyone wants to happen, but I'll agree that it seems 
> like the most defensible last effort possible.

Sure, I can swallow that. "Faithful to the original content" is... 
well, like you said, makes no guarantees about the content.

But here's the thing, I think the most important thing is to be able 
to distinguish between 0 and >0 attachments; it's less important to 
get the 1 vs 2 vs 30 attachments count exactly correct, because it's 
the 1-vs-0 count makes a mutt user decide to look at the mime 
structure. It'd be nice if we could make the attachment count perfect, 
but I think it's a bigger problem to mistakenly say there are zero 
attachments when in fact there is at least one and maybe more.

> It was more important to me to get the code pushed upstream than to 
> maintain options.

I can respect that.

>> The thing I like about this idea is that if someone sends a 
>> multipart/alternative that has the attachment in an earlier 
>> component but not a later component, we can point to the RFC and 
>> say "you're doing it wrong; the LAST component is the one that's 
>> supposed to have all the fancy stuff." (I.e. the choice to count 
>> only the last alternative is a defensible one.)
>
> Not necessarily.  The RFC says that if the alternatives are unequal 
> (whatever that might mean), then the last is the richest.  What if the 
> first is HTML with an inline addition, and the second is a PDF with all 
> content inlined within the PDF?  This isn't incorrect because the HTML 
> is not richer, fancier, or more faithful than the PDF.  It just requires 
> more parts (in this hypothetical case; certainly this is not necessary 
> for any hypothetical case.).

That's an excellent example! Let's be a bit more precise, just for 
argument's sake:

  I   1 [multipart/alternative]
  I   2 |-> [multipart/mixed]
  I   3 | |->   [text/html]
  I   4 | |->   [image/gif]
  I   5 | |->   [text/html]
  I   6 | |->   [image/gif]
  I   7 | |->   [text/html]
  I   8 | |->   [image/gif]
  I   9 | `->   [text/html]
  I  10 `-> [application/pdf]

The problem is that the current attachment counting code would look at 
that and report that there are ZERO attachments, when in fact there's 
at least one (the PDF) and maybe more (all the image/gifs).

I think we can make a reasonable argument that, based on the RFC, an 
attachment count of 1 is valid, if not perfect. There may be 
reasonable arguments to say whether a count of 1 or 3 or 4 attachments 
is more preferable. But I think it's absolutely indefensible (from a 
MIME-parsing perspective) to say that there are 0 attachments in such  
an email.

On the other hand, if we have a message structured like this:

  I   1 [multipart/alternative]
  I   2 |-> [multipart/mixed]
  I   3 | |->   [text/html]
  I   4 | |->   [image/gif]
  I   5 | |->   [text/html]
  I   6 | |->   [image/gif]
  I   7 | |->   [text/html]
  I   8 | |->   [image/gif]
  I   9 | `->   [text/html]
  I  10 `-> [text/plain]

I think we can make a pretty good argument to say that this is a 
poorly formed email (not that I can't imagine some really circuitous 
arguments along the lines of "the user wanted to send text/plain, so 
adding images was technically less-faithful"), and that in that case, 
our attachment counting is allowed to be wrong.

Here's another thought: perhaps the attachment count for a 
multipart/alternative should be the maximum of all of its components. 
Thus, in both this case and the previous case, the attachment count is 
3 (which is a reasonable value, if not a perfect one).

Of course, like I said, I'm more worried about incorrectly saying 
there are 0 attachments when there is in fact (at least) 1 than I am 
with incorrectly saying there are 3 attachments when there are in fact 
(depending on how you count) 4 or even just 1.

>>> The best combination of efficiency and accuracy for this message 
>>> would have been:
>>>
>>> multipart/mixed 
>>> |-> multipart/alternative 

Re: multipart/alternative question

[lee]

On Thu, Jul 16, 2009 at 09:19:14AM -0500, Kyle Wheeler wrote:
> On Wednesday, July 15 at 11:59 PM, quoth lee:
> >> You can also use the %X sequence in your index_format definition to 
> >> display the number of attachments in a message.  However, I don't 
> >> think either of those methods pick up on inline attachments.
> >
> > Hm, I would expect that attachments are attachments and count as 
> > such ...
> 
> The definition of "attachment" is not as clear as you would think. For 
> example, we tend to think of MIME components whose type is text/* as 
> not being "attachments", but sometimes they can be (e.g. if I sent you 
> a txt file).

Yeah, but mutt already has a way of showing a list of attachments. I
would simply count every entry in that list as an attachment. It
doesn't matter to me if a part is designated as inline --- other than
"inline" is confusing because when something is described as "inline",
one would think that it is inline and not an attachment.

If you have used the mail client built into Mozilla, it would
distinguish between forwarding messages inline vs. as attachment. And
inline was actually inline, while attachment was attachment.

So what's the difference between "inline" and "attachment"?


> Here's a wacky message structure my mom sent me (using Apple Mail):
> 
>  I   1 [multipa/alterna, 7bit, 653K]
>  I   2 |-> [text/plain, utf-8, 2.0K]
>  I   3 `-> [multipa/mixed, 7bit, 651K]
>  I   4   |->   [text/html, quoted, windows-1252, 3.0K]
>  I   5   |->Typeface Ideas.pdf [applica/pdf ...]
>  I   6   `->   [text/html, 7bit, us-ascii, 0.2K]
> 
> I haven't set up attachment detection properly, so %X says this 
> message has 0 attachments.

All the attachments of this message are designated inline. But you can
even set


attachments +A */.*
attachments +I */.*


and mutt doesn't count attachments that are inline. (Imho, there's no
such thing as an "inline attachment". Something is either attached or
inline, and it cannot be both. Creating mails with inline attachments
is silly.)

> Details of how this works and why it's hard are here: 
> http://www.mutt.org/doc/devel/manual.html#attachments

This doesn't explain why inline attachments aren't counted even when
you make them qualify as attachments?

Re: multipart/alternative question

[lee]

On Thu, Jul 16, 2009 at 01:14:22PM -0500, Kyle Wheeler wrote:

> If you want to add a config option to allow it to count ALL 
> alternatives, that's fine by me, but I think counting only the last 
> alternative is perfectly reasonable and compliant.

Well, I think it depends on what the user of mutt wants to know. I
would want to know how many attachments there are, someone else might
want to know how many attachments would make up the most faithful
representation, and yet another person cares about how many
attachments mutt figures he/she might want to look at. You could as
well count only the attachments mutt can display (with or without the
help of external programs) because the user doesn't need to know about
attachments he cannot even display.

> Granted, mutt will only *display* the attachment inline if you view 
> the message as text/html, but whether it's displayed or not should 
> have nothing to do with whether it counts as an attachment. I think t 
> should counts as an attachment if a) I consider inlined PDFs to be 
> attachments and b) it is in the last component of the 
> multipart/alternative.

Hm, when it shouldn't matter for the count if an attachment is
displayed or not, why should it matter if an attachment would be part
of the most faithful representation of the message? Being part of the
most faithful representation or not is only relevant when the
attachment is displayed within the representation it is part of.

It shouldn't matter for the count what an attachment is part of or
where in the message it is. It's still there.

Re: multipart/alternative question

[lee]

On Thu, Jul 16, 2009 at 02:23:40PM -0500, Kyle Wheeler wrote:

> Of course, like I said, I'm more worried about incorrectly saying 
> there are 0 attachments when there is in fact (at least) 1 than I am 
> with incorrectly saying there are 3 attachments when there are in fact 
> (depending on how you count) 4 or even just 1.

Maybe it's a stupid idea: What if mutt only counts how many containers
are in a message?

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thursday, July 16 at 08:18 PM, quoth lee:
>> The definition of "attachment" is not as clear as you would think. 
>> For example, we tend to think of MIME components whose type is 
>> text/* as not being "attachments", but sometimes they can be (e.g. 
>> if I sent you a txt file).
>
> Yeah, but mutt already has a way of showing a list of attachments.

Those aren't attachments, they're MIME components. There's a 
difference, at least in modern lingo. MIME components have *semantics* 
that are important. For example, if someone sends me a message that is 
a multipart/alternative container with both a text/plain component 
(that simply says "Your reader cannot read HTML!") and a text/html 
component, *very* few people would consider that message to have THREE 
attachments, besides the fact that it has three MIME components.

> If you have used the mail client built into Mozilla, it would 
> distinguish between forwarding messages inline vs. as attachment. 
> And inline was actually inline, while attachment was attachment.
>
> So what's the difference between "inline" and "attachment"?

In the case of forwarding mail? The difference is usually between 
"copy the text of the forwarded mail into the text of a new mail, and 
maybe quote it or indicate that it came from another message somehow" 
(that's "inline") and the alternative "preserve the original message 
EXACTLY and encapsulate it within a separate MIME container appended 
to the MIME structure of a new message" (that's "attachment"). Mutt 
does similar things based on the $forward_mime setting.

Unfortunately, those terms mean different (albeit related) things in 
the sense of MIME disposition. In MIME disposition terms, "inline" 
means "display the contents of this MIME component when the reader 
views the mail" and non-inline means "don't display the contents of 
this MIME component when the reader views the mail".

>> Here's a wacky message structure my mom sent me (using Apple Mail):
>>
>>  I   1 [multipa/alterna, 7bit, 653K]
>>  I   2 |-> [text/plain, utf-8, 2.0K]
>>  I   3 `-> [multipa/mixed, 7bit, 651K]
>>  I   4   |->   [text/html, quoted, windows-1252, 3.0K]
>>  I   5   |->Typeface Ideas.pdf [applica/pdf ...]
>>  I   6   `->   [text/html, 7bit, us-ascii, 0.2K]
>>
>> I haven't set up attachment detection properly, so %X says this 
>> message has 0 attachments.
>
> All the attachments of this message are designated inline. But you can 
> even set
>
> attachments +A */.* 
> attachments +I */.*
>
> and mutt doesn't count attachments that are inline.

Yes it does. But it doesn't recurse into some MIME containers (as 
we've been discussing).

For example, I have a message with the following MIME structure:

 I   1[text/plain]
 I   2 forwarded message  [message/rfc822]
 I   3 `->[text/plain]

With your two rules, mutt tells me that this message has ONE 
attachment. They're ALL inline, so *something* got counted!

As I understand it (David would know for sure) the "main body" of the 
message (MIME component #1) doesn't count toward the total. Also, mutt 
doesn't look at the sub-components of MIME component #2 (why? I don't 
know), so there is only one attachment: component #2 itself.

> (Imho, there's no such thing as an "inline attachment". Something is 
> either attached or inline, and it cannot be both. Creating mails 
> with inline attachments is silly.)

Then you're not understanding the idea.

It's all about *display*. Do you want the contents a given 
"attachment" (or MIME component) to be *displayed* when the rest of 
the message is displayed, or do you want it to be represented more 
succinctly, merely letting the viewer know that it exists? The former 
is an "inline" attachment, the latter is a non-inline attachment.

If you include a JPEG in an email, should that JPEG be displayed when  
the user views the message, or should it just show up as an icon that 
can be downloaded and saved to disk? If you want it to display when 
the user opens the message, is that JPEG "attached" to the message? 
(if it is not attached, how would you describe its relationship to the  
message?) Should the user be able to save it separately from the rest 
of the message? Should it be allowed to have a filename associated 
with it?

The answers, according to the standard RFCs, is that yes, that JPEG is 
"attached" to the message, yes it can have a filename, and yes the 
user should be able to separate the picture 

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thursday, July 16 at 08:56 PM, quoth lee:
>On Thu, Jul 16, 2009 at 02:23:40PM -0500, Kyle Wheeler wrote:
>
>> Of course, like I said, I'm more worried about incorrectly saying
>> there are 0 attachments when there is in fact (at least) 1 than I am
>> with incorrectly saying there are 3 attachments when there are in fact
>> (depending on how you count) 4 or even just 1.
>
>Maybe it's a stupid idea: What if mutt only counts how many containers
>are in a message?

Well, I get a lot of messages from people who use email clients with 
"default" message composition in HTML (that includes Outlook, 
Thunderbird, Apple Mail, and a whole host of others). When they send a 
basic message to say "Hi!", their client sends a message structured 
like this:

 I   1 [multipart/alternative]
 I   2 |-> [text/plain]
 I   3 `-> [text/html]

In this case, the text/plain part says "Hi!", and the text/html part 
says "Hi!". It's completely idiotic.

But anyway, I don't consider this message to have ANY "attachments". 
The person didn't send me any extra files to look at. They sent me the 
same message twice, one with extra formatting and one without. I don't 
think most people would consider that to be a message with 
"attachments", so I don't think mutt should say that there is an 
attachment.

~Kyle
- -- 
There can be but little liberty on earth while men worship a tyrant in 
heaven.
  -- Robert Green Ingersoll
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKX+0pAAoJECuveozR/AWeZEYP/j+9bB9g0vgFYCkE1PduIgKE
RvI9ygNGDpB0XT+zaWDiJa+9DnSQYl3nYvDoeS+kAx8QhnXtlFLjWZvg/9NxoiJd
sOcti1U9JMZHFy4mpDSdtmEMKncw7uMX/F0Aflic/esbhhh1/GBlxMyITshTV2xF
JzV711rKmjNRyhO6irey9aKtWJE1rUaZB4LBfYT0a9VjZh1iHXRzoAlG/JIEJdJx
xQkvP+9ySJeIJ3cnKCvgmLsQJGX0sAz2JWiXgJzKyRvkMuLa0g2+Lx6neTa2nefW
BCJGruMGckTtSf4Yj9m3MsttOHWaO4lm156+2wAmosCgDELVT8bXcAbVu0oaTOv5
s+qYgMbfDxQhGdwRvEGZzo+3X5HnqVZ1wj69atgDnetKODQcpXZkVNe1+cg2l+U6
V4VEk7Qnq4CG2nipj3pkClgaBZVN9W4fQP3xa2Y7N3Lffwku3cQ2DTGrvVkPR+w2
RLXs+PQbSZNoeq8LIWx+/2864aRgDPQuT7AdAawelP9Jgrj5Jvqtlz+ieIAw3eTx
XoODC8Vo9Kqcuc4y/Yus4Ay7kAGRCYaAL+AYJEsbk3k2zMrC+9/KxySZzcXLfYxh
TJRatWl3gtV2jIn9E6/Rb+ZhjMXz9U45aFnMHPITiiV+4w5wWHuAnq3nZb4G7c/+
3wbYbn20rmATPgusxg41
=B0V/
-END PGP SIGNATURE-

Re: multipart/alternative question

[Tim Gray]

On Thu 16, Jul'09 at 10:16 PM -0500, Kyle Wheeler wrote:
But anyway, I don't consider this message to have ANY "attachments". The 
person didn't send me any extra files to look at. They sent me the same 
message twice, one with extra formatting and one without. I don't think 
most people would consider that to be a message with "attachments", so I 
don't think mutt should say that there is an attachment.


I think we are on the same page Kyle.  You understand where I'm coming from 
with the Apple Mail messages.  I have collaborators who send a lot of files: 
pdfs, jpgs, whatever.  They just toss them in the message window and they 
get inlined just like the example I described early and you showed.  It'd be 
nice if they showed up or got counted somehow but I don't see how to make 
mutt do it.


Of all the ideas discussed so far, I think the one of counting all the non 
text/html attachments in the last part of the multipart makes the most 
sense. Especially if the last part is supposed to be the preferred/richest 
one according to the RFC.

Re: multipart/alternative question

[lee]

On Thu, Jul 16, 2009 at 10:09:16PM -0500, Kyle Wheeler wrote:
> On Thursday, July 16 at 08:18 PM, quoth lee:
> >
> > Yeah, but mutt already has a way of showing a list of attachments.
> 
> Those aren't attachments, they're MIME components. There's a 
> difference, at least in modern lingo. MIME components have *semantics* 
> that are important.

You mean the difference between attachments and mime components is
only a semantical one?

> For example, if someone sends me a message that is a
> multipart/alternative container with both a text/plain component
> (that simply says "Your reader cannot read HTML!") and a text/html
> component, *very* few people would consider that message to have
> THREE attachments, besides the fact that it has three MIME
> components.

Well, messages are plain text in the first place. If there's a message
that doesn't have text but a container, that container is an
attachment. You might argue whether things inside the container are
also attachments or not. To me they are because it doesn't matter to
me if things attached to a mail are contained in a container or not.

If you argue that things inside containers are not to be counted as
attachments, then you cannot count a container other than the mail
itself as attachments because the mail is a container (containing
other containers) itself.

> > So what's the difference between "inline" and "attachment"?
> 
> Unfortunately, those terms mean different (albeit related) things in 
> the sense of MIME disposition. In MIME disposition terms, "inline" 
> means "display the contents of this MIME component when the reader 
> views the mail" and non-inline means "don't display the contents of 
> this MIME component when the reader views the mail".

That's what I meant. Still all the components are attachments, no
matter if they are to be displayed in line or not.

> > and mutt doesn't count attachments that are inline.
> 
> Yes it does. But it doesn't recurse into some MIME containers (as 
> we've been discussing).

Even when mutt doesn't recurse into multipart/alternative, the
multipart/alternative itself is an attachment which should be counted:


  I 1 [multipa/alternativ, 7bit, 4.2K]
  I 2 >   [text/plain, quoted, iso-8859-1, 1.3K]
  I 3 >   [text/html, quoted, iso-8859-1, 2.5K]


Mutt says that there are 0 attachments. I say there's at least 1.

> For example, I have a message with the following MIME structure:
> 
>  I   1[text/plain]
>  I   2 forwarded message  [message/rfc822]
>  I   3 `->[text/plain]
> 
> With your two rules, mutt tells me that this message has ONE 
> attachment. They're ALL inline, so *something* got counted!

The interesting question is: *What* has been counted :)

> As I understand it (David would know for sure) the "main body" of the 
> message (MIME component #1) doesn't count toward the total.

RFC822:


"
  A message consists of header fields and, optionally, a body.
 The  body  is simply a sequence of lines containing ASCII charac-
 ters.  It is separated from the headers by a null line  (i.e.,  a
 line with nothing preceding the CRLF).
"


You could argue that the message doesn't have an attachment because
everything is to be displayed in line. I would argue that everything
that isn't either headers or body as described in RFC822 is an
attachment.

Containers? If you put a container containing 1 bricks onto a
container ship, you have 1 bricks on the container ship (and one
container). For the purpose of counting containers, you loaded one
container; for the purpose of counting bricks, you loaded 1
bricks.

So what do you want to count, containers or everything that is
"attached" to the ship?

> > (Imho, there's no such thing as an "inline attachment". Something is 
> > either attached or inline, and it cannot be both. Creating mails 
> > with inline attachments is silly.)
> 
> Then you're not understanding the idea.

Indeed --- or lets say I have a different understanding.

> It's all about *display*. Do you want the contents a given 
> "attachment" (or MIME component) to be *displayed* when the rest of 
> the message is displayed, or do you want it to be represented more 
> succinctly, merely letting the viewer know that it exists? The former 
> is an "inline" attachment, the latter is a non-inline attachment.

So you would say that all of them are attachments and therefore should
count as such, no matter how they are supposed to be displayed.

> If you include a JPEG in an email, should that JPEG be displayed when  
> the user vie

Re: multipart/alternative question

[lee]

On Thu, Jul 16, 2009 at 10:16:57PM -0500, Kyle Wheeler wrote:

> But anyway, I don't consider this message to have ANY "attachments". 
> The person didn't send me any extra files to look at. They sent me the 
> same message twice, one with extra formatting and one without. I don't 
> think most people would consider that to be a message with 
> "attachments", so I don't think mutt should say that there is an 
> attachment.

Well, I would consider such a message as attachment only: No message
(i. e. no body), only three attachments.

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thursday, July 16 at 10:27 PM, quoth lee:
> On Thu, Jul 16, 2009 at 10:09:16PM -0500, Kyle Wheeler wrote:
>> On Thursday, July 16 at 08:18 PM, quoth lee:
>>>
>>> Yeah, but mutt already has a way of showing a list of attachments.
>>
>> Those aren't attachments, they're MIME components. There's a 
>> difference, at least in modern lingo. MIME components have *semantics* 
>> that are important.
>
> You mean the difference between attachments and mime components is 
> only a semantical one?

No, I mean that MIME components (aka "entities") have meanings that 
affect the interpretation of other MIME entities. For example, take 
PGP/MIME, where one MIME entity (the signature) can affect the 
understanding of another. As another example, take multipart/mixed, 
which is only a container for other MIME entities and has no inherent 
content itself.

The term "attachment", on the other hand, is a poorly defined term 
that has different meanings based on who you ask. For example, you 
seem to think that all MIME entities count as "attachments", while I 
tend to think of "attachments" as only those things that a user has 
explicitly attempted to attach (I don't think the body text of a 
message counts as an "attachment").

I could appeal to something like Wikipedia (which says an email 
attachment "is a computer file which is sent along with an email 
message"), but I'm guessing you don't care much for so-called 
"official" definitions.

> Even when mutt doesn't recurse into multipart/alternative, the 
> multipart/alternative itself is an attachment which should be 
> counted:
>
>
>  I 1 [multipa/alternativ, 7bit, 4.2K]
>  I 2 >   [text/plain, quoted, iso-8859-1, 1.3K]
>  I 3 >   [text/html, quoted, iso-8859-1, 2.5K]
>
>
> Mutt says that there are 0 attachments. I say there's at least 1.

We clearly have different definitions of the term.

I find my definition more useful, because then I can use it to tell me 
whether there's some component of the message that I can and will want 
to save to disk. In the message structure you show there, none of 
those MIME entities are things I have any interest in saving to disk. 
None of those MIME entities are things the sender explicitly 
"attached" to the message (by using the "attach" function of his/her 
mailer). It makes sense to me.

What's the utility of your definition?

> Containers? If you put a container containing 1 bricks onto a 
> container ship, you have 1 bricks on the container ship (and one 
> container). For the purpose of counting containers, you loaded one 
> container; for the purpose of counting bricks, you loaded 1 
> bricks.
>
> So what do you want to count, containers or everything that is 
> "attached" to the ship?

I want to know if I need to unload anything from the ship. I want to 
know the difference between a ship loaded full of empty containers 
(that I don't care about) and a ship loaded full of bricks (things 
that I want). Thus, I can ask "how many things are on the ship?" and 
get an answer. If the ship merely has a hundred empty containers, and 
my smart-alecky captain says "there's a hundred things on the ship", 
I'm gonna be annoyed when I rifle through every last container and 
discover that they're all empty. On the other hand, if I paid to ship 
a thousand bricks, and there's one container with a thousand bricks, 
when he tells me "there just one thing on the ship", I'm *still* going 
to be annoyed that he was playing goofy semantic games and didn't tell 
me that everything I ordered was in fact on the ship.

Why do *you* care how many containers are on the ship?

>> It's all about *display*. Do you want the contents a given 
>> "attachment" (or MIME component) to be *displayed* when the rest of 
>> the message is displayed, or do you want it to be represented more 
>> succinctly, merely letting the viewer know that it exists? The 
>> former is an "inline" attachment, the latter is a non-inline 
>> attachment.
>
> So you would say that all of them are attachments and therefore should 
> count as such, no matter how they are supposed to be displayed.

Am I really that hard to understand, or are you just trying to get 
under my skin?

For the umpteenth time, no, not all MIME entities are attachments.

> RFC822:

RFC 2045:

 This set of documents, collectively called the Multipurpose
 Internet Mail Extensions, or MIME, redefines the format of
 messages to allow for

 (1) textual message bodies in character sets other than US-

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thursday, July 16 at 10:51 PM, quoth lee:
>On Thu, Jul 16, 2009 at 10:16:57PM -0500, Kyle Wheeler wrote:
>
>> But anyway, I don't consider this message to have ANY "attachments".
>> The person didn't send me any extra files to look at. They sent me the
>> same message twice, one with extra formatting and one without. I don't
>> think most people would consider that to be a message with
>> "attachments", so I don't think mutt should say that there is an
>> attachment.
>
>Well, I would consider such a message as attachment only: No message
>(i. e. no body), only three attachments.

Logically, an "attachment" needs something to be attached TO.

In snail mail, a letter is not an attachment, and when you staple 
something to a letter (such as a photograph), the photograph is 
considered the attachment, the letter is the thing to which the 
photograph is attached. They do not both become attachments of each 
other.

The MIME equivalent of what I just described is this:

 I   1   [multipart/mixed]
 I   2 |->   [text/plain]
 A   3 `->   [image/jpeg]

Entity #3 is the attachment. It is attached to Entity #2. Entity #1 is 
the staple: it exists only for the purpose of attaching #3 to #2.

I understand, having read enough philosophy, that you can argue ad 
infinitum about the "truth" that the letter is just as much the 
attachment to the photograph as the photograph is an attachment to the 
letter, but that's a really pointless argument.

~Kyle
- -- 
Scientists have shown that the moon is moving away at a tiny, although 
measurable distance from earth every year. If you do the math, you can 
calculate that 65 million years ago, the moon was orbiting at a 
distance of about 35 feet from the earth's surface. This would explain 
the death of the dinosaurs ... the tallest ones, anyway.
 -- Unknown
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKYBC8AAoJECuveozR/AWeD+8P/ifUZrtgI4Wxa68iDapDtrEE
QG9Mu+TVEOzvl/VGeeYa5+HWgrMgo49Z8dTwtLVNqG5y8osFCv4Fn20qm5tN9Kq7
AhueBVirIPCsE2RpOsYgEbtHfzvIb6iXcqDaw3oE0S/5HQDjhwbdkOmHdLAw/bW2
pjPNb9hTb7RGS0KtmFk9to9k0nqaxa0y3C/hVM1Tod/IdG3pelY6mnXTMhmfx/fO
TMCLjq3++9ahxPFyJS8qwTDoGDmK+k4M8TPEI3dsr4LZ713f+yUZrFK1rxcMnbV8
ZzB/z5id1nDj8lRMdJGtfVA0cxvWk2hK7Aw8sDGW8qDDn7DSxc0FIHMTow4456Sa
n/WDUtCKXKFdtBfJ9aQwA/PlPgmXb192DBPGt8uiD3qf1hQ32HDZ+j4zHUkCSpZK
bdhOGbdPqnXd9BOw+WD//n/SA8Wf4pZU+hoGREFaahJCYgs5oAiExeK0N2+U/Lzh
kKpX8JszIUnIkE4JCUoTLSVp+Dotyfl/AELWet3Vxz/Bf11uLeNhq9Xp52yKKaSM
JV6wbFHhgdOaq4T6pgEHzQfdm9JoYFMCB975onojRfnFjbbcac3VR+UlQoYs8m1C
Vq+vCRqv/eHN/mJGs+asIiwDBWAK7T3NXPjphJNPXDhAFOM07k9VSimC3I2VuiWg
EAaEkbAc4/l4+NJZgrUE
=N8SF
-END PGP SIGNATURE-

Re: multipart/alternative question

[lee]

On Fri, Jul 17, 2009 at 12:48:45AM -0500, Kyle Wheeler wrote:
> On Thursday, July 16 at 10:51 PM, quoth lee:
> >On Thu, Jul 16, 2009 at 10:16:57PM -0500, Kyle Wheeler wrote:
> >
> >> But anyway, I don't consider this message to have ANY "attachments".
> >> The person didn't send me any extra files to look at. They sent me the
> >> same message twice, one with extra formatting and one without. I don't
> >> think most people would consider that to be a message with
> >> "attachments", so I don't think mutt should say that there is an
> >> attachment.
> >
> >Well, I would consider such a message as attachment only: No message
> >(i. e. no body), only three attachments.
> 
> Logically, an "attachment" needs something to be attached TO.

Ok, maybe I should have that expressed less ambiguous. What you get is
a message (RFC822) that doesn't have a body (or has an empty body). To
this message, something is attached.

> The MIME equivalent of what I just described is this:
> 
>  I   1   [multipart/mixed]
>  I   2 |->   [text/plain]
>  A   3 `->   [image/jpeg]
> 
> Entity #3 is the attachment. It is attached to Entity #2. Entity #1 is 
> the staple: it exists only for the purpose of attaching #3 to #2.

Yeah, I see what you mean.

But you've skipped a step: the message. If you consider the
implementation, starting with RFC822 (and considering RFC821), you
have a message. The message doesn't have a body. Your entity #1 is
attached to the message.

That entities #2 and #3 are contained in entity #1 doesn't change the
fact that they are, though indirectly, attached to the message. That
entity #3 could be considered as attached to entity #2 doesn't change
the fact that they are (indirectly) attached to the message, either.

The fact that all entities are attached to the message makes all of
them attachments to the message, regardless of their purpose,
regardless of how they might be attached to each other and regardless
of how they are attached to the message.

Thus you cannot deny that you have a message (without a body and) with
three attachments. *You cannot send attachments without a message.*

> I understand, having read enough philosophy, that you can argue ad 
> infinitum about the "truth" that the letter is just as much the 
> attachment to the photograph as the photograph is an attachment to the 
> letter, but that's a really pointless argument.

ok :)

Then we don't need to argue whether a message is still a message or
not when it doesn't have a body. RFC822 gives us the basic definition
of what a message is. That still seems to be in use. Other RFCs define
attachments --- I'll admit that I didn't read those because I didn't
need to yet and because there are so many and because it's hard to
tell which ones are current and which ones are superseded by others
...

Re: multipart/alternative question

[Rejo Zenger]

++ 16/07/09 09:03 -0500 - Kyle Wheeler:
>> Since mutt is set to prefer text/plain, all I see is the plain text 
>> message, with no indication that there is an attachment (or even an 
>> html part).
>
>First, of course there's no obvious indication that there's an html 
>part. Why should there be? Unless you press v to view the MIME 
>hierarchy of the message, mutt doesn't tell you about alternative 
>components to your email.
[...]

The same issue has been discussed before on this list: [1]. Kyle did a 
good job of explaining at [2].


[1] 
[2] 



-- 
Rejo Zenger .  . 0x21DBEFD4 . 
GPG encrypted e-mail prefered. 


signature.asc
Description: Digital signature

Re: multipart/alternative question

[Noah Slater]

Hey,

On Thu, Jul 16, 2009 at 10:16:57PM -0500, Kyle Wheeler wrote:
>  I   1     [multipart/alternative]
>  I   2 |-> [text/plain]
>  I   3 `-> [text/html]
[...]
> But anyway, I don't consider this message to have ANY "attachments".

On Thu, Jul 16, 2009 at 10:51:44PM -0600, lee wrote:
> Well, I would consider such a message as attachment only: No message
> (i. e. no body), only three attachments.
[...]
> The fact that all entities are attached to the message makes all of
> them attachments to the message, regardless of their purpose,
> regardless of how they might be attached to each other and regardless
> of how they are attached to the message.

Lee, directly or indirectly, you're just playing language games.

You're using the word "attach" to misleadingly describe the process by which a
message has message entities added to it. While this is certainly a valid use of
the word attach, you're then extrapolating that all entities must therefor be
attachments. I guess in some general sense you are correct, but within the
context of a MUA, an attachment has a very specific and well defined meaning,
that is much more narrow than this.

An attachment is a message entity that a user is likely to add or save to and
from the file system, as separate to the main message. A good litmus test,
although by no means perfect, would be if the entity has an explicit file name.
In the example that Kyle gave, there are clearly no attachments, and I would not
want to use a MUA that listed any.

Best,

-- 
Noah Slater, http://tumbolia.org/nslater

Re: multipart/alternative question

[lee]

On Fri, Jul 17, 2009 at 02:36:41PM +0100, Noah Slater wrote:
> I guess in some general sense you are correct, but within the
> context of a MUA, an attachment has a very specific and well defined
> meaning, that is much more narrow than this.

Well, I'm not trying to mislead someone. Where is defined what an
attachment is for the context of a MUA, and who made the definition?

> An attachment is a message entity that a user is likely to add or
> save to and from the file system, as separate to the main message.

In Kyles example, that would be saving the html attachment to view it
in a web browser. The user might do that himself, the MUA might do it
automatically. If you use a MUA that cannot display text/plain, you
might save the text/plain to display it ...

And who is to decide how likely a particular user is to save a
particular attachment, for the purpose of the MUA counting the
attachments? The MUA would have a hard time to figure that out.

> A good litmus test, although by no means perfect, would be if the
> entity has an explicit file name.  In the example that Kyle gave,
> there are clearly no attachments, and I would not want to use a MUA
> that listed any.

To me, it has clearly three attachments. It doesn't matter if a user
is likely to save an attachment or not.

BTW, what's a "message entity"? Attachments are not "message entities"
if you look at RFC822.

Re: multipart/alternative question

[David Champion]

* On 17 Jul 2009, lee wrote: 
> 
> Well, I'm not trying to mislead someone. Where is defined what an
> attachment is for the context of a MUA, and who made the definition?

Content-Disposition's role is described in RFC 2183.  But "attachment"
is a very ambiguous term.  There is no English analogue for a message
component with Content-Disposition: inline ("inlinement"? no), and many
MUAs incorrectly identify disposition when constructing MIME messages.
That's why mutt's attachment-counting rules are flexible enough to allow
you to identify inline components as attachments if you wish (even
though they don't by default).


> > An attachment is a message entity that a user is likely to add or
> > save to and from the file system, as separate to the main message.
> 
> In Kyles example, that would be saving the html attachment to view it
> in a web browser. The user might do that himself, the MUA might do it
> automatically. If you use a MUA that cannot display text/plain, you
> might save the text/plain to display it ...

HTML components are most often best considered inline these days, since
most HTML components represent the sender's message.  If you wanted
to say "here is an example of an HTML file that does what I'm talking
about", and attached that to your message as an exhibit, that would be
properly flagged as "Content-Disposition: attach".

It's less about what the user wants to do, and more about the
component's relationship to the message that the sender composed.  But
this is still rather subjective.

-- 
 -D.d...@uchicago.eduNSITUniversity of Chicago

Re: multipart/alternative question

[lee]

On Fri, Jul 17, 2009 at 12:39:19AM -0500, Kyle Wheeler wrote:

> No, I mean that MIME components (aka "entities") have meanings that 
> affect the interpretation of other MIME entities.

ok

> I could appeal to something like Wikipedia (which says an email 
> attachment "is a computer file which is sent along with an email 
> message"), but I'm guessing you don't care much for so-called 
> "official" definitions.

It depends ... I distinguish between definitions and descriptions, and
since there are often many different descriptions of something
(calling themselves definitions), I don't care much for so-called
official definitions. Then look at different languages and the
descriptions of the same thing, and even if the description of
something may be very similar to one in another language, people who
have different native languages can (and usually will) have a
different understanding/perception/relationship/opinion of the same
thing. That is something very difficult to include into a description,
and it's usually not done.

As to RFCs, the ones I know are more definitions than descriptions,
and I consider RFCs as relevant. They are what is in use; implementing
something is either compliant with RFCs or may not work. Without RFCs,
one MTA couldn't understand another one, and one MUA couldn't display
messages created with another one.

> > Mutt says that there are 0 attachments. I say there's at least 1.
> 
> We clearly have different definitions of the term.

Yes --- but that's ok.

> I find my definition more useful, because then I can use it to tell
> me whether there's some component of the message that I can and will
> want to save to disk.

That's fine --- it is what is useful for you. You could rename what is
called "attachment counter" to "file counter" or something, or you
could say that you would like to have a counter telling you how many
attachments there are that you might want to save.

Mutt already supports this in that you can specify what things should
qualify as attachments and be counted. The problem is that the
counting doesn't work right.

> What's the utility of your definition?

You mean what the usefulness is of my considering everything that is
attached to a message as an attachment? It gives me an impression
about how messed up a message might be. If it's a message that might
be a SPAM mail, it will prevent me from opening it.

What is the usefulness of knowing if something is attached to a
message that you might want to save to a separate file? It's useful to
you, but not really useful to me.

> Why do *you* care how many containers are on the ship?

See above --- you care about what's in the containers, I care about
how many containers there are.

How do you want to unload, i. e. would you prefer to unload all the
bricks at once by unloading the container (save the whole container to
disk with everything in it), or would you rather open the container
and unload (save to disk) one brick (file) at a time?

> >> It's all about *display*. Do you want the contents a given 
> >> "attachment" (or MIME component) to be *displayed* when the rest of 
> >> the message is displayed, or do you want it to be represented more 
> >> succinctly, merely letting the viewer know that it exists? The 
> >> former is an "inline" attachment, the latter is a non-inline 
> >> attachment.
> >
> > So you would say that all of them are attachments and therefore should 
> > count as such, no matter how they are supposed to be displayed.
> 
> Am I really that hard to understand, or are you just trying to get 
> under my skin?

Well, what were you saying?

> For the umpteenth time, no, not all MIME entities are attachments.

To me, they are.

> > RFC822:
> 
> RFC 2045:
> 
>  This set of documents, collectively called the Multipurpose
>  Internet Mail Extensions, or MIME, redefines the format of
>  messages to allow for
> 
>  (1) textual message bodies in character sets other than US-ASCII,
>  (2) an extensible set of different formats for non-textual message
>  bodies,
>  (3) multi-part message bodies, and
>  (4) textual header information in character sets other than
>  US-ASCII.
> 
> Thus, in the context of MIME, the RFC 822 definition of a message 
> format is no longer supreme. It has been, in the words of the MIME 
> RFC, "redefined".

Ok, so which is the current RFC for this? 2045, or is there even
another one modifying or superseding 2045?

2045 says:


"
   The term "message", when not further qualified, means either a
   (complete or "top-level") RFC 822 message being transferred on a
   network, or a message encapsulated in a body of type "message/rfc822"
   or "message/partial".
"


That's a rather unlucky definition because it uses the term it defines
in the definition. I don't understand what "message" means when they
say "a message encapsulated in a body". Do they mean an RFC822
message? Do they mean "body" in the sense of RFC822?

> > You shouldn't ask

Re: multipart/alternative question

[lee]

On Fri, Jul 17, 2009 at 11:37:50AM -0500, David Champion wrote:
> * On 17 Jul 2009, lee wrote: 
> > 
> > Well, I'm not trying to mislead someone. Where is defined what an
> > attachment is for the context of a MUA, and who made the definition?
> 
> Content-Disposition's role is described in RFC 2183.  But "attachment"
> is a very ambiguous term.

They have a good way of putting it in RFC 2183:


"
   Two common ways of presenting multipart electronic messages are as a
   main document with a list of separate attachments, and as a single
   document with the various parts expanded (displayed) inline. The
   display of an attachment is generally construed to require positive
   action on the part of the recipient, while inline message components
   are displayed automatically when the message is viewed. A mechanism
   is needed to allow the sender to transmit this sort of presentational
   information to the recipient; the Content-Disposition header provides
   this mechanism, allowing each component of a message to be tagged
   with an indication of its desired presentation semantics.
"


There is a distinction between attachments and other message
components. You could say everything not designated to be displayed
automatically in line is considered as an attachment.

> It's less about what the user wants to do, and more about the
> component's relationship to the message that the sender composed.  But
> this is still rather subjective.

There could be a counter counting message components. The RFC 2183 is
supposed to define a means *for the sender* to specify how he wants
parts of the message to be displayed. How the recipient deals with the
message is up to him.

Is there an RFC that defines how a MUA is supposed to deal with such
multipart messages? RFC 2183 seems to (reasonably) say only a minimum
about what MUAs should do.

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Friday, July 17 at 11:37 AM, quoth lee:
> Mutt already supports this in that you can specify what things 
> should qualify as attachments and be counted. The problem is that 
> the counting doesn't work right.

Agreed!

>> What's the utility of your definition?
>
> You mean what the usefulness is of my considering everything that is 
> attached to a message as an attachment? It gives me an impression 
> about how messed up a message might be. If it's a message that might 
> be a SPAM mail, it will prevent me from opening it.

Hm. See, I find that I really don't care how "messed up" a message 
might be. For example, I often get emails from corporate secretaries 
that use Outlook and some goofy HTML stationery (complete with 
background picture, goofy fonts, corporate logo, etc.). Knowing that 
it's a complex MIME structure isn't a useful piece of information to 
me.

But to each his own, I suppose.

> What is the usefulness of knowing if something is attached to a 
> message that you might want to save to a separate file? It's useful to 
> you, but not really useful to me.

Well, the usefulness to me is that occasionally I receive messages 
that don't make it clear that there IS an attachment in the text. For 
example, I'll get an email that reads "Can you make sure that the 
schedules are right for next month?". It also has a copy of the 
schedules attached (probably that's messed up and isn't what had 
previously been established as the schedules), but that's an easy fact 
to miss in a text-based email reader (GUI email programs, and webmail, 
often make such things a bit more obvious).

>> Why do *you* care how many containers are on the ship?
>
> See above --- you care about what's in the containers, I care about 
> how many containers there are.
>
> How do you want to unload, i. e. would you prefer to unload all the 
> bricks at once by unloading the container (save the whole container to 
> disk with everything in it), or would you rather open the container 
> and unload (save to disk) one brick (file) at a time?

See, here's where I think the metaphor becomes a bit strained. I don't 
know how what you're talking about maps back to email.

 It's all about *display*. Do you want the contents a given 
 "attachment" (or MIME component) to be *displayed* when the rest of 
 the message is displayed, or do you want it to be represented more 
 succinctly, merely letting the viewer know that it exists? The 
 former is an "inline" attachment, the latter is a non-inline 
 attachment.
>>>
>>> So you would say that all of them are attachments and therefore should 
>>> count as such, no matter how they are supposed to be displayed.
>>
>> Am I really that hard to understand, or are you just trying to get 
>> under my skin?
>
> Well, what were you saying?

According to the Content-Disposition RFC (2183), which is what defines 
the idea of an "inline" MIME entity versus an "attached" MIME entity, 
the difference is in presentation (aka "display") to the recipient. 
Here's how they describe it:

 Two common ways of presenting multipart electronic messages are as
 a main document with a list of separate attachments, and as a
 single document with the various parts expanded (displayed)
 inline. The display of an attachment is generally construed to
 require positive action on the part of the recipient, while inline
 message components are displayed automatically when the message is
 viewed.

That, I think, pretty much restates what I was saying.

In particular, mutt observes and respects the two disposition types 
outlined in that RFC:

 2.1  The Inline Disposition Type

 A bodypart should be marked `inline' if it is intended to be
 displayed automatically upon display of the message.  Inline
 bodyparts should be presented in the order in which they
 occur, subject to the normal semantics of multipart messages.

 2.2  The Attachment Disposition Type

 Bodyparts can be designated `attachment' to indicate that they
 are separate from the main body of the mail message, and that
 their display should not be automatic, but contingent upon
 some further action of the user.  The MUA might instead
 present the user of a bitmap terminal with an iconic
 representation of the attachments, or, on character terminals,
 with a list of attachments from which the user could select
 for viewing or storage.

>> For the umpteenth time, no, not all MIME entities are attachments.
>
> To me, they are.

Well, then I think it's safe to say that you have a rather unusual 
view of MIME entities that is not shared by (at least some of) the 
designers of the MIME standard.

> Ok, so which is the current RFC for this? 2045, or is there even 
> another one modifying or superseding 2045?

There isn't an RFC that obsoletes 2045. It is updated by 2

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Friday, July 17 at 12:18 PM, quoth lee:
> Is there an RFC that defines how a MUA is supposed to deal with such 
> multipart messages? RFC 2183 seems to (reasonably) say only a 
> minimum about what MUAs should do.

Not that I know of... The closest I can find is RFC 1521, which says:

 It may be the case that some user agents, if they can recognize
 more than one of the formats, will prefer to offer the user the
 choice of which format to view. This makes sense, for example, if
 mail includes both a nicely-formatted image version and an
 easily-edited text version. What is most critical, however, is
 that the user not automatically be shown multiple versions of the
 same data. Either the user should be shown the last recognized
 version or should be given the choice.

Granted, this is talking about presentation of the CONTENTS of the 
multipart/alternative sub-entities, but I think it applies to 
summaries of that content as well (i.e. "attachment counts"). In other 
words, I think the suggestion here is to count attachments from only 
ONE of the alternatives, not from all of the alternatives, because to 
count attachments in ALL of the alternatives is equivalent to being 
show multiple versions of the same data.

Of course, this is complicated by the preceeding paragraph:

 In the case where one of the alternatives is itself of type
 "multipart" and contains unrecognized sub-parts, the user agent
 may choose either to show that alternative, an earlier
 alternative, or both.

It doesn't say what to do if multiple alternatives are of type 
"multipart", and showing "both" seems to directly contradict "what is 
most critical" a mere few sentences later.

~Kyle
- -- 
Preach the Gospel at all times and when necessary use words.
   -- St. Francis of Assisi
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKYMlsAAoJECuveozR/AWebUsP/1KhmB/AjnTqQSFJPF/th+Qf
X4+kbao9m2xMNSE2pcpT/3eZwyk886gCXsgWfxtA2I78/9In32UTeg2YkNROIAHX
BT26rSd3rZMqTAL/5yKyWs5jAcz4NlRES0nCd6UIpS5vk9lNqEFWjhMz/n58UsUo
xtiR7PjCEc5fVwTRH5ukN7GKoTdc5rzzmsn8wuehIdTPTbvJOA/9oWaGP8mhXpow
X0ak3i4JKBQEfpn1J6lJJFe0FE4Rguex60EdqinWWMqgRL4nmU/I4uNf+sd4KRQt
G+6z84bkm1EqQFms6+7DYuP9NTaYMQw1NLfdb5fdbrSFYmi6G9YRgJvy5g86tWKZ
dG3/SGyKdzwbvdyIBGo+UJdTqkgI72JtUrBWjjr0ULmKWZg6kmd4nGh/d8p0CzSH
A6u9iW9XsVjokXTBTHD1ggswJJrllfLXqaiRK45sHjHRBHJUA5bWayGCdeFywfKz
l0KrbtuCTlBxg6VMErRKTd4rVYIYlDhaKX0ooC+rrwbbWxRjo7U9BIkyUU11a8tx
KDotd4SKy2gw75pkc10+nWPaVwAVDnqZAclUz4Oe6V1BK+X9Pn4Sv2srMgw8MEin
6P0s389ZFRNKRMlU2PkvE2Op9zv8r7Odjx4GgUKXXG0+HGHv1goVeNKNWCB/LXyA
t1v7bcaptJpkJKCQPqSU
=U5rt
-END PGP SIGNATURE-

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Friday, July 17 at 01:56 PM, quoth Kyle Wheeler:
>On Friday, July 17 at 12:18 PM, quoth lee:
>> Is there an RFC that defines how a MUA is supposed to deal with such 
>> multipart messages? RFC 2183 seems to (reasonably) say only a 
>> minimum about what MUAs should do.
>
>Not that I know of... The closest I can find is RFC 1521, which says:

Actually, RFC 2046 is more recent, but says nearly the exact same 
thing. It adds:

 Systems should recognize that the content of the various parts [of
 multipart/alternative sections] are interchangeable.  Systems
 should choose the "best" type based on the local environment and
 references, in some cases even through user interaction.

By "Systems", I'm pretty sure they mean "recipient systems".

~Kyle
- -- 
The most important thing a father can do for his children is to love 
their mother.
   -- Fr. Theodore Hesburgh
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKYMsvAAoJECuveozR/AWeCUEP/2ZK1QYpmvo9QjHS52C+IRMG
LpH+SrgiKtwx4tqFIqkpcCEzKvpuiUQpwGMBNGBkkX9FmcRyXesbGOUD1Lkey0uP
wbf0e5mkCCQA7YAeeTDCa/knpqAQjvck/1jdwiggsgCFh3AGeNS0aGcTRbY1G6SE
ONapoo5Pa7ZA6prnBYtrcLVABCiplfx69vAM2VID90T2LRpL7+IZOlakzJCqlEf+
Xt6fWRHq1g07wV9ezJnJi8kc7pnN1pbVQyIdnvSBeuo2jnNaT1+gzjK3epREnvgr
NcPG92awoG3ljiEQ3ICNeto4Cs3aqWYYZrzJ1XhJrF3gKWFMVXZHSyPV6kc5gJtF
JBsTiwEa1qtiSufq72B8qU7GutzJSUbcupzfOjWAxSJBu18KkLksPRfk2g2GRO0q
twhDrCgN3CSKtowZXt66HaQN5kvqM1BEH28qqsnS08RjN+aUFWIrpLNscHyKwFN2
gTDDbfVBovHUQs8oAleYBUubTVGKuL2RuXDiR21bjFxoN+CT9+fRQn8ZhTNnXvdj
xyNAm3bDxfEBa6SN1KSgRz8NcKPoIqmVh4IlyYSR0BdJo4DfqvyDUQo7vbg3cvDS
9obqBz4UIG51FZzI5uikkp+tg9ur3+BCzV1xZfHhOivsr9DH2kbXJFCJ08DbEd0V
r9U8Z5bX6cn4gwUGDyIQ
=xkNv
-END PGP SIGNATURE-

Re: multipart/alternative question

[lee]

On Fri, Jul 17, 2009 at 01:56:45PM -0500, Kyle Wheeler wrote:

> In other words, I think the suggestion here is to count attachments
> from only ONE of the alternatives, not from all of the alternatives,
> because to count attachments in ALL of the alternatives is
> equivalent to being show multiple versions of the same data.

Hm, I don't think that there is a suggestion about counting
attachments. But anyway, you could as well argue that all those
versions should be counted which could be displayed. However, all this
won't have to do much with counting attachments.

Maybe "attachment" isn't something that should be counted at all
because there can be so much disagreement about what an "attachment"
is and under what circumstances it should be counted or not.

> Of course, this is complicated by the preceeding paragraph:
> 
>  In the case where one of the alternatives is itself of type
>  "multipart" and contains unrecognized sub-parts, the user agent
>  may choose either to show that alternative, an earlier
>  alternative, or both.
> 
> It doesn't say what to do if multiple alternatives are of type 
> "multipart", and showing "both" seems to directly contradict "what is 
> most critical" a mere few sentences later.

When sub-parts are unrecognizable, it makes sense to allow showing
several alternatives because the MUA may not be able to determine
which of the alternatives it should show since it contains parts the
MUA cannot recognize.

And how does a MUA show unrecognizable parts of a message?

Re: multipart/alternative question

[lee]

On Fri, Jul 17, 2009 at 02:04:15PM -0500, Kyle Wheeler wrote:
> Actually, RFC 2046 is more recent, but says nearly the exact same 
> thing. It adds:
> 
>  Systems should recognize that the content of the various parts [of
>  multipart/alternative sections] are interchangeable.  Systems
>  should choose the "best" type based on the local environment and
>  references, in some cases even through user interaction.
> 
> By "Systems", I'm pretty sure they mean "recipient systems".

That's pretty interesting: The MUA *should* "choose the "best" type
based on the local environment and references, in some cases even
through user interaction".

I find that so interesting because it basically means that the MUA
should display a "type" (a message, or part of a message) in just the
way the user would want it. Insofar the user is the recipient, the RFC
says "To hell with how the sender wanted something to be displayed!
Always display it as the recipient wants it to be displayed!"

If you transcribe this to the counting of attachments, it means that
the MUA should count attachments the way the user wants them to be
counted.

Re: multipart/alternative question

[lee]

On Fri, Jul 17, 2009 at 01:38:04PM -0500, Kyle Wheeler wrote:

> For example, I often get emails from corporate secretaries that use
> Outlook and some goofy HTML stationery (complete with background
> picture, goofy fonts, corporate logo, etc.). Knowing that it's a
> complex MIME structure isn't a useful piece of information to me.

Yeah, you want to know what the message says and if something is
attached that you might want to do something with. For that, you don't
want/need to care about how a message is made up.

> But to each his own, I suppose.

yeah

> > What is the usefulness of knowing if something is attached to a 
> > message that you might want to save to a separate file? It's useful to 
> > you, but not really useful to me.
> 
> Well, the usefulness to me is that occasionally I receive messages 
> that don't make it clear that there IS an attachment in the text. For 
> example, I'll get an email that reads "Can you make sure that the 
> schedules are right for next month?". It also has a copy of the 
> schedules attached (probably that's messed up and isn't what had 
> previously been established as the schedules), but that's an easy fact 
> to miss in a text-based email reader (GUI email programs, and webmail, 
> often make such things a bit more obvious).

Hm, somehow I've never had that problem. When reading the message, I
find out if something is attached.

But yes, you're right that for such cases it would be nice if it was
more obvious that there is an attachment. Perhaps you can somehow
change the color of the status line to white on red or change the
color of the message display to white on blue in case a message has a
part that is not designated as inline but as attachment.

For this, mutt would first have to be able to count attachments
exactly the way the user wants them to be counted.

> > How do you want to unload, i. e. would you prefer to unload all the 
> > bricks at once by unloading the container (save the whole container to 
> > disk with everything in it), or would you rather open the container 
> > and unload (save to disk) one brick (file) at a time?
> 
> See, here's where I think the metaphor becomes a bit strained. I don't 
> know how what you're talking about maps back to email.

Well, you could have a message with a container. The container could
contain a number of files, JPEGs for example --- maybe portraits of
your relatives. You could have a choice: Do you want to go to every
file in the list and save one after another, or would you rather go to
the container and save the whole container with all the files in it at
once (as a new directory containing all the JPEGs).


> That, I think, pretty much restates what I was saying.
> In particular, mutt observes and respects the two disposition types 
> outlined in that RFC:

Now I see what you mean. Well, you're right when you say that not
every attachment is an attachment.

>  2.1  The Inline Disposition Type
>  2.2  The Attachment Disposition Type
> >> For the umpteenth time, no, not all MIME entities are attachments.
> >
> > To me, they are.
> 
> Well, then I think it's safe to say that you have a rather unusual 
> view of MIME entities that is not shared by (at least some of) the 
> designers of the MIME standard.

Sort of ... When I started using email, there weren't any attachments
or inlines. If you wanted to send someone something that didn't
contain only ASCII characters (and a few others) --- i. e. a file ---
you would use an uuencoder to convert the file into characters you
could send in a mail. The recipient would save the mail and eventually
have to edit it to remove header lines and use an uudecoder to convert
the message back into a file. And that was all there was; base64 came
some time later but didn't work as well for that. Since different
users would use different uuencoders and uudecoders, recipients were
not always able to decode a message, or senders were not always able
to encode a message so that the recipient could decode it.

At some time, all this mime crap (that's how I still think of it) was
invented. It's very useful for the purpose of sending files because it
makes that easier and more reliable. What they did was basically
changing the encoding from uucode to base64 and moving the file from
the body of the mail to the end of the mail, i. e. they made it an
attachment instead of putting it into the mail. You were able to do
the same with uucode if you got a good en-/decoder, and you would even
see that the uucode is in the message.

To me, sending files is pretty much the only thing the mime stuff is
good for and the only thing it should be used for, with the exception
of using it for encryption (I used that before there was mime, too,
and mime only made it easier ...). I don't want and don't need mails
written in HTML or MS Word or something. That really isn't needed, and
I don't like it. Mails are plain text. (I'm aware it's not that easy
when different languages come into play ...

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Friday, July 17 at 03:58 PM, quoth lee:
> Hm, somehow I've never had that problem. When reading the message, I 
> find out if something is attached.

You're lucky! These days, I usually use the size as an indicator. A 
message that's 10K or so is probably text; but 100K or more probably 
means I need to have a look at its innards (at least that's ONE 
benefit to MSOffice's giant files). But every now and then, I still 
manage to miss an attached file (either because I didn't look, or 
because it was surprisingly small).

> For this, mutt would first have to be able to count attachments 
> exactly the way the user wants them to be counted.

Quite.

> Well, you could have a message with a container. The container could 
> contain a number of files, JPEGs for example --- maybe portraits of 
> your relatives. You could have a choice: Do you want to go to every 
> file in the list and save one after another, or would you rather go 
> to the container and save the whole container with all the files in 
> it at once (as a new directory containing all the JPEGs).

Hmm, well, I guess I see your point, but not even mutt supports 
batch-decoding like that. Do you perhaps have a perl script of some 
kind that you use to bulk-decode like that?

> At some time, all this mime crap (that's how I still think of it) 
> was invented.

HEH - way to make me feel old. The first MIME RFC was written in 1993, 
back when I was barely a teenager and was just about to discover the 
wonders of HyperCard. (My First Internet (tm) was AOL.)

But I see what you mean about your definition of an "attachment"... 
though by that logic, a "message" is essentially defined by its 
headers (From/To/Subject/etc.) rather than its content.

> And isn't it outright amazing that the mime guys, in a way, 
> massively failed in clearly defining what an attachment is and what 
> not?

Yes and no. I think a lot of those sorts of oversights tend to be the 
result of assumptions, influenced by popular software abstractions. 
For example, it's easy to assume that an "attachment" is anything the 
user explicitly "attached" (by clicking the "attach" button) and that 
any behind-the-scenes encoding nonsense doesn't count IF (and only if) 
you typically operate at a level where that stuff is handled 
transparently such that you never see it. If, on the other hand, you 
usually read mail with `more` (or `mail` or something else that 
usually shows raw email content), and you tend to *see* the MIME 
encoding, then its easier to think of that as "attached" to the "plain 
text message".

>> As I understand it, this means that a "Message" is generally a 
>> series of text lines similar to that defined in RFC 822 but that 
>> may also be divided into one or more sub-parts that are encoded 
>> according to the MIME standard (RFC 2045). As such, a "message" can 
>> contain another "message", as long as the "contained" message is 
>> encapsulated within a MIME entity/component of the other. Thus, 
>> since a MIME entity can encapsulate another message, the entity's 
>> body may be a full-blown "message" in and of itself.
>
> Why don't they just say that? But what is an entity?

Ehrm... it's defined in section 2.4:

 The term "entity", refers specifically to the MIME-defined header
 fields and contents of either a message or one of the parts in the
 body of a multipart entity. The specification of such entities is
 the essence of MIME. Since the contents of an entity are often
 called the "body", it makes sense to speak about the body of an
 entity. Any sort of field may be present in the header of an
 entity, but only those fields whose names begin with "content-"
 actually have any MIME-related meaning. Note that this does NOT
 imply that they have no meaning at all -- an entity that is also a
 message has non-MIME header fields whose meanings are defined by
 RFC 822.

So... it sounds like, because it's English, words got re-used and 
redefined into confusion. As I understand it, an "entity" is 
essentially anything between a pair of MIME delimiters. Entities have 
a two-part format based on RFC 822 messages: a header section and a 
"the rest of it" section. This latter section is referred to in RFC 
822 as the "body", thus dooming us to talk about the entity's "header" 
and an entity's "body". On top of that, since "beginning of data" and  
"end of data" count as MIME delimiters, an original RFC 822 message 
can be thought of (and often is) as a MIME entity, particularly since  
they usually include MIME information in their header sections.

When a MIME "entity" is a container for other entities, those 
sub-entities are contained within the "body" of their parent. The 
parent entity's "body" is segmented by MIME delimiters, and the 
sub-entities are always contiguous segments of that "body", and can 
therefore be logically referred to as "body parts". Of course, "body 
par

Re: multipart/alternative question

[Noah Slater]

On Fri, Jul 17, 2009 at 10:21:29AM -0600, lee wrote:
> On Fri, Jul 17, 2009 at 02:36:41PM +0100, Noah Slater wrote:
> > I guess in some general sense you are correct, but within the
> > context of a MUA, an attachment has a very specific and well defined
> > meaning, that is much more narrow than this.
>
> Well, I'm not trying to mislead someone. Where is defined what an
> attachment is for the context of a MUA, and who made the definition?

To the best of my knowledge, it isn't defined anywhere. But that doesn't matter.
The common understanding of an attachment is that it is a file, with a filename,
that has been sent as a separate item from the message.

> > An attachment is a message entity that a user is likely to add or
> > save to and from the file system, as separate to the main message.
>
> In Kyles example, that would be saving the html attachment to view it
> in a web browser. The user might do that himself, the MUA might do it
> automatically. If you use a MUA that cannot display text/plain, you
> might save the text/plain to display it ...

This is NOT a typical use case.

> And who is to decide how likely a particular user is to save a
> particular attachment, for the purpose of the MUA counting the
> attachments?

The authors of the MUA.

> To me, it has clearly three attachments. It doesn't matter if a user
> is likely to save an attachment or not.

And you should be free to configure your MUA to display those as attachments,
but the way you think about message parts is uncommon, and would be confusing
for the average user.

Best,

-- 
Noah Slater, http://tumbolia.org/nslater

Re: multipart/alternative question

[lee]

On Fri, Jul 17, 2009 at 06:28:35PM -0500, Kyle Wheeler wrote:
> On Friday, July 17 at 03:58 PM, quoth lee:
> > Hm, somehow I've never had that problem. When reading the message, I 
> > find out if something is attached.
> 
> You're lucky!

Yay! ;)

> But every now and then, I still manage to miss an attached file
> (either because I didn't look, or because it was surprisingly
> small).

That's because mutt doesn't count the attachments right and doesn't
make it very obvious that they are there. Not making it obvious has
advantages in that you don't need to worry about them when viewing a
message. But in your case, it's not so good because it leads you to
miss attachments ... If I got such mails, I might miss them as well.

> > Well, you could have a message with a container. The container could 
> > contain a number of files,
> 
> Hmm, well, I guess I see your point, but not even mutt supports 
> batch-decoding like that. Do you perhaps have a perl script of some 
> kind that you use to bulk-decode like that?

Unfortunately not; but I haven't needed one yet. Saving whole
containers is merely a possibility that comes to mind when considering
attachments as containers that contain something. That's something I
didn't do before. Once you do, it's evident that a MUA could have a
way to save a whole container like that.

Perhaps we should make a feature request? I'm not sure how useful that
would be, but I can imagine that there are ways of explicitly using
it. In case you want to send someone several files, you (or the MUA)
could make a container to contain them. The recipient could save the
whole container instead of having to save all the files separately. If
you want to go a step further, you could invent a way of specifying
something that should be done after saving the files, similar to
Debian packages specifying what to do to configure the software that
is in the package ... Like someone could attach a folder with files in
it, the MUA would attach them as/in a container, and the sender would
specify that "make" should be run after saving the files and then
program that's compiled because he's sending you the new version of
the program. That's a dangerous feature, so the MUA would have to ask
to user before doing something ...

Speaking of which, I sometimes wished that I could just attach a whole
folder instead of having to attach all the files separately. Moott,
that was when I wanted to send several pictures to someone. I would
resize them and convert them to JPEG and collect them in a folder, and
when I had all the pictures gathered, I "naturally" wanted to tell
mutt to send the folder --- but that doesn't work. Since pictures can
be large, the user should be able to specify a size limit after
attaching a folder (or large files) to a message, and the MUA should
automatically split the thing up as needed.

These mime guys did only part of the job --- or maybe it's the MUA
developers. I used to split up files when the message size limit was
64k and had scripts for sending them and splitting them up
automatically. The limits aren't that tight anymore, but the files are
also larger. Try sending someone 5 or 10 TIFFs as they come out of
your camera --- you may find that you can't even send one because he's
got a mailbox limit of 5MB or a size limit of 20MB and one TIFF is
about 18MB ...

So where's the full MUA support of the mime stuff?

> > At some time, all this mime crap (that's how I still think of it) 
> > was invented.
> 
> HEH - way to make me feel old.

Well, how should I feel? ;)

> The first MIME RFC was written in 1993, back when I was barely a
> teenager and was just about to discover the wonders of
> HyperCard. (My First Internet (tm) was AOL.)

You started early then. In 1993, only a few people had even heard
about "internet" --- it was something very expensive that only a few
institutions like universities could/would afford. At that time, I had
news and mail, but no internet ...

> But I see what you mean about your definition of an "attachment"... 
> though by that logic, a "message" is essentially defined by its 
> headers (From/To/Subject/etc.) rather than its content.

*The headers are content.* The headers are the substantial part of the
message.

What content the headers or other parts of a message have doesn't
define what a message is. The definition is formal and doesn't concern
the contents.

You can send something via SMTP that doesn't have headers and a body
because the MTA doesn't care about the content. That's why the SMTP
protocol knows such things as "envelope sender" and "envelope
recipient". What you put into the headers as From: and To: can be
different from what's in the envelope. For example:


l...@cat:~/Mail$ telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 cat.rubenette.is-a-geek.com ESMTP Exim 4.69 Sat, 18 Jul 2009 12:37:07 -0600
helo cat.rubenette.is-a-geek.com
250 cat.rubenette.is-a-geek.com Hello localhost [127.0.0.1

Re: multipart/alternative question

[lee]

On Sat, Jul 18, 2009 at 09:20:49PM +0100, Noah Slater wrote:
> On Fri, Jul 17, 2009 at 10:21:29AM -0600, lee wrote:
> > Well, I'm not trying to mislead someone. Where is defined what an
> > attachment is for the context of a MUA, and who made the definition?
> 
> To the best of my knowledge, it isn't defined anywhere. But that doesn't 
> matter.
> The common understanding of an attachment is that it is a file, with a 
> filename,
> that has been sent as a separate item from the message.

Well, then most people have a wrong understanding.

> > In Kyles example, that would be saving the html attachment to view it
> > in a web browser. The user might do that himself, the MUA might do it
> > automatically. If you use a MUA that cannot display text/plain, you
> > might save the text/plain to display it ...
> 
> This is NOT a typical use case.

Why not? Mutt does it, sup does it. When I have a mail with an html
part and want to view that, I can press ENTER on it and mutt and sup
will start galeon (Yuck! I need to change that.) to display it. I
haven't verified, but I'm pretty sure that the MUA saves the html part
as a file so that a web browser can load the file to display it.

The MUAs probably do the same with other parts of a mail, unless they
can display the part themselves. Since they can display plain text,
they're not saving it, but if they couldn't display plain text,
wouldn't they handle it the same way they handle parts they can't
display themselves?

> > And who is to decide how likely a particular user is to save a
> > particular attachment, for the purpose of the MUA counting the
> > attachments?
> 
> The authors of the MUA.

The RFC leaves it up to the user how he wants to display a (part of a)
message. And since each user has preferences, it's not up to the
authors of the MUA to force the user to display a message in a
particular way or to decide what the user would consider as an
attachment.

> > To me, it has clearly three attachments. It doesn't matter if a user
> > is likely to save an attachment or not.
> 
> And you should be free to configure your MUA to display those as attachments,
> but the way you think about message parts is uncommon, and would be confusing
> for the average user.

Yeah, I configured mutt to count all attachments, but mutt doesn't do
that. It doesn't go into some containers.

Don't get me wrong: Reasonable defaults are fine and should be there,
and since its up to each user, it doesn't matter what you or I or most
users consider as an attachment. As you say, each user should be free
to configure his MUA the way he wants.

Re: multipart/alternative question

[Noah Slater]

On Sat, Jul 18, 2009 at 03:37:32PM -0600, lee wrote:
> > To the best of my knowledge, it isn't defined anywhere. But that doesn't 
> > matter.
> > The common understanding of an attachment is that it is a file, with a 
> > filename,
> > that has been sent as a separate item from the message.
>
> Well, then most people have a wrong understanding.

This is an absurdly prescriptivist statement.

> > > In Kyles example, that would be saving the html attachment to view it
> > > in a web browser. The user might do that himself, the MUA might do it
> > > automatically. If you use a MUA that cannot display text/plain, you
> > > might save the text/plain to display it ...
> >
> > This is NOT a typical use case.
>
> Why not? Mutt does it, sup does it.

Sure, many MUAs will let you do it, but it's not a typical use case.

As in, if you did a survey of all the people on the planet, and asked them if
they had ever saved the HTML component of a simple email message, I am willing
to bet the number would be under 1%.

> > The authors of the MUA.
>
> The RFC leaves it up to the user how he wants to display a (part of a)
> message. And since each user has preferences, it's not up to the
> authors of the MUA to force the user to display a message in a
> particular way or to decide what the user would consider as an
> attachment.

I never said force. I'm only talking about sane defaults.

> > And you should be free to configure your MUA to display those as 
> > attachments,
> > but the way you think about message parts is uncommon, and would be 
> > confusing
> > for the average user.
>
> Yeah, I configured mutt to count all attachments, but mutt doesn't do
> that. It doesn't go into some containers.
>
> Don't get me wrong: Reasonable defaults are fine and should be there,
> and since its up to each user, it doesn't matter what you or I or most
> users consider as an attachment. As you say, each user should be free
> to configure his MUA the way he wants.

Agreed.

Best,

-- 
Noah Slater, http://tumbolia.org/nslater

Re: multipart/alternative question

[lee]

On Sat, Jul 18, 2009 at 10:51:05PM +0100, Noah Slater wrote:
> On Sat, Jul 18, 2009 at 03:37:32PM -0600, lee wrote:
> > > To the best of my knowledge, it isn't defined anywhere. But that doesn't 
> > > matter.
> > > The common understanding of an attachment is that it is a file, with a 
> > > filename,
> > > that has been sent as a separate item from the message.
> >
> > Well, then most people have a wrong understanding.
> 
> This is an absurdly prescriptivist statement.

I'm not sure what "prescriptivist" means. See Message-ID: 
<20090718204148.ga8...@cat.rubenette.is-a-geek.com>,
there's an explanation why I could maintain saying that.

> As in, if you did a survey of all the people on the planet, and
> asked them if they had ever saved the HTML component of a simple
> email message, I am willing to bet the number would be under 1%.

A simple email message doesn't have any HTML components.

You probably wouldn't get any valid results from such a survey because
the percentage of people who wouldn't know what you're talking about
would be too high.

Re: multipart/alternative question

[Noah Slater]

On Sat, Jul 18, 2009 at 09:37:04PM -0600, lee wrote:
> On Sat, Jul 18, 2009 at 10:51:05PM +0100, Noah Slater wrote:
> > On Sat, Jul 18, 2009 at 03:37:32PM -0600, lee wrote:
> > > > To the best of my knowledge, it isn't defined anywhere. But that 
> > > > doesn't matter.
> > > > The common understanding of an attachment is that it is a file, with a 
> > > > filename,
> > > > that has been sent as a separate item from the message.
> > >
> > > Well, then most people have a wrong understanding.
> >
> > This is an absurdly prescriptivist statement.
>
> I'm not sure what "prescriptivist" means.

Compare the following topics:

  http://en.wikipedia.org/wiki/Descriptive_linguistics

  http://en.wikipedia.org/wiki/Linguistic_prescription

In other words, if "most people" think "attachment" means "X" then, by
definition, attachment means "X" - regardless of your personal preference for
what it should mean. This is how language works.

> > As in, if you did a survey of all the people on the planet, and
> > asked them if they had ever saved the HTML component of a simple
> > email message, I am willing to bet the number would be under 1%.
>
> A simple email message doesn't have any HTML components.

That depends on what you mean by "simple" - and you have already demonstrated
that your definitions are unusual. That is not meant to be offensive, because I
can see where you're coming from. Nevertheless.

> You probably wouldn't get any valid results from such a survey because
> the percentage of people who wouldn't know what you're talking about
> would be too high.

I think that would probably support my thesis. Heh.

Best,

-- 
Noah Slater, http://tumbolia.org/nslater

Re: multipart/alternative question

[lee]

On Sat, Jul 18, 2009 at 09:37:04PM -0600, lee wrote:
> I'm not sure what "prescriptivist" means. See Message-ID: 
> <20090718204148.ga8...@cat.rubenette.is-a-geek.com>,
> there's an explanation why I could maintain saying that.

Sorry, you might have that. Here's the References: header
(which you probably have):

References: <20090716055919.ga6...@cat.rubenette.is-a-geek.com> 
<20090716141914.gc4...@atakapa.local>
<20090717021854.ga7...@cat.rubenette.is-a-geek.com> 
<20090717030916.gn4...@atakapa.local>
<20090717042711.gf7...@cat.rubenette.is-a-geek.com> 
<20090717053919.gp4...@atakapa.local>
<20090717173748.gd14...@cat.rubenette.is-a-geek.com> 
<20090717183804.gt4...@atakapa.local>
<20090717215821.gf1...@cat.rubenette.is-a-geek.com> 
<20090717232835.gw4...@atakapa.local>

Re: multipart/alternative question

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Saturday, July 18 at 02:41 PM, quoth lee:
>> Hmm, well, I guess I see your point, but not even mutt supports 
>> batch-decoding like that. Do you perhaps have a perl script of some 
>> kind that you use to bulk-decode like that?
>
> Unfortunately not; but I haven't needed one yet. Saving whole 
> containers is merely a possibility that comes to mind when considering 
> attachments as containers that contain something. That's something I 
> didn't do before. Once you do, it's evident that a MUA could have a 
> way to save a whole container like that.
>
> Perhaps we should make a feature request?

Well, I was thinking that it might be possible using tags and piping 
with a slick perl script, that you could glue together with a macro..

> Speaking of which, I sometimes wished that I could just attach a 
> whole folder instead of having to attach all the files separately.

You *can* do the tag-and-attach approach. Saves time over attaching 
each file independently.

> Since pictures can be large, the user should be able to specify a 
> size limit after attaching a folder (or large files) to a message, 
> and the MUA should automatically split the thing up as needed.
>
> These mime guys did only part of the job --- or maybe it's the MUA 
> developers.

It's the MUA developers. MIME supports a "message/partial" entity type 
(section 7.3.2 of RFC 1521), which allows a "message" (i.e. a MIME 
structure) to be split up across multiple emails. Outlook Express 
supports it, but it's the only MUA I know of that does. The origin of 
the idea was to avoid problems with slow unreliable modems that 
periodically disconnected, so that if you've only partially uploaded 
your giant email to someone, at least part of it will have been sent 
(and received)... it just can't be decoded & viewed until you've sent 
all the pieces of it. It could also be used to circumvent limits on 
single message sizes.

> So where's the full MUA support of the mime stuff?

Good question.

For what it's worth, another way to segment large files (or 
collections of files) is to use the shell utility `split` (and the 
recipient can use `cat` to put them all together again). Combine that 
with `tar`, and you can pretty efficiently chunk up large collections 
of files. Then, again using your shell (assuming all the segments are 
in a folder called "segments"), you can send those segments using 
mutt, like this:

 for F in segments/* ; do
 mutt -s "segment $F" -a $F -- recipi...@example.com
 done

Not exactly *convenient*, though... but unless your recipient is using 
Outlook Express, there's not much point in using a MIME trick that 
they can't take advantage of.

> The content doesn't matter. No message without headers, but headers 
> are content.

A fair point. Kind of like saying "no file without an inode".

>> So... it sounds like, because it's English, words got re-used and 
>> redefined into confusion.
>
> Hm. I was about to say that it doesn't have to be that way, but, since 
> I'm German, I find that English, at least American English, is mott 
> very sloppy and indistinctive with things. There are distinctions I 
> "naturally" make in German that nobody makes in English. That means 
> they are not aware that there is the possibility of making a 
> distinction. English doesn't allow them to think of one, it sets 
> limits. I can't tell if that's really true because I might not feel 
> that way if English was my native language --- and it's impossible to 
> tell because if English was my native language, I wouldn't be aware of 
> the possibility (unless I learned another language, maybe).

English has its trade-offs, like most things. While it is a bit sloppy 
and leaves a lot up to interpretation, that leads to lots of fun 
double- or triple-entendres (which has benefits in the realms of 
poetry, humor, and other forms of literature), and lets us use nouns 
as verbs, among other things. By not requiring the speaker to make 
distinctions about everything, it leaves a lot more room for 
interpretation, which is both liberating and frustrating for the exact 
same reason.

~Kyle
- -- 
The fact that we live at the bottom of a deep gravity well, on the 
surface of a gas-covered planet going around a nuclear fireball 90 
million miles away, and think this to be normal, is obviously some 
indication of how skewed our perspective tends to be.
   -- Douglas Adams
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKY3nmAAoJECuveozR/AWekz8QAIlUPfrwS+cPRCRlBqNzb8F9
k0LYtU6JzkScYvQpdYZWKcHhoPKAPKrc/7TRneaMUBQVkqnlxuV02x3peaTRTY16
KKmXx+Oviw6/MRHBRQR+F9lqTqjEJEXf/GJDRXjfZb66ZhtwCPzu+d8DKAQ5jhE2
N6c8EpN9iscETgA4yRHs+f4MBuutKKbFy8hZ7+7hpI565Jb+YBRaQl0cJ+spJWVO
c+NG7ePQjsASX26USru34Sra0FeNzH5+VCWS9GoxBYKPdjJT53b4p4j4gukIDkgI
/IRuvmkZuAlOYlio1XN8+786iSz4We5E+HkMv57JaGKruxAEhoYjUSLMfjmPYlj7
72Mp0XwndhIbbjKrSd

Re: multipart/alternative question

[lee]

At Sun, 19 Jul 2009 04:50:05 +0100,
Noah Slater wrote:
> 
> On Sat, Jul 18, 2009 at 09:37:04PM -0600, lee wrote:
> > On Sat, Jul 18, 2009 at 10:51:05PM +0100, Noah Slater wrote:
> > > On Sat, Jul 18, 2009 at 03:37:32PM -0600, lee wrote:
> > > > > To the best of my knowledge, it isn't defined anywhere. But that 
> > > > > doesn't matter.
> > > > > The common understanding of an attachment is that it is a file, with 
> > > > > a filename,
> > > > > that has been sent as a separate item from the message.
> > > >
> > > > Well, then most people have a wrong understanding.
> > >
> > > This is an absurdly prescriptivist statement.
> >
> > I'm not sure what "prescriptivist" means.
> 
> In other words, if "most people" think "attachment" means "X" then, by
> definition, attachment means "X" - regardless of your personal preference for
> what it should mean. This is how language works.

Ah, I see what you mean. But aren't RFCs prescriptive by nature? And
if they are, it's silly to say that a statement resulting of an
interpretation of an RFC is "absurdly prescriptive". --- The
interpretation can be wrong, but that's another question.

> > A simple email message doesn't have any HTML components.
> 
> That depends on what you mean by "simple"

sure does

> > You probably wouldn't get any valid results from such a survey because
> > the percentage of people who wouldn't know what you're talking about
> > would be too high.
> 
> I think that would probably support my thesis. Heh.

I don't see how invalid results could support a hypothesis based on
them.

If you ask 100 people the way to the museum while having a hypothesis
that you should go to the right and about 90 of them tell you that
they don't know what you're talking about, would you think that the
answer you got from those 90 people supports your hypothesis? Or would
you rather ignore their answers?

Re: multipart/alternative question

[lee]

At Sun, 19 Jul 2009 14:54:15 -0500,
Kyle Wheeler wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Saturday, July 18 at 02:41 PM, quoth lee:
> >> Hmm, well, I guess I see your point, but not even mutt supports 
> >> batch-decoding like that. Do you perhaps have a perl script of some 
> >> kind that you use to bulk-decode like that?
> 
> > Perhaps we should make a feature request?
> 
> Well, I was thinking that it might be possible using tags and piping 
> with a slick perl script, that you could glue together with a macro..

Yeah, IIRC, there are perl libraries to handle mime things. Or you
could always make some bash script that uses one of the softwares that
can handle mime, like metamail, to send a whole folder out as a
message. Another script could handle unpacking the message.

> > Speaking of which, I sometimes wished that I could just attach a 
> > whole folder instead of having to attach all the files separately.
> 
> You *can* do the tag-and-attach approach. Saves time over attaching 
> each file independently.

I know, but I just happend to try to attach the whole folder
somethimes without thinking and then found that I can't ...

> > So where's the full MUA support of the mime stuff?
> 
> Good question.
> 
> For what it's worth, another way to segment large files (or 
> collections of files) is to use the shell utility `split`
> 
> Not exactly *convenient*, though... but unless your recipient is using 
> Outlook Express, there's not much point in using a MIME trick that 
> they can't take advantage of.

Hm. I wonder what mutt --- or wanderlust, which I'm trying out now ---
would do with messages containing parts of files. You might be able to
save something from each message but then be left with the problem of
having to figure out how to put the pieces together.

> English has its trade-offs, like most things. While it is a bit sloppy 
> and leaves a lot up to interpretation, that leads to lots of fun 
> double- or triple-entendres (which has benefits in the realms of 
> poetry, humor, and other forms of literature), and lets us use nouns 
> as verbs, among other things. By not requiring the speaker to make 
> distinctions about everything, it leaves a lot more room for 
> interpretation, which is both liberating and frustrating for the exact 
> same reason.

That's probably true for other languages as well, in one way or
another, to a greater or lesser extent. I wonder if there's a German
translation of that RFCs --- it's probably extremely difficult to
translate if the interpreter was to transcribe what it's supposed to
mean to the full extent ... I've always been reading things like that
in English, even when there was a translated version available. It's a
lot easier because the translations ignore that the original
originates from a totally different mindset, which makes them hard to
understand and sometimes even incomprehensible.

For example, there is no German word for "segmentation fault". It is
not translatable not only because there isn't a word for it, there's
also no concept for it. Interpreters confronted with the problem of
translating it made something up, but it is nonsense. It's like trying
to explain to a blind person what colors look like.

When you watch German TV, you start asking yourself where you are
because like half the words are English. They do that to make what
they are saying to appear important, and the less they know what they
are trying to say, the more English words they (ab-)use. It's really
awful --- but nobody would ever say "segmentation fault".

Multipart/alternative and default attachments

[Clint Olsen]

Hello:

I'm getting multipart/alternative emails from friends/family, and the
default seems to be html, but the non-HTML version appears there in the
attachments menu.  Is there a way to read the ASCII version by default in
Mutt so I don't have to spin up lynx?

Thanks,

-Clint

Re: Sending multipart/alternative attachments

[Will Yardley]

Gary Johnson wrote:
> 
> Before this degenerates into a discussion of "Why would you ever want
> to do that?" and "Mail should be text/plain":  The reason I want this
> is that as secretary for an organization, I need to regularly
> distribute a form to the members.  The form was written as a Word
> document, and I'm sure that most members would like it in that format,
> but I would like to also distribute a text/plain version.

well in the compose screen, you can attach as many documents as you
like, and they'll show up as MIME multipart.  so compose your message,
then exit the editor and hit 'a' to attach the first document, rinse,
lather, repeat.

that should do what you want, no?

-- 
Experience -- a great teacher, but the tutition fees...

Re: Sending multipart/alternative attachments

[Gary Johnson]

On Wed, Dec 19, 2001 at 11:21:00AM -0800, Will Yardley wrote:

> well in the compose screen, you can attach as many documents as you
> like, and they'll show up as MIME multipart.  so compose your message,
> then exit the editor and hit 'a' to attach the first document, rinse,
> lather, repeat.
> 
> that should do what you want, no?

That will give me multiple attachments, which may be good enough, but I
was hoping to use the "alternative" tag to allow each recipient's MUA to
display only one version of the attachment, the one with the user's
preferred Content-Type.  I was also hoping this would cue the recipients
that there really is only one form they need to fill out, without me
having to spell it out in the cover letter.  On the other hand, maybe
giving them an explicit choice of formats would be better.

Gary

-- 
Gary Johnson   | Agilent Technologies
[EMAIL PROTECTED]   | Spokane, Washington, USA
http://www.spocom.com/users/gjohnson/mutt/ |

Re: Sending multipart/alternative attachments

[Thomas Hurst]

Ooops, proof that that X-Uptime header's not entirely useless.  Just
noticed I had a locked-up proftpd process that's been there for the last
4 hours :)

* Gary Johnson ([EMAIL PROTECTED]) wrote:

> I've RTFM and haven't seen a way for mutt to send (not display)
> multipart/alternative attachments.  Is there an external program that
> can be used with mutt to do this?  I was considering using an existing
> message as a template, but I thought I read where the boundary string
> has to be unique and I'd rather not have to guess at a unique sequence
> and edit the boundary manually.  Besides, it would be much easier to
> have the attachments assembled automatically and after all, that's
> what computers are for.

Have mutt generate the MIME stuff, then post-filter the message to alter
the headers to make it mutlipart/alternative?

It should be specified in an rfc anyway; good idea to read that if you
can't have something else generate it for you.

-- 
Thomas 'Freaky' Hurst  -  [EMAIL PROTECTED]  -  http://www.aagh.net/

Re: Sending multipart/alternative attachments

[Thomas Hurst]

* Gary Johnson ([EMAIL PROTECTED]) wrote:

> On the other hand, maybe giving them an explicit choice of formats
> would be better.

Personally I'd multipart/alternate the Word version so even if word
breaks they can still read the message, and give a choice of not
including the word version at signup.  Same with HTML; I may well be
able to read HTML messages, but if lynx breaks I'd still like to be able
to read it, if only to find how to change it :)

-- 
Thomas 'Freaky' Hurst  -  [EMAIL PROTECTED]  -  http://www.aagh.net/

Re: Sending multipart/alternative attachments

[Gary Johnson]

On Wed, Dec 19, 2001 at 08:02:03PM +, Thomas Hurst wrote:
> * Gary Johnson ([EMAIL PROTECTED]) wrote:
> 
> > On the other hand, maybe giving them an explicit choice of formats
> > would be better.
> 
> Personally I'd multipart/alternate the Word version so even if word
> breaks they can still read the message, and give a choice of not
> including the word version at signup.  Same with HTML; I may well be
> able to read HTML messages, but if lynx breaks I'd still like to be able
> to read it, if only to find how to change it :)

What I meant was that maybe I should send the attachments to everyone as
multipart/mixed so that they would see two attachments, form.doc and
form.txt, and could decide when they respond which version they want to
fill out.  I would prefer not to keep track of which recipients prefer
which version, but I suppose that really wouldn't be that much extra
work.

Gary

-- 
Gary Johnson   | Agilent Technologies
[EMAIL PROTECTED]   | Spokane, Washington, USA
http://www.spocom.com/users/gjohnson/mutt/ |

multipart/alternative and text/html

[Philip Mak]

How can I make mutt able to display text/html attachments inline, WITHOUT
making it pick text/html (instead of text/plain) when the original message
was sent as multipart/alternative? I find the text/html versions to be
formatted worse.

This is my .mailcap for text/html:

text/html; lynx %s; nametemplate=%s.html
text/html; lynx -dump %s; nametemplate=%s.html; copiousoutput

Also, should I look into using "w3m" or "links" instead of "lynx"? I heard
that some people (prefer to?) use those.

Re: Multipart/alternative and default attachments

[David DeSimone]

Clint Olsen <[EMAIL PROTECTED]> wrote:
>
> I'm getting multipart/alternative emails from friends/family, and the
> default seems to be html, but the non-HTML version appears there in
> the attachments menu.

You can choose preferred alterative views with the alternative_order
command.  By default, Mutt will choose a view from this list.  If you
don't give a list, Mutt will choose from whatever types it considers to
be "auto-viewable".  That is, a type which has a "copiousoutput" tag in
your .mailcap.  If none of these are found, Mutt will choose text/plain,
text/enriched, or text/html, in that order.  Beyond that Mutt will
choose whatever it can make sense out of.

> Is there a way to read the ASCII version by default in Mutt so I don't
> have to spin up lynx?

It sounds like someone has set up the alternative_order differently on
your system.  Here's how mine is set in .muttrc:

alternative_order  text/enriched  text/plain  text/html

-- 
David DeSimone   | "The doctrine of human equality reposes on this:
[EMAIL PROTECTED]   |  that there is no man really clever who has not
Hewlett-Packard  |  found that he is stupid." -- Gilbert K. Chesterson
Richardson IT|PGP: 5B 47 34 9F 3B 9A B0 0D  AB A6 15 F1 BB BE 8C 44

Re: multipart/alternative and text/html

[Philip Mak]

On Sun, Jan 06, 2002 at 09:21:25PM +0700, budsz wrote:
> >How can I make mutt able to display text/html attachments inline, WITHOUT
> >making it pick text/html (instead of text/plain) when the original message
> >was sent as multipart/alternative? I find the text/html versions to be
> >formatted worse.
> 
> If you want to make easy pls install metamail, copy mailcap to home
> directory.

I don't understand how that applies to my problem... I already have
metamail installed on my system, and my .mailcap file IS in my home
directory.

BTW, why'd you CC your message to [EMAIL PROTECTED] instead of
[EMAIL PROTECTED]?

Re: multipart/alternative and text/html

[David T-G]

Philip --

...and then Philip Mak said...
% 
% How can I make mutt able to display text/html attachments inline, WITHOUT
% making it pick text/html (instead of text/plain) when the original message
% was sent as multipart/alternative? I find the text/html versions to be
% formatted worse.

Look into section 5.5 of the manual and put something like

  auto_view text/html   # autoview of HTML after dump 
from lynx (see .mailcap)
  alternative_order text/plain text/enriched text/html  # I'd prefer simple text, 
though; got some?

into your muttrc file.


% 
% This is my .mailcap for text/html:
% 
% text/html; lynx %s; nametemplate=%s.html
% text/html; lynx -dump %s; nametemplate=%s.html; copiousoutput
% 
% Also, should I look into using "w3m" or "links" instead of "lynx"? I heard
% that some people (prefer to?) use those.

I hear that both are good, but have been too lazy to check them out :-)


:-D
-- 
David T-G  * It's easier to fight for one's principles
(play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie
(work) [EMAIL PROTECTED]
http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg!




msg22404/pgp0.pgp
Description: PGP signature

Re: multipart/alternative and text/html

[Nuno Teixeira]

On Sun, Jan 06, 2002 at 04:23:36PM -0500, David T-G wrote:
| Philip --
| 
| ...and then Philip Mak said...
| % 
| % How can I make mutt able to display text/html attachments inline, WITHOUT
| % making it pick text/html (instead of text/plain) when the original message
| % was sent as multipart/alternative? I find the text/html versions to be
| % formatted worse.
| 
| Look into section 5.5 of the manual and put something like
| 
|   auto_view text/html # autoview of HTML after dump 
|from lynx (see .mailcap)
|   alternative_order text/plain text/enriched text/html# I'd prefer simple 
|text, though; got some?
| 
| into your muttrc file.
| 
| 
| % 
| % This is my .mailcap for text/html:
| % 
| % text/html; lynx %s; nametemplate=%s.html
| % text/html; lynx -dump %s; nametemplate=%s.html; copiousoutput
| % 
| % Also, should I look into using "w3m" or "links" instead of "lynx"? I heard
| % that some people (prefer to?) use those.
| 
| I hear that both are good, but have been too lazy to check them out :-)
| 
| 
| :-D
| -- 
| David T-G  * It's easier to fight for one's principles
| (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie
| (work) [EMAIL PROTECTED]
| http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg!
| 

  Hi,
  
  Can I use the same config with w3m?
  
  Thanks,

-- 
Nuno Teixeira
pt-quorum.com

/* 
PGP Public Key:
http://www.pt-quorum.com/pgp/nunoteixeira.asc
Key fingerprint:
8C2C B364 D4DC 0C92 56F5  CE6F 8F07 720A 63A0 4FC7
*/

Re: multipart/alternative and text/html

[Im Eunjea]

* Nuno Teixeira <[EMAIL PROTECTED]> [2002-01-06 22:06]:
>   
>   Can I use the same config with w3m?
>   

Yes, you can.
This is my mailcap entry:

#text/html; w3m %s; nametemplate=%s.html
text/html; w3m -dump %s; nametemplate=%s.html; copiousoutput


-- 
Eunjea <[EMAIL PROTECTED]>

GnuPG fingerprint: 08C9 2D3F 91B2 D395 2EFF  4C33 544C 321C E194 91CF



msg22409/pgp0.pgp
Description: PGP signature

Displaying multipart/alternative as multipart/mixed

[Simon Kirby]

Hi!

It seems a billion things lately send email such as:

Content-type: multipart/alternative

text/plain part: Your mailer sucks!

text/html part: intended body

rather than just leaving out the useless text/plain part or sending a
useful text/plain version.

I can view them by selecting the right part, but to be honest, I'd much
rather view it as if it was mailed as multipart/mixed, since then I can
see that the email is silly and have all of the parts on the screen at
once, saving time.

The only alternative is to put text/html first on alternative_order.
Doing that for outlook by deault would probably help, but that's not
really what I want for everything else.

Is there a knob that would allow this?

Simon-

Re: Displaying multipart/alternative as multipart/mixed

[Christian Ebert]

* Simon Kirby on Thursday, March 24, 2016 at 17:16:53 -0700
> It seems a billion things lately send email such as:
> 
> Content-type: multipart/alternative
> 
> text/plain part: Your mailer sucks!
> 
> text/html part: intended body
> 
> rather than just leaving out the useless text/plain part or sending a
> useful text/plain version.
> 
> I can view them by selecting the right part, but to be honest, I'd much
> rather view it as if it was mailed as multipart/mixed, since then I can
> see that the email is silly and have all of the parts on the screen at
> once, saving time.
> 
> The only alternative is to put text/html first on alternative_order.
> Doing that for outlook by deault would probably help, but that's not
> really what I want for everything else.
> 
> Is there a knob that would allow this?

Not automated, but I use the following to toggle
alternative_order with a keystroke:

# toggle alternative_order
macro pager ,@aot= "\
 unalternative_order *; \
alternative_order text/enriched text/plain text/html text 
application/postscript image/*; \
macro pager A ,@aoh= 'prefer html over text'\
"
#
macro pager ,@aoh= "\
 unalternative_order *; \
alternative_order text/enriched text/html text/plain text 
application/postscript image/*; \
macro pager A ,@aot= 'prefer text over html'\
"
#
macro pager A ,@aoh= "prefer html over text"

-- 
theatre - books - texts - movies
Black Trash Productions at home: http://www.blacktrash.org
Black Trash Productions on Facebook:
http://www.facebook.com/blacktrashproductions

Holy Grail (multipart/alternative + HTML + inline images + GPG)

[Patrice Levesque]

Hi.

This subject has been discussed many times over the years, and I'm
having a go at it.

Because mutt's native support for multipart/alternative seems
insufficient for what I'm trying to achieve, I'm aiming to get this
flow:

1) Use mutt (write text/plain mail, set mail headers (recipients,
subject, others) and handle file attachments).

2) [Message pushed somewhere, via a mutt macro, that could save
locally in a mailbox, or pipe to a file, or anything: mechanism does
not really matter to me].

3) Message is massaged by a script that rebuilds the MIME sections
of the mail, adding a text/html section (transcoding text/plain via
Markdown or other tool) and adding related HTML inline images (for
signature).  MIME structure becomes:

- multipart/mixed
    - multipart/alternative
- text/plain
- multipart/related
- text/html
- inline image
- attachments

4) Message returns to mutt, which handles GPG, archiving to
appropriate Fcc, sending out for transport.

Now my blocker comes from (4).  No matter if I try to `recall-message`
(Shift-R), `resend-message` (Esc-e) or mutt's `-H` option, the
multipart/alternative part gets corrupted by mutt.  I'm trying to tell
mutt “Please just send it as it is”.  `bounce-message` (b) leaves mail
structure intact but of course modifies recipients.

Any possible way to achieve that “send as is” behaviour, or do you guys
know any patch in the wild that would allow that?

Thanks,



-- 
· Patrice Levesque
· http://ptaff.ca/
· mutt.wa...@ptaff.ca
--



signature.asc
Description: Digital signature

Re: Holy Grail (multipart/alternative + HTML + inline images + GPG)

[Michelle Konzack]

On 2017-01-25 07:55:05 Patrice Levesque hacked into the keyboard:
>   - multipart/mixed
>   - multipart/alternative
>   - text/plain
>   - multipart/related
>   - text/html
>   - inline image
>   - attachments

Are you sure, you have closed every part properly?

I do some things similary, BUT I use commandline tools,  to  create  the
multipart/alternative  and  then  I  move  the  complete  file  to   the
~/Maildir/.Drafts/new/ folder, where mutt can find  it  if  I  recall  a
message.

> Any possible way to achieve that “send as is” behaviour, or do you guys
> know any patch in the wild that would allow that?

You can use sendmail or ssmtp to send the file without using mutt.
It is much easier, specially from a script.

-- 
Michelle KonzackITSystems
GNU/Linux Developer 0033-6-61925193


signature.asc
Description: Digital signature

Re: Holy Grail (multipart/alternative + HTML + inline images + GPG)

[Patrice Levesque]

>> [MIME message structure description]
> Are you sure, you have closed every part properly?

I used the swiftmailer library to construct the mail and mutt properly
recognizes the parts when it receives the mail via a bounce, so I
suspect the mail is well-formed but of course there might be subtleties.


> I do some things similary, BUT I use commandline tools,  to  create
> the multipart/alternative  and  then  I  move  the  complete  file  to
> the ~/Maildir/.Drafts/new/ folder, where mutt can find  it  if  I
> recall  a message.

I'm happy it seems to work for you, and that the problem's probably in
my chair.  Would you be kind enough to send me a direct email to
mutt.wa...@ptaff.ca using your method? That may help me figure out
what's so different between your mail structure and mine.

Just out of curiosity, when you recall the message, does the editor show
only the text/plain part? It seems I always get an improperly unwrapped
version of the multipart/alternative part.  And when you exit the
editor, are you saying all MIME parts left unchanged?


> You can use sendmail or ssmtp to send the file without using mutt.  It
> is much easier, specially from a script.

I get that, but I'd prefer dealing with GPG inside mutt, I want to avoid
recreating mutt's perfectly fine interface for it (selecting keys for
instance).


Thanks, and have a nice day,



-- 
· Patrice Levesque
· http://ptaff.ca/
· mutt.wa...@ptaff.ca
--



signature.asc
Description: Digital signature

Re: Holy Grail (multipart/alternative + HTML + inline images + GPG)

[Michelle Konzack]

On 2017-01-26 08:24:30 Patrice Levesque hacked into the keyboard:
> I'm happy it seems to work for you, and that the problem's probably in
> my chair.  Would you be kind enough to send me a direct email to
> mutt.wa...@ptaff.ca using your method? That may help me figure out
> what's so different between your mail structure and mine.

Currently not possibel, because the script is on my server @home which I
can not access trough the Internet and I work currently 600km far away.

> Just out of curiosity, when you recall the message, does the editor show
> only the text/plain part? It seems I always get an improperly unwrapped
> version of the multipart/alternative part.  And when you exit the
> editor, are you saying all MIME parts left unchanged?

I see the text/plain part only.
I can not edit the text/html part.

Ehm yes, I get all parts presented and it looks like

8<--
From: linux4michelle
To: admin
Cc: 
Bcc: 
Subject: Only a test
Reply-To: 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="All_the_parts"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format

--All_the_parts
Content-Type: multipart/alternative; boundary="Some_text";

--Some_text
Content-Type: text/plain

Hello World!

--Some_text
Content-Type: text/html

Hello World!

--Some_text--

--All_the_parts
Content-Type: image/png; name="mutt.png"
Content-Disposition: attachment; filename="mutt.png"
Content-Transfer-Encoding: base64



--All_the_parts--

8<--

> I get that, but I'd prefer dealing with GPG inside mutt, I want to avoid
> recreating mutt's perfectly fine interface for it (selecting keys for
> instance).
> 
> 
> Thanks, and have a nice day,

-- 
Michelle KonzackITSystems
GNU/Linux Developer 0033-6-61925193


signature.asc
Description: Digital signature

Re: Holy Grail (multipart/alternative + HTML + inline images + GPG)

[Patrice Levesque]

Michelle,


> Currently not possibel, because the script is on my server @home which
> I can not access trough the Internet and I work currently 600km far
> away.

Would've been neat, but I think you gave me enough pointers so far that
I can manage on my own for a bit.  Thanks again for your time and
extensive answers.



-- 
· Patrice Levesque
· http://ptaff.ca/
· mutt.wa...@ptaff.ca
--



signature.asc
Description: Digital signature