Re: Sending attachments

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <address@hidden>
 > > Date: Fri, 10 Jul 2009 18:02:28 +0900
 > > Cc: Reiner Steib <address@hidden>, address@hidden
 > > 
 > > Thing is, that complexity is going to pop up at every turn as you
 > > develop these features.
 > 
 > True.  Which is why I thought the intent was to create something
 > exceedingly simple, e.g.:

That simplicity drove me nuts as a Mule maintainer, because it didn't
try to defend against users who went beyond the parameters sendmail.el
was ready to deal with.  Eg, I would tell somebody to send a bug
report using M-x report-xemacs-bug.  That uses sendmail.el because
Gnus and VM are both in the package distribution of XEmacs.  They'd
put non-ASCII in the header because it was a phrase they were having
problems getting Mule to handle correctly, Mule would encode it to
(raw, not RFC 2047) KOI8 or something, and it would take down the bug
list because (at that time) Mailman assumed ASCII in the headers of
mail coming off the wire, and threw an exception if it didn't get it.
(Now we just get mojibake, but we've fixed our bug reporter to say "if
possible we would really appreciate if you would kill this buffer,
customize `mail-composition-agent' and start your report over" because
really people do want to attach files, sometimes with non-ASCII names,
with their reports.)

OK, so now you fix mail-mode to deal with this.  You have two options:
error on non-ASCII in the headers, or RFC 2047 encode.  This is
non-trivial if you want to be RFC conformant, because you SHOULD use
quoted printable encoding for languages like French that use ASCII
supersets, and SHOULD use BASE64 for languages like Hebrew that don't.
(In practice this is usually done by looking at the fraction of ASCII
characters, rather than by determining the language.)  See RFC 2119
for the official definitions of requirement levels of capitalized
terms like SHOULD and MUST; IMHO a SHOULD is pretty strong.

Good, good, we're making progress (at the expense of a couple hundred
lines of code unless you grab rfc2047.el from Gnus -- which is what
Ken'ichi's 10-line .emacs hook does), whose usage assume several other
libraries in the usual Gnus-y way, and is 35KB or so by itself).

OK, so now we add an attachment feature.  No problem, right?  We
already handle RFC 2047, so our headers are OK, right?  Wrong.  RFC
2047 *specifically* forbids use of the encoding it defines to specify
file names in MIME headers.  This is a MUST NOT; a failure to conform
means you have a non-conformant MUA.  This is a boolean standard, your
MUA flunks, it's not "a little bit non-conformant".

OK. so now we have a choice.  You can error on an attempt to use a
non-ASCII filename, or you can implement RFC 2231.  More complexity,
rfc2231.el is 10KB.  Or you could munge the file name in some way and
instruct the recipient to change it back, or ask the sender to change
it.

Sure, you could stop short of a full implementation of all the RFCs
related to these "minimal features" you want, but where?  Figuring out
what to to include and what not to include, and introducing code to
check for and refuse unsupported requests from the user is
non-trivial, itself, and IMO should be based on an even better
knowledge of the RFCs than simply implementing the whole RFC.

You could say, oh, we don't have to do that.  And you're right ... but
IMO a non-RFC-conforming product really isn't something you want to
distribute as part of Emacs.

Is it really worth dealing with all this when as far as Miles and I
can tell, the sendmail.el UI (including hooks and keyboard macros) is
a 100% compatible subset of the Message mode UI?  Wouldn't it be a
better idea for one of the few serious Mail mode users to just try
Message mode for a few days, and fix any problems that show up?
Reading the RFCs is not easy.

Richard's point about complexity and modularity is a good one, of
course, but Message mode isn't that complex and is reasonably
well-factored.  The complexity comes in on the reader side of Gnus,
and I admit that's an impenetrable thicket of code.  But then, it's
much much easier to write something that just produces conformant
messages in RFC 822 format than it is to have a multibackend reader
that not only deals with netnews and a host of mail formats, but also
the hideous stuff that is produced by Microsoft and Yahoo! mailers,
not to mention spammers.