Sending attachments

[Robert J. Chassell]

mime-compose-1.5.el is 52576 bytes and 1284 lines long including a
commented out patch for the Sun Record program demo.  Without the patch,
mime-compose-1.5.el is 49428 bytes and 1182 lines long.

--
    Robert J. Chassell                          
    bob@...                         bob@...
    http://www.rattlesnake.com                  http://www.teak.cc

[Teemu Likonen-2]

On 2009-07-03 18:52 (-0400), Richard Stallman wrote:

> I don't want to replace the simple sendmail.el with this tremendous
> pile of complexity.

I have an idea: Let's have two different modes, a simple mode called
mail-mode and a complex mode named message-mode which has more features.
People who like simplicity can use mail-mode and people who need more
features can use message-mode. How does that sound? :-)

> message.el is also 8000 lines long, where sendmail.el is under 2000
> lines.  I expect that sending attachments won't require more than 200
> lines.

I think it's clear that message-mode contains more features over
mail-mode than just attachments.

A humble request from a user: if some kind of code reordering or merging
of the modes takes place please don't cripple message-mode's current
features too badly.

[Andreas Schwab-2]

Richard Stallman <rms@...> writes:

> According to the documentation in "(emacs-mime)Composing",
> one must put certain text in the buffer
> which then gets converted to Mime parts,
>
> Maybe that is convenient for some cases, but what I would like
> is a simpler command that just attaches a file.
>
> Has anyone written such a thing?

C-c RET f runs the command mml-attach-file, which is an interactive
compiled Lisp function in `mml.el'.

It is bound to <menu-bar> <Attachments> <Attach File...>, C-c RET f, C-c
C-a.

(mml-attach-file file &optional type description disposition)

Attach a file to the outgoing MIME message.
The file is not inserted or encoded until you send the message with
`C-c C-c' or `C-c C-s'.

file is the name of the file to attach.  type is its
content-type, a string of the form "type/subtype".  description
is a one-line description of the attachment.  The disposition
specifies how the attachment is intended to be displayed.  It can
be either "inline" (displayed automatically within the message
body) or "attachment" (separate from the body).

Andreas.

--
Andreas Schwab, schwab@...
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[Chad Brown-4]

On Jul 3, 2009, at 7:21 AM, Alfred M. Szmidt wrote:

> That is much  unneeded work, the only thing  that uses message-mode is
> gnus.

MH-e uses message-mode, as do a few third-party elisp mail packages  
(or they did when I last looked, a few years ago).  For better or  
worse, MIME handling is seen as necessary in most elisp mail packages,  
and is tremendously fiddly, which leaves most people relying on the  
gnus-ish code.

Sadly, I'm not in a good position to offer to help with either  
proposal, but I doubt that you can make mail-mode usable for the mime-
handling features that multiple packages want from message-mode  
without significant (mostly duplicated) effort.

*Chad

[Eli Zaretskii]

> From: Chad Brown <yandros@...>
> Date: Sat, 4 Jul 2009 08:33:56 -0700
>
> I doubt that you can make mail-mode usable for the mime- handling
> features that multiple packages want from message-mode without
> significant (mostly duplicated) effort.

Could you please post a list of the features you had in mind, so that
the effort could be estimated?

Just looking at email messages with MIME attachments, it looks like
each attachment is just a fancy header line and a body encoded by
either base64 or quoted-printable.  Implementing a simple command that
asks for a file name and then encodes it and puts the result in the
*mail* buffer sounds easy enough, so I'm sure I'm missing something.

[leon-9]

On 2009-07-04 16:11 +0100, Teemu Likonen wrote:
> I have an idea: Let's have two different modes, a simple mode called
> mail-mode and a complex mode named message-mode which has more
> features. People who like simplicity can use mail-mode and people who
> need more features can use message-mode. How does that sound? :-)

There are already a few variants.

