[Nmh-workers] [patch] snapshot of my MIME handling improvments
Hoi, I will be out of town for about ten days. Maybe I can read my emails at times. Before I go off, I like to share what I worked on the last two days. It's neither cleaned up nor much tested. Please see it as code in development. It may though be interesting for people who work on nmh currently, for not doing the same work twice. (I'm looking at you Peter. ;-) ) During the last week I thought a lot about how to do the MIME stuff right. My studies of send(1) and Peter's mail with this thoughts were the basis. From my current knowledge I believe that Jon Steinhart's attachment system (read docs/README-ATTACHMENTS) is the way to go for sending MIME messages. It can cover comp(1) and the MIME part of forw(1), and in fact any other sending of mail because is sits in send(1). Peter already pointed out that he believes that that's the right point for it. What I did: - I changed Jon's attachment system to get the attachment header name and format from the profile and not from command line arguments. This made the involved commands and functions less bulky because the values need not to be passed through all the time. It also makes this data avaliable to any program who ``likes to take part''. This alone I regard as an improvement. The new profile names are: `attachment-header' and `attachment-format'. (attach_fmt should likely be a char* too.) The -attach and -attachformat cmdline options of whatnow(1) and send(1) vanished. - The main change was done in uip/sendsbr.c:attach(). The message gets now MIMEified if it has attachment headers or (this is new) contains any non-ASCII character. Also handling of the body and forwarded messages is done directly. Until now if the body contained non-ASCII chars it would have gone as application/octet-stream if attachment headers had been present. This is fixed. (The content-typing of unknown attachments is still poor, but that's a different task.) - In uip/forw.c the action of the -mime switch was changed. Instead of inserting a mhbuild directive (#forw) it now inserts an attachment header that looks similar to the #forw directive. Therefore I replaced copy_mime_draft() with add_forw_hdr() which uses annotate(). The header will get converted to a #forw directive in sendsbr.c. This prevents /^#/ from being special, thanks to Jon's system. - I updated parts of the man pages but not very carefully and not well. Notes: The mime action of whatnow must not be used as it will collide with send's MIME facility. Thus automimeproc should not be set. I think whatnow's `mime' action should probably be removed then. If one does not use attachments (Jon's system) and mails include only ASCII chars then no MIME will be used and everything is like it had been. If either one is used then MIME will be used, which probably is what is wanted. (Peter pointed to the direction that nmh should behave just reasonable.) The space-tab-mixture of the indentation may be non-standard, by accident. You may test the patch if you like, but please see it as work in progress. I publish it now because it's good to release often, also now it's hot and I still know what I did ;-) . I very much like to clean every thing up when I'm back. meillo Diffstats: config/config.c |7 +++- h/mh.h |2 + h/prototypes.h |2 - man/send.man | 40 - man/whatnow.man |2 - sbr/readconfig.c |2 + uip/forw.c | 21 ++--- uip/mhparam.c|2 + uip/send.c | 31 +-- uip/sendsbr.c| 86 ++- uip/viamail.c|2 - uip/whatnowsbr.c | 79 +- 12 files changed, 101 insertions(+), 175 deletions(-) diff -r f306353298cc config/config.c --- a/config/config.c Wed Nov 10 13:18:11 2010 -0300 +++ b/config/config.c Fri Nov 12 20:02:06 2010 -0300 @@ -166,6 +166,12 @@ char *mh_seq = .mh_sequences; #endif +/* + * Default attachment header field name and attachment format. + */ +char *attach_hdr = X-MH-Attachment; +int attach_fmt = 0; + /* * nmh globals */ @@ -365,4 +371,3 @@ */ char *msgprot = DEFAULT_MESSAGE_MODE; - diff -r f306353298cc h/mh.h --- a/h/mh.h Wed Nov 10 13:18:11 2010 -0300 +++ b/h/mh.h Fri Nov 12 20:02:06 2010 -0300 @@ -299,6 +299,8 @@ * their values and reloading the various modules, nmh will run * on any system. */ +extern char *attach_hdr; +extern int attach_fmt; extern char *buildmimeproc; extern char *catproc; extern char *components; diff -r f306353298cc h/prototypes.h --- a/h/prototypes.h Wed Nov 10 13:18:11 2010 -0300 +++ b/h/prototypes.h Fri Nov 12 20:02:06 2010 -0300 @@ -162,7 +162,7 @@ int distout (char *, char *, char *); void replout (FILE *, char *, char *, struct msgs *, int, int, char *, char *, char *); -int sendsbr (char **, int, char *, struct stat *, int, char *, int); +int sendsbr (char **, int, char *, struct stat *, int); int what_now (char
Re: [Nmh-workers] extending nmh for smtps support?
On Fri, Nov 12, 2010 at 8:08 PM, heym...@bellsouth.net wrote: The question that still out there is whether or not nmh should support smtps. If so, I'm more than willing to go back into the code and work on it. Would this be of interest? What kind of schedule are we looking at for nmh 1.4 (so I can gauge my time/commitment)? I think it would be nice to have native support for SMTP over TLS, but there is some effort in doing it. I looked at seeing what it would take, but I think some reworking of some of the I/O code would be required to provide a decent enough abstraction so alternate I/O transports can be used. However, I did find a workable solution since I wanted to use Gmails servers for sending outgoing mail. See http://earlhood.blogspot.com/2010/01/how-to-posting-to-gmail-servers-with.html for more details. I figure what I did can be used for Yahoo's mail servers. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] MIME questions, and followup to my earlier email
I'm starting to look at writing new code to handle reading MIME messages as per the earlier discussion. My plan is to write a completely new version of scan for people to play with, and to replace the original only when consensus is reached on behavior. I haven't paid attention to mail standards in a long time. Is RFC 2231 a happening thing? Do we need to go through the trouble of supporting it? On my earlier email, I guess that I'm unhappy that meillo is making changes that break things, even if those are minor things. Comments on my proposed MIME-reading changes indicated that they should be optional for compatibility reasons. I took that approach when I implemented the MIME-sending changes. I think that we should only break existing code for clear and compelling technical reasons. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] MIME questions, and followup to my earlier email
On Fri, Nov 12, 2010 at 9:50 PM, Jon Steinhart wrote: I haven't paid attention to mail standards in a long time. Is RFC 2231 a happening thing? Do we need to go through the trouble of supporting it? I have support for 2184 (which 2231 updates) in my OSS Perl program, but mainly when dealing with attachment data where is seems to be of most practical use. I think several MUAs support it, but unsure about the ones used by most people (e.g. Outlook). I've seen the use of non-ASCII encoding defined in RFC 2047 inside of parameter values, which is not valid, but is likely that MUAs are supporting such abuse due to developers misunderstanding the MIME RFCs. I do not recommend nmh even try to deal with such data. IMO, if there is motivation to provide more robust MIME handling in nmh, I think it would be a mistake to not support 2231. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] extending nmh for smtps support?
On Fri, 12 Nov 2010 21:42:43 -0500, Ken Hornstein k...@pobox.com wrote: Recently I've changed my Internet connection from DSL to UVerse (both managed by ATT), but with UVerse I now have to deal with yahoo.com's mail service. They require the use of port 465 (smtps) and MAIL-AUTH. I think your termology doesn't quite match what I'm used to (and what the RFCs specify). If by MAIL-AUTH you mean SMTP AUTH, defined by RFC 4954, then nmh already has supported that for a decade. Yes, you are correct. If by smtps you mean SMTP with TLS, then no, we don't support that yet. People have talked about it, but no one has written the code. There are two general approaches: doing a TLS negotiation at connection start (which I guess is what happens on port 465, although that is not a standardized port; that port is reserved for a Cisco protocol called urd), and doing a STARTTLS command as part of the SMTP exchange. We should be doing the latter. I also left out that I was using 'stunnel' map the local port to the remote port on the yahoo.com server. I see that at http://www.iana.org/assignments/port-numbers, port 465 is called urd, but on my Mandriva 2009.1 Linux system I see: [je...@unix smtp]$ grep 465 /etc/services smtps 465/tcp # SMTP over SSL (TLS) I apologize for my ignorance, I actually thought that the info in my local /etc/services would be accurate, especially as ATT called it the same thing. I started working my way through the code, taking advantage of the sylpheed email GUI program I use for hints. It was slow going as I tried to keep the code in the same style. I got to the point where I was going to have to suck in a bunch of base64 encoding/decoding code when I stopped as this was no longer going to be a quick fix. I was not aware you needed a base64 encoder for TLS; are you sure you're not talking about the SASL support defined by RFC 4954? Because we do have base64 encoding/decoding as part of that (also as part of the MIME support, of course). After the EHLO response, used the base64 command to decode the prompts for userid and password. My reading of sylpheed code, and watching the generated log file showed that it was then creating a single string that contained AUTH PLAIN userid\0password where userid\0password were base64 encoded The question that still out there is whether or not nmh should support smtps. If so, I'm more than willing to go back into the code and work on it. Would this be of interest? What kind of schedule are we looking at for nmh 1.4 (so I can gauge my time/commitment)? There is definitely interest in TLS support, and I think it would be perfectly appropriate for nmh to support it. I don't think anyone has proposed a release schedule for 1.4; someone did suggest calling it 2.0. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers jerry -- // Jerry Heyman | Congress does not draw to its halls // Amiga Forever :-) | those who love liberty, it draws those \\ //heymanj at acm dot org | who love power. Judge Andrew Napolitano \X/ http://www.hobbeshollow.com ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
