Subject: [Imap-uw] mailutil patch: recognize -- switch

From: Elliot Kendall <[email-masked]>
Date: Wed, 5 Oct 2005 16:03:38 -0400

I have some pesky users who begin the names of their mailboxes with -.
This patch allows me to use mailutil with those mailboxes by giving
the standard UNIX -- switch to indicate that no more switches should
be parsed.

For example:

$ mailutil check -foo
unknown switch: -foo
$ mailutil check -- -foo
No new messages, 0 total in -foo

Please let me know if I should be submitting this elsewhere. I couldn't
find any mention of a development list or similar.

--
Elliot Kendall <[email-masked]>
Systems Administrator
Brandeis University
_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Elliot Kendall <[email-masked]>
Date: Wed, 5 Oct 2005 16:08:53 -0400

> the standard UNIX -- switch to indicate that no more switches should

THIS patch, rather.

--
Elliot Kendall <[email-masked]>
Systems Administrator
Brandeis University
diff -ur imap-2004g.orig/src/mailutil/mailutil.c imap-2004g/src/mailutil/mailutil.c
--- imap-2004g.orig/src/mailutil/mailutil.c	2005-07-20 16:52:51.000000000 -0400
+++ imap-2004g/src/mailutil/mailutil.c	2005-07-20 16:59:09.000000000 -0400
@@ -151,14 +151,16 @@
   int nargs,i;
   int merge = NIL;
   int ret = 1;