,----[ C-h v mail-user-agent RET ]
|   `sendmail-user-agent' -- use the default Emacs Mail package.
|                            See Info node `(emacs)Sending Mail'.
|   `mh-e-user-agent'     -- use the Emacs interface to the MH mail system.
|                            See Info node `(mh-e)'.
|   `message-user-agent'  -- use the Gnus Message package.
|                            See Info node `(message)'.
|   `gnus-user-agent'     -- like `message-user-agent', but with Gnus
|                            paraphernalia, particularly the Gcc: header for
|                            archiving.
`----

I'd prefer the core functionality of both sendmail and message-mode be
merged into a library that offers a default send mail interface and also
a basis for all other MUAs like gnus, mh-e etc. if they need extra stuff
than the default.

--
Leo's Emacs uptime: 24 days, 2 hours, 2 minutes, 12 seconds

[Chad Brown-6]

On Jul 4, 2009, at 8:53 AM, Eli Zaretskii wrote:

>> From: Chad Brown <yandros@...>
>> Date: Sat, 4 Jul 2009 08:33:56 -0700
>>
>> I doubt that you can make mail-mode usable for the mime- handling
>> features that multiple packages want from message-mode without
>> significant (mostly duplicated) effort.
>
> Could you please post a list of the features you had in mind, so that
> the effort could be estimated?
>
> Just looking at email messages with MIME attachments, it looks like
> each attachment is just a fancy header line and a body encoded by
> either base64 or quoted-printable.  Implementing a simple command that
> asks for a file name and then encodes it and puts the result in the
> *mail* buffer sounds easy enough, so I'm sure I'm missing something.

I'm sorry to say that it's unlikely, but I will see if I can do.  Most  
of my experience with this sort of thing comes from long-ago work on  
MH-e, wherein I found that simple MIME is pretty easy but everything  
turns crazy when you hit multipart/mixed and multipart/alternative.  
If the goal is simply to be able to attach files to messages, then the  
code required is very simple (my long-ago MH-e for doing so was less  
than 15 lines of elisp).  If you want to handle the larger range of  
MIME options, the complication is hard to avoid.

To be more specific about what I was trying to say:   I doubt that  
mail-mode can be made into a replacement for message-mode for things  
like MH-e easily, and I expect the result will duplicate most of  
message mode.  Adding a simple `attach file' to mail-mode is probably  
not very hard at all, but the result won't allow you to drop message-
mode/mml (it's been long enough that I forget which parts are where).

*chad

[Richard Stallman]

Etach looks like just what I had in mind.
(The parts that interact with Rmail need updating.)

[Daniel Pittman]

Eli Zaretskii <eliz@...> writes:

>> From: Chad Brown <yandros@...>
>> Date: Sat, 4 Jul 2009 08:33:56 -0700
>>
>> I doubt that you can make mail-mode usable for the mime- handling
>> features that multiple packages want from message-mode without
>> significant (mostly duplicated) effort.
>
> Could you please post a list of the features you had in mind, so that
> the effort could be estimated?
>
> Just looking at email messages with MIME attachments, it looks like
> each attachment is just a fancy header line and a body encoded by
> either base64 or quoted-printable.  Implementing a simple command that
> asks for a file name and then encodes it and puts the result in the
> *mail* buffer sounds easy enough, so I'm sure I'm missing something.

If you do decide to go the simple path, don't encode anything but text/* MIME
content as Q-P.  Various mailers, especially on Windows, take Q-P as an
instruction to un-Q-P the text, then convert line endings to the platform
format.

This violates the spec, but causes corruption of attachments.  Gnus, for a
while, selected the optimum of Q-P and base64 for size, and I found the above
issue when PDF files selected Q-P and ended up corrupted on Windows.

Regards,
        Daniel

[Miles Bader-2]

Eli Zaretskii <eliz@...> writes:
> Could you please post a list of the features you had in mind, so that
> the effort could be estimated?

Important things:

  1. Proper handling of non-ascii text. For instance:

      a. Proper encoding of non-ascii headers (using "=?" notation)
      b. Ability to use other transfer encodings besides 8-bit
      c. Ability to automatically choose different character encodings
         depending on the language/context/whatever (e.g., for many
         cases, the "standard" isn't utf-8).

  2. Ability to have both text and binary attachments (both are very
     important), and that these work together with the language support
     in part (1).

  3. The ability to handle the various quirks of sending netnews as
     opposed to email (they're similar in many ways, but obviously not
     all).

     [This presumes that we're looking at _replacing_ the current
     duplicated infrastructure with something new/better -- if the
     non-trivial effort is to be spent to make mail-mode really do email
     correctly, it would be dumb to retain message-mode just for
     handling netnews!]

Of course, message-mode already does all this properly.

My observation has been that there are lot of corner cases, and a lot of
software screws them up.

It would be very very useful to have some of the guys that actually work
on message-mode involved in this conversation, because they probably
know this stuff in much more detail -- I only know what I use as a user,
and have had problems with in the past.

-Miles


p.s. A probably unrelated problem, which made testing a bit annoying:
I can't actually send _any_ mail with mail-mode, because my ISP's
mail-forwarder rejects any messages generated with it!  I'm not quite
sure what extra headers or whatever message-mode adds, but I have no
problems with mail sent using message-mode...

--
Friendless, adj. Having no favors to bestow. Destitute of fortune. Addicted to
utterance of truth and common sense.

[Eli Zaretskii]

> From: Miles Bader <miles@...>
> Cc: Chad Brown <yandros@...>, Katsumi Yamaoka <yamaoka@...>,
>     emacs-devel@..., ding@...
> Date: Sun, 05 Jul 2009 11:39:59 +0900
>
> Eli Zaretskii <eliz@...> writes:
> > Could you please post a list of the features you had in mind, so that
> > the effort could be estimated?
>
> Important things:

Thanks.

>   1. Proper handling of non-ascii text. For instance:
>
>       a. Proper encoding of non-ascii headers (using "=?" notation)
>       b. Ability to use other transfer encodings besides 8-bit
>       c. Ability to automatically choose different character encodings
>          depending on the language/context/whatever (e.g., for many
>          cases, the "standard" isn't utf-8).

I think this is not really related to attaching files.

>   3. The ability to handle the various quirks of sending netnews as
>      opposed to email (they're similar in many ways, but obviously not
>      all).

And this is out of scope for mail-mode, which (AFAIK) does not support
news.

> p.s. A probably unrelated problem, which made testing a bit annoying:
> I can't actually send _any_ mail with mail-mode, because my ISP's
> mail-forwarder rejects any messages generated with it!  I'm not quite
> sure what extra headers or whatever message-mode adds, but I have no
> problems with mail sent using message-mode...

If you find out why that happens and post the info here, perhaps
someone could fix the problems causing it.  FWIW, I use mail-mode for
many years with many different ISPs with no problems at all.

[Miles Bader-2]

Eli Zaretskii <eliz@...> writes:
> I think this is not really related to attaching files.
...
> And this is out of scope for mail-mode, which (AFAIK) does not support
> news.

What exactly is the plan here?

Do we want to address the duplication between mail-mode and message-mode
or not?  Isn't this duplication a bad thing?  I think it is -- it
confuses users and adds maintenance burden.  Is adding layers and layers
of poorly integrated leaky bandaids to mail-mode really the path we want
to follow?  Are you just saying "let's add this one function now and
deal with the real problem later"?

-Miles

--
Hers, pron. His.

[Andreas Schwab-2]

Miles Bader <miles@...> writes:

> p.s. A probably unrelated problem, which made testing a bit annoying:
> I can't actually send _any_ mail with mail-mode, because my ISP's
> mail-forwarder rejects any messages generated with it!  I'm not quite
> sure what extra headers or whatever message-mode adds, but I have no
> problems with mail sent using message-mode...

Perhaps it's the wrong envelope sender.

Andreas.

--
Andreas Schwab, schwab@...
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[Miles Bader-2]

Andreas Schwab <schwab@...> writes:
>> p.s. A probably unrelated problem, which made testing a bit annoying:
>> I can't actually send _any_ mail with mail-mode, because my ISP's
>> mail-forwarder rejects any messages generated with it!  I'm not quite
>> sure what extra headers or whatever message-mode adds, but I have no
>> problems with mail sent using message-mode...
>
> Perhaps it's the wrong envelope sender.

I think that's it, but somehow, message-mode manages to set it correctly
(or perhaps not set it incorrectly), whereas mail-mode fails to do so.

I was kind of surprised because I thought both used the same backend
sending code in emacs....

-Miles

--
Circus, n. A place where horses, ponies and elephants are permitted to see
men, women and children acting the fool.

[Richard Stallman]

    MH-e, wherein I found that simple MIME is pretty easy but everything  
    turns crazy when you hit multipart/mixed and multipart/alternative.  

I don't know a lot about Mime.  What does multipart/alternative mean?
I see that in incoming messages that have plain text and HTML,
but handling those messages in Emacs should be basically trivial.
So what is the difficulty?

Likewise for multipart/mixed: I see that in a message I received,
but it looks like handling that message requires nothing special
or difficult.

      Adding a simple `attach file' to mail-mode is probably  
    not very hard at all, but the result won't allow you to drop message-
    mode/mml (it's been long enough that I forget which parts are where).

I do not propose to eliminate those programs.
The people who installed them should have proposed the change,
rather than sneaking it in as "part of Gnus".  But that was years ago,
and it would not make sense to remove it now.

[Chong Yidong]

Richard Stallman <rms@...> writes:

>     It's a question of necessary complexity.
>
> I don't think so.  Look at all the libraries message.el loads.
>
> I don't want to replace the simple sendmail.el with this tremendous
> pile of complexity.
>
> message.el is also 8000 lines long, where sendmail.el is under 2000
> lines.  I expect that sending attachments won't require more than 200
> lines.

As has been pointed out, message-mode has more features than mail-mode.
Even if we wanted to bring mail-mode up to par, that would turn it into
something just as complex, or more (since, as you noted, message-mode
already relies on other libraries to much of its functionality).

[Eli Zaretskii]

> From: Miles Bader <miles@...>
> Cc: yamaoka@...,  yandros@...,  ding@...,  emacs-devel@...
> Date: Sun, 05 Jul 2009 12:44:00 +0900
>
> Eli Zaretskii <eliz@...> writes:
> > I think this is not really related to attaching files.
> ...
> > And this is out of scope for mail-mode, which (AFAIK) does not support
> > news.
>
> What exactly is the plan here?

There is no plan (yet).  I was just trying to estimate the effort
needed for adding simple attachment facility to mail-mode.  Plans, if
there will be such, will come later.

> Do we want to address the duplication between mail-mode and message-mode
> or not?

I don't know about ``we'', but _I_ don't.  I simply don't have enough
time for such cleanups, and don't think I know enough about Gnus and
message-mode to be a good candidate for the job anyway.

> Isn't this duplication a bad thing?

Probably, but we have lived with that since when Gnus was merged with
Emacs.

> Is adding layers and layers of poorly integrated leaky bandaids to
> mail-mode really the path we want to follow?

I have no idea why you thought I was about to add ``leaky bandaids''.
I didn't even say I'm going to write any code, let alone ``leaky''.
And I don't think I ever added to Emacs such low-quality code that
would justify you making such assumptions, should I decide to write
some code.

[牛粥]

"Alfred M. Szmidt" <ams@...> writes:

>    The first step is to check for incompatibilities and missing
>    features in message-mode.  Currently, message-mode recognizes many
>    mail-mode variables, such as `sendmail-program', and do the right
>    thing in response.  Someone needs to go through all the sendmail.el
>    variables and make sure they are all handled properly in
>    message-mode.  Once that is done, we can start to migrate rmail,
>    the bug reporter, and any other places that use mail-mode to
>    message-mode.
>
> That is much  unneeded work, the only thing  that uses message-mode is
> gnus.  It would be much easier to add etach, or similar, to mail-mode,
> and make gnus use mail-mode which is the default mode for sending mail
> in Emacs.

As a user of Gnus, i think mail-mode need to more features. For
example, mail-mode does not support IMAP. Currently, most folks use
Google's Gmail which offers IMAP. Hence, i cannot agree to such an
Alfred's proposal. Again, Gnus will not go with mail-mode unless Gmail's
users respect for mail-mode.

Sincerely,
 
--
Byung-Hee HWANG, KNU
∑ WWW: http://izb.knu.ac.kr/~bh/

[Alfred M. Szmidt]

mail-mode is for sending mail, not for reading it.

[Miles Bader-2]

Eli Zaretskii <eliz@...> writes:
>> > And this is out of scope for mail-mode, which (AFAIK) does not support
>> > news.
>>
>> What exactly is the plan here?
>
> There is no plan (yet).  I was just trying to estimate the effort
> needed for adding simple attachment facility to mail-mode.  Plans, if
> there will be such, will come later.

So that would be the "let's add this one function now and
deal with the real problem later" answer, yes?

> I have no idea why you thought I was about to add ``leaky bandaids''.
> I didn't even say I'm going to write any code, let alone ``leaky''.
> And I don't think I ever added to Emacs such low-quality code that
> would justify you making such assumptions, should I decide to write
> some code.

I was not saying anything about your code (I wasn't even thinking you'd
write the code), and thus was making no assumptions about it.

The point was that real support for mime (as message-mode has today)
can't be done piecemeal, and that while adding "a little bit" of support
to mail-mode may be a _temporary_ fix for some people's perceived
problem, it isn't a good long-term solution -- and even in the
short-term it actually makes the duplication problem _worse_, so it
seems worth thinking about whether even that is actually desirable.

-Miles

--
Abstainer, n. A weak person who yields to the temptation of denying himself a
pleasure. A total abstainer is one who abstains from everything but
abstention, and especially from inactivity in the affairs of others.