+  int moreswitchesp = T;
   char *cmd = NIL;
   char *src = NIL;
   char *dst = NIL;
   char *pgm = argc ? argv[0] : "mailutil";
 #include "linkage.c"
   for (nargs = argc ? argc - 1 : 0,args = argv + 1; nargs; args++,nargs--) {
-    if (*(s = *args) == '-') {	/* parse switches */
+    if (*(s = *args) == '-' && moreswitchesp) {	/* parse switches */
       if (!strcmp (s,"-debug") || !strcmp (s,"-d")) debugp = T;
+      else if (!strcmp (s,"--")) moreswitchesp = NIL;
       else if (!strcmp (s,"-verbose") || !strcmp (s,"-v")) verbosep = T;
       else if (!strcmp (s,"-rwcopy") || !strcmp (s,"-rw")) rwcopyp = T;
       else if ((nargs > 1) && (!strcmp (s,"-merge") || !strcmp (s,"-m"))) {
_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Mark Crispin <[email-masked]>
Date: Wed, 5 Oct 2005 14:13:08 -0700 (Pacific Daylight Time)

Hi Elliot -

Thank you very much for this suggested patch.

For my information, is the "--" any sort of convention, or was it ad-hoc 
on your part?  I find it difficult to believe that this is the first time 
that this has ever come up, and I'm hoping that you can point to other 
applications that do this as well.

For what it's worth, I generally use something like ~/-foo, although that 
can have problems if your site sets mailsubdir.  So I'm inclined to adopt 
your proposed patch.

Another possibility is to have a -source and -destination switch that 
takes a following argument (regardless of "-") so, e.g., you could say 
something like
 	mailutil check -source -foo
as opposed to your patch of
 	mailutil -- check -foo

I don't know which is clearer/more conventional.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Elliot Kendall <[email-masked]>
Date: Wed, 5 Oct 2005 17:20:14 -0400

> applications that do this as well.

I believe all GNU tools support the "--" switch. For instance:

$ file -- -foo
-foo: MBX mail folder

> can have problems if your site sets mailsubdir.  So I'm inclined to adopt 

I tend to have problems getting mailutil to use real path names, but
that's probably just laziness on my part.

> I don't know which is clearer/more conventional.

I would say my version, but probably I'm biased.

---

From: Mark Crispin <[email-masked]>
Date: Wed, 5 Oct 2005 14:30:16 -0700 (Pacific Daylight Time)

On Wed, 5 Oct 2005, Elliot Kendall wrote:
> I believe all GNU tools support the "--" switch.

That's good enough for me.  I'll adopt your patch.  Thanks again!

-- Mark --

---

From: Tim Mooney <[email-masked]>
Date: Wed, 5 Oct 2005 18:08:23 -0500 (CDT)

In regard to: Re: [Imap-uw] mailutil patch: recognize -- switch, Mark...:

> For my information, is the "--" any sort of convention,

It's actually specified by the XCU portion of the Single Unix
Specification (SUS).  I'm not sure when it was mandated, but it's
definitely part of SUSv3 (UNIX98).  Any command that takes command line
arguments and is SUS-compliant is required to take `--' to mean "end of
option arguments, hereafter are non-option arguments".

If you're willing to register with the Open Group, you can download the
entire SUS

 	http://www.unix.org/single_unix_specification/

> or was it ad-hoc on your part?  I find it difficult to believe that this
> is the first time that this has ever come up, and I'm hoping that you
> can point to other applications 
> that do this as well.

Every command that takes command line arguments on most modern UNIX
systems should do this, e.g.

$cd /tmp/foo
$touch -t foo bar
touch: bad conversion
$touch -- -t foo bar
$ls -t 
-t    bar   foo
$ls -- -t
-t
$rm -t
rm: illegal option -- t
usage: rm [-efirR] file ...
$rm -- -t

This is with the vendor commands on Tru64 5.1b, which is UNIX98 compliant.
The same would be true for recent Solaris and other commercial UNIX
platforms.

Tim
-- 
Tim Mooney                              [email-masked]
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Mark Crispin <[email-masked]>
Date: Wed, 5 Oct 2005 16:16:13 -0700 (Pacific Daylight Time)

> option arguments, hereafter are non-option arguments".

Thank you, and everybody else who has pointed this out.  I appreciate the 
information, and as a consequence have adopted the "--" choice.  It'll be 
in the next imap-2005 development snapshot.

Speaking of imap-2005; this is a sneak peak at the new code which supports 
UIDPLUS.  I do not consider this code to be "ready for prime time", but 
after a few months of testing it's ready for other people on an 
experimental basis.  There are some known issues in imap-2005; please read 
the BEWARE-READ-ME-FIRST file for more details.  The download is at:
 	ftp://ftp.cac.washington.edu/mail/imap-2005.DEV.tar.Z

-- Mark --

---

From: Shawn Walker <[email-masked]>
Date: Thu, 06 Oct 2005 10:11:48 -0500

We have a from address that has:

From: =?UTF-8?Q? Fr=C3=A9d=C3=A9ric ?= <[email-masked]>"

utf8_mime2text() can't decode that, if there is no spaces in the 
encoding such as

From: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric?= <[email-masked]>"

utf8_mime2text() decodes it just fine.

We are using 2004 of c-client.
_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Mark Crispin <[email-masked]>
Date: Thu, 6 Oct 2005 08:24:24 -0700 (PDT)

On Thu, 6 Oct 2005, Shawn Walker wrote:
> utf8_mime2text() can't decode that, if there is no spaces in the encoding 
> such as

That behavior is intentional and correct.  The first paragraph of RFC 2047 
section 2 states that "white space characters MUST NOT appear between 
components of an 'encoded-word'."

Later on in section 2, we find:
    IMPORTANT: 'encoded-word's are designed to be recognized as 'atom's
    by an RFC 822 parser.  As a consequence, unencoded white space
    characters (such as SPACE and HTAB) are FORBIDDEN within an
    'encoded-word'.  For example, the character sequence

       =?iso-8859-1?q?this is some text?=

    would be parsed as four 'atom's, rather than as a single 'atom' (by
    an RFC 822 parser) or 'encoded-word' (by a parser which understands
    'encoded-words').  The correct way to encode the string "this is some
    text" is to encode the SPACE characters as well, e.g.

       =?iso-8859-1?q?this=20is=20some=20text?=

RFC 2047 also permits the use of "_" instead of "=20", so that example can 
also be stated as:
       =?iso-8859-1?q?this_is_some_text?=

In conclusion, the problem is with the the entity that generated that From 
address, not with c-client.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Tim Mooney <[email-masked]>
Date: Thu, 6 Oct 2005 12:29:13 -0500 (CDT)

> address, not with c-client.

I'm not disagreeing, but what about being "... generous in what you
accept"?

There is a lot of software that generates QP incorrectly in some cases;
it would be really nice if c-client (and pine, by extension) would work
around the deficiences of that other software -- assuming it's not
terribly onerous to do so.

Tim

---

From: Mark Crispin <[email-masked]>
Date: Thu, 6 Oct 2005 11:12:55 -0700 (PDT)

> I'm not disagreeing, but what about being "... generous in what you

My position is:

This argument is based upon a terrible misunderstanding of Jon Postel's 
robustness principle: "be liberal in what you accept, be conservative in 
what you generate."

I knew Jon personally.  Although I can't speak for Jon, and sadly Jon is 
no longer with us, I am confident that he never intended it to be used in 
cases like this.

Jon's point was that ARPAnet (later Internet) protocols had many 
facilities, but only a subset of these facilities were commonly used. 
This had caused interoperability problems when one implementation depended 
upon a facility that another implementation did not implement.  TELNET, 
FTP, and the early email protocols suffered greatly from such problems.

Thus, "be conservative" by eschewing the facilities that aren't commonly 
used; but "be liberal" by implementing all the facilities described in the 
base specification even if they seem silly/useless/meaningless.

As an example of the Postel Principle, it was perfectly reasonable in RFCs 
733 and 822 to have a From header looking like:
 	From: Joe Mooch <(personal) joe (mooch) @ (company) example.com >
The c-client library (and hence Pine) is liberal and will interpret it
correctly as being equivalent to:
 	From: Joe Mooch <[email-masked]>
but many other MUAs will not!

Incidentally, RFC 2822 threw in the towel and outlawed sending the former. 
So, there is no longer a stated need for MUAs to "be liberal" and accept 
that form.  But some MUAs still do so out of respect for the past.

The abuse of the Postel Principle is its extension to "be liberal" by 
accepting out-of-specification protocol, even in those cases when the 
situation has always been explicitly prohibited by the specification.

This abuse encourages the practice of browbeating standards-compliant 
implementations to be non-compliant because some other implementation is 
non-compliant: "blurdybloop works with it, so your software is broken."

It also creates long-term interoperability problems; nobody really knows 
what the standard is.  A new implementor can not implement from the 
specification because much of the standard is in folklore that is not in 
any written specification.

It also causes harm.  Over the past 30 years, we've had numerous sad 
examples in which correct protocol was "repaired" into bogusity by 
well-intentioned software that incorrectly thought "it didn't really mean 
that, it meant this other thing, I'll fix it."  Email protocols in 
particular have suffered greatly because of this problem, which was 
largely brought on by the lack of rigor in the early specifications.

The IMAP protocol's strict syntax rules were a reaction to this problem. 
IMAP tries very hard to have just One Right Way That Everybody Must Obey. 
It occasionally has faltered in enforcement; and goodness knows people 
have complained about IMAP being so strict.  Nevertheless IMAP has had 
much better interoperability than had previously existed in email 
protocols.

> terribly onerous to do so.

In my opinion, it is onerous for the following reasons:
  1) (Multiple) slippery slope argument(s):
     a) standard undocumented in any specification
     b) repetitive fixing of bad effects of previous fixes
     c) "you did that, so you should do this too"... :-(
     d) etc.
  2) It introduces a bug: valid, standard-compliant data *will* be
     misinterpreted, and when that happens, the aggrieved party will
     rightfully say that it's c-client's fault.
  3) It's additional work; doing this means that the code can no longer use
     the rule, explicitly stated in RFC 2047, that an encoded-word is an
     RFC 2822 atom.

Your mileage may vary... :-)

-- Mark --

http://panda.com/mrc

---

From: Tim Mooney <[email-masked]>
Date: Thu, 6 Oct 2005 15:26:42 -0500 (CDT)

>> I'm not disagreeing, but what about being "... generous in what you

I don't necessarily disagree with any of this, and I appreciate someone
that sticks to their principles (especially when they're sound).  Perhaps
in this case principles will win out over interoperability, and the
principled software will help force better behavior on the broken
software.  That sometimes happens, and I hope it's so in this case.

Tim

---

From: Tim Mooney <[email-masked]>
Date: Thu, 6 Oct 2005 15:26:42 -0500 (CDT)

Tim