2005-05-30 [paul] 1.9.11cvs19
authorPaul Mangan <paul@claws-mail.org>
Mon, 30 May 2005 04:36:15 +0000 (04:36 +0000)
committerPaul Mangan <paul@claws-mail.org>
Mon, 30 May 2005 04:36:15 +0000 (04:36 +0000)
* doc/src/rfc2368.txt **NEW FILE**
* src/compose.c
compose_entries_set(): don't interpret Bcc
header field (conform to RFC 2368)
(sync with main)

ChangeLog-gtk2.claws
PATCHSETS
configure.ac
doc/src/rfc2368.txt [new file with mode: 0644]
src/compose.c

index f756216..bd711db 100644 (file)
@@ -1,3 +1,11 @@
+2005-05-30 [paul]      1.9.11cvs19
+
+       * doc/src/rfc2368.txt   **NEW FILE**
+       * src/compose.c
+               compose_entries_set(): don't interpret Bcc
+               header field (conform to RFC 2368)
+               (sync with main)
+
 2005-05-29 [colin]     1.9.11cvs18
 
        * src/prefs_common.c
index f6716be..e9a75f3 100644 (file)
--- a/PATCHSETS
+++ b/PATCHSETS
 ( cvs diff -u -r 1.115.2.33 -r 1.115.2.34 src/main.c; cvs diff -u -r 1.3.12.8 -r 1.3.12.9 src/message_search.c; cvs diff -u -r 1.17.2.10 -r 1.17.2.11 src/send_message.c; cvs diff -u -r 1.15.2.14 -r 1.15.2.15 src/summary_search.c; cvs diff -u -r 1.96.2.54 -r 1.96.2.55 src/textview.c; cvs diff -u -r 1.36.2.29 -r 1.36.2.30 src/common/utils.c; ) > 1.9.11cvs16.patchset
 ( cvs diff -u -r 1.395.2.70 -r 1.395.2.71 src/summaryview.c; ) > 1.9.11cvs17.patchset
 ( cvs diff -u -r 1.204.2.38 -r 1.204.2.39 src/prefs_common.c; ) > 1.9.11cvs18.patchset
+( cvs diff -u -r 0 -r 1 doc/src/rfc2368.txt; cvs diff -u -r 1.382.2.121 -r 1.382.2.122 src/compose.c; ) > 1.9.11cvs19.patchset
index a3d4797..48c7ea7 100644 (file)
@@ -11,7 +11,7 @@ MINOR_VERSION=9
 MICRO_VERSION=11
 INTERFACE_AGE=0
 BINARY_AGE=0
-EXTRA_VERSION=18
+EXTRA_VERSION=19
 EXTRA_RELEASE=
 EXTRA_GTK2_VERSION=
 
diff --git a/doc/src/rfc2368.txt b/doc/src/rfc2368.txt
new file mode 100644 (file)
index 0000000..f8b646a
--- /dev/null
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                       P. Hoffman
+Request for Comments: 2368                    Internet Mail Consortium
+Updates: 1738, 1808                                        L. Masinter
+Category: Standards Track                            Xerox Corporation
+                                                           J. Zawinski
+                                               Netscape Communications
+                                                             July 1998
+
+
+                         The mailto URL scheme
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   This document defines the format of Uniform Resource Locators (URL)
+   for designating electronic mail addresses. It is one of a suite of
+   documents which replace RFC 1738, 'Uniform Resource Locators', and
+   RFC 1808, 'Relative Uniform Resource Locators'. The syntax of
+   'mailto' URLs from RFC 1738 is extended to allow creation of more RFC
+   822 messages by allowing the URL to express additional header and
+   body fields.
+
+1. Introduction
+
+   The mailto URL scheme is used to designate the Internet mailing
+   address of an individual or service. In its simplest form, a mailto
+   URL contains an Internet mail address.
+
+   For greater functionality, because interaction with some resources
+   may require message headers or message bodies to be specified as well
+   as the mail address, the mailto URL scheme is extended to allow
+   setting mail header fields and the message body.
+
+2. Syntax of a mailto URL
+
+   Following the syntax conventions of RFC 1738 [RFC1738], a "mailto"
+   URL has the form:
+
+
+
+Hoffman, et. al.            Standards Track                     [Page 1]
+
+RFC 2368                 The mailto URL scheme                 July 1998
+
+
+     mailtoURL  =  "mailto:" [ to ] [ headers ]
+     to         =  #mailbox
+     headers    =  "?" header *( "&" header )
+     header     =  hname "=" hvalue
+     hname      =  *urlc
+     hvalue     =  *urlc
+
+   "#mailbox" is as specified in RFC 822 [RFC822]. This means that it
+   consists of zero or more comma-separated mail addresses, possibly
+   including "phrase" and "comment" components. Note that all URL
+   reserved characters in "to" must be encoded: in particular,
+   parentheses, commas, and the percent sign ("%"), which commonly occur
+   in the "mailbox" syntax.
+
+   "hname" and "hvalue" are encodings of an RFC 822 header name and
+   value, respectively. As with "to", all URL reserved characters must
+   be encoded.
+
+   The special hname "body" indicates that the associated hvalue is the
+   body of the message. The "body" hname should contain the content for
+   the first text/plain body part of the message. The mailto URL is
+   primarily intended for generation of short text messages that are
+   actually the content of automatic processing (such as "subscribe"
+   messages for mailing lists), not general MIME bodies.
+
+   Within mailto URLs, the characters "?", "=", "&" are reserved.
+
+   Because the "&" (ampersand) character is reserved in HTML, any mailto
+   URL which contains an ampersand must be spelled differently in HTML
+   than in other contexts.  A mailto URL which appears in an HTML
+   document must use "&amp;" instead of "&".
+
+   Also note that it is legal to specify both "to" and an "hname" whose
+   value is "to". That is,
+
+     mailto:addr1%2C%20addr2
+
+     is equivalent to
+
+     mailto:?to=addr1%2C%20addr2
+
+     is equivalent to
+
+     mailto:addr1?to=addr2
+
+   8-bit characters in mailto URLs are forbidden. MIME encoded words (as
+   defined in [RFC2047]) are permitted in header values, but not for any
+   part of a "body" hname.
+
+
+
+Hoffman, et. al.            Standards Track                     [Page 2]
+
+RFC 2368                 The mailto URL scheme                 July 1998
+
+
+3. Semantics and operations
+
+   A mailto URL designates an "internet resource", which is the mailbox
+   specified in the address. When additional headers are supplied, the
+   resource designated is the same address, but with an additional
+   profile for accessing the resource. While there are Internet
+   resources that can only be accessed via electronic mail, the mailto
+   URL is not intended as a way of retrieving such objects
+   automatically.
+
+   In current practice, resolving URLs such as those in the "http"
+   scheme causes an immediate interaction between client software and a
+   host running an interactive server. The "mailto" URL has unusual
+   semantics because resolving such a URL does not cause an immediate
+   interaction. Instead, the client creates a message to the designated
+   address with the various header fields set as default. The user can
+   edit the message, send this message unedited, or choose not to send
+   the message. The operation of how any URL scheme is resolved is not
+   mandated by the URL specifications.
+
+4. Unsafe headers
+
+   The user agent interpreting a mailto URL SHOULD choose not to create
+   a message if any of the headers are considered dangerous; it may also
+   choose to create a message with only a subset of the headers given in
+   the URL.  Only the Subject, Keywords, and Body headers are believed
+   to be both safe and useful.
+
+   The creator of a mailto URL cannot expect the resolver of a URL to
+   understand more than the "subject" and "body" headers. Clients that
+   resolve mailto URLs into mail messages should be able to correctly
+   create RFC 822-compliant mail messages using the "subject" and "body"
+   headers.
+
+5. Encoding
+
+   RFC 1738 requires that many characters in URLs be encoded. This
+   affects the mailto scheme for some common characters that might
+   appear in addresses, headers or message contents. One such character
+   is space (" ", ASCII hex 20). Note the examples above that use "%20"
+   for space in the message body.  Also note that line breaks in the
+   body of a message MUST be encoded with "%0D%0A".
+
+   People creating mailto URLs must be careful to encode any reserved
+   characters that are used in the URLs so that properly-written URL
+   interpreters can read them. Also, client software that reads URLs
+   must be careful to decode strings before creating the mail message so
+
+
+
+
+Hoffman, et. al.            Standards Track                     [Page 3]
+
+RFC 2368                 The mailto URL scheme                 July 1998
+
+
+   that the mail messages appear in a form that the recipient will
+   understand. These strings should be decoded before showing the user
+   the message.
+
+   The mailto URL scheme is limited in that it does not provide for
+   substitution of variables. Thus, a message body that must include a
+   user's email address can not be encoded using the mailto URL. This
+   limitation also prevents mailto URLs that are signed with public keys
+   and other such variable information.
+
+6. Examples
+
+   URLs for an ordinary individual mailing address:
+
+     <mailto:chris@example.com>
+
+   A URL for a mail response system that requires the name of the file
+   in the subject:
+
+     <mailto:infobot@example.com?subject=current-issue>
+
+   A mail response system that requires a "send" request in the body:
+
+     <mailto:infobot@example.com?body=send%20current-issue>
+
+   A similar URL could have two lines with different "send" requests (in
+   this case, "send current-issue" and, on the next line, "send index".)
+
+     <mailto:infobot@example.com?body=send%20current-
+     issue%0D%0Asend%20index>
+
+   An interesting use of your mailto URL is when browsing archives of
+   messages. Each browsed message might contain a mailto URL like:
+
+     <mailto:foobar@example.com?In-Reply-
+     To=%3c3469A91.D10AF4C@example.com>
+
+   A request to subscribe to a mailing list:
+
+     <mailto:majordomo@example.com?body=subscribe%20bamboo-l>
+
+   A URL for a single user which includes a CC of another user:
+
+     <mailto:joe@example.com?cc=bob@example.com&body=hello>
+
+   Another way of expressing the same thing:
+
+     <mailto:?to=joe@example.com&cc=bob@example.com&body=hello>
+
+
+
+Hoffman, et. al.            Standards Track                     [Page 4]
+
+RFC 2368                 The mailto URL scheme                 July 1998
+
+
+   Note the use of the "&" reserved character, above. The following
+   example, by using "?" twice, is incorrect:
+
+     <mailto:joe@example.com?cc=bob@example.com?body=hello>   ; WRONG!
+
+   According to RFC 822, the characters "?", "&", and even "%" may occur
+   in addr-specs. The fact that they are reserved characters in this URL
+   scheme is not a problem: those characters may appear in mailto URLs,
+   they just may not appear in unencoded form. The standard URL encoding
+   mechanisms ("%" followed by a two-digit hex number) must be used in
+   certain cases.
+
+   To indicate the address "gorby%kremvax@example.com" one would do:
+
+     <mailto:gorby%25kremvax@example.com>
+
+   To indicate the address "unlikely?address@example.com", and include
+   another header, one would do:
+
+     <mailto:unlikely%3Faddress@example.com?blat=foop>
+
+   As described above, the "&" (ampersand) character is reserved in HTML
+   and must be replacded with "&amp;". Thus, a complex URL that has
+   internal ampersands might look like:
+
+     Click
+     <a href="mailto:?to=joe@xyz.com&amp;cc=bob@xyz.com&amp;body=hello">
+     mailto:?to=joe@xyz.com&amp;cc=bob@xyz.com&amp;body=hello</a> to
+     send a greeting message to <i>Joe and Bob</i>.
+
+7. Security Considerations
+
+   The mailto scheme can be used to send a message from one user to
+   another, and thus can introduce many security concerns. Mail messages
+   can be logged at the originating site, the recipient site, and
+   intermediary sites along the delivery path. If the messages are not
+   encoded, they can also be read at any of those sites.
+
+   A mailto URL gives a template for a message that can be sent by mail
+   client software. The contents of that template may be opaque or
+   difficult to read by the user at the time of specifying the URL.
+   Thus, a mail client should never send a message based on a mailto URL
+   without first showing the user the full message that will be sent
+   (including all headers that were specified by the mailto URL), fully
+   decoded, and asking the user for approval to send the message as
+   electronic mail. The mail client should also make it clear that the
+   user is about to send an electronic mail message, since the user may
+   not be aware that this is the result of a mailto URL.
+
+
+
+Hoffman, et. al.            Standards Track                     [Page 5]
+
+RFC 2368                 The mailto URL scheme                 July 1998
+
+
+   A mail client should never send anything without complete disclosure
+   to the user of what is will be sent; it should disclose not only the
+   message destination, but also any headers. Unrecognized headers, or
+   headers with values inconsistent with those the mail client would
+   normally send should be especially suspect. MIME headers (MIME-
+   Version, Content-*) are most likely inappropriate, as are those
+   relating to routing (From, Bcc, Apparently-To, etc.)
+
+   Note that some headers are inherently unsafe to include in a message
+   generated from a URL. For example, headers such as "From:", "Bcc:",
+   and so on, should never be interpreted from a URL. In general, the
+   fewer headers interpreted from the URL, the less likely it is that a
+   sending agent will create an unsafe message.
+
+   Examples of problems with sending unapproved mail include:
+
+     * mail that breaks laws upon delivery, such as making illegal
+       threats;
+
+     * mail that identifies the sender as someone interested in breaking
+       laws;
+
+     * mail that identifies the sender to an unwanted third party;
+
+     * mail that causes a financial charge to be incurred on the sender;
+
+     * mail that causes an action on the recipient machine that causes
+       damage that might be attributed to the sender.
+
+   Programs that interpret mailto URLs should ensure that the SMTP
+   "From" address is set and correct.
+
+8. IANA Considerations
+
+   This document changes the definition of the mailto: URI scheme; any
+   registry of URI schemes should refer to this document rather than its
+   predecessor, RFC 1738.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman, et. al.            Standards Track                     [Page 6]
+
+RFC 2368                 The mailto URL scheme                 July 1998
+
+
+9. References
+
+   [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
+            Messages", STD 11, RFC 822, August 1982.
+
+   [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, Editors,
+             "Uniform Resource Locators (URL)", RFC 1738, December 1994.
+
+   [RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC
+             1808, June 1995.
+
+   [RFC2047] Moore, K., "MIME Part Three: Message Header Extensions for
+             Non-ASCII Text", RFC 2047, November 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman, et. al.            Standards Track                     [Page 7]
+
+RFC 2368                 The mailto URL scheme                 July 1998
+
+
+A. Change from RFC 1738
+
+   RFC 1738 defined only a simple 'mailto' with no headers, just an
+   addr-spec (not a full mailbox.)  However, required usage and
+   implementation has led to the development of an extended syntax that
+   included more header fields.
+
+B. Acknowledgments
+
+   This document was derived from RFC 1738 and RFC 1808 [RFC1808]; the
+   acknowledgments from those specifications still applies.
+
+   The following people contributed to this memo or had and discussed
+   similar ideas for mailto.
+
+   Harald Alvestrand
+   Bryan Costales
+   Steve Dorner
+   Al Gilman
+   Mark Joseph
+   Laurence Lundblade
+   Keith Moore
+   Jacob Palme
+   Michael Patton
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman, et. al.            Standards Track                     [Page 8]
+
+RFC 2368                 The mailto URL scheme                 July 1998
+
+
+C. Author Contact Information
+
+   Paul E. Hoffman
+   Internet Mail Consortium
+   127 Segre Place
+   Santa Cruz, CA  95060 USA
+
+   EMail: phoffman@imc.org
+
+
+   Larry Masinter
+   Xerox Corporation
+   3333 Coyote Hill Road
+   Palo Alto, CA 94304 USA
+
+   EMail: masinter@parc.xerox.com
+
+
+   Jamie Zawinski
+   Netscape Communications Corp.
+   501 East Middlefield Road
+   Mountain View, CA 94043 USA
+
+   EMail: jwz@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman, et. al.            Standards Track                     [Page 9]
+
+RFC 2368                 The mailto URL scheme                 July 1998
+
+
+D.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman, et. al.            Standards Track                    [Page 10]
+
index a493822..f896b2c 100644 (file)
@@ -1590,20 +1590,17 @@ static void compose_entries_set(Compose *compose, const gchar *mailto)
 {
        gchar *to = NULL;
        gchar *cc = NULL;
-       gchar *bcc = NULL;
        gchar *subject = NULL;
        gchar *body = NULL;
        gchar *temp = NULL;
        gint  len = 0;
 
-       scan_mailto_url(mailto, &to, &cc, &bcc, &subject, &body);
+       scan_mailto_url(mailto, &to, &cc, NULL, &subject, &body);
 
        if (to)
                compose_entry_append(compose, to, COMPOSE_TO);
        if (cc)
                compose_entry_append(compose, cc, COMPOSE_CC);
-       if (bcc)
-               compose_entry_append(compose, bcc, COMPOSE_BCC);
        if (subject)
                if (!g_utf8_validate (subject, -1, NULL)) {
                        temp = g_locale_to_utf8 (subject, -1, NULL, &len, NULL);
@@ -1640,7 +1637,6 @@ static void compose_entries_set(Compose *compose, const gchar *mailto)
 
        g_free(to);
        g_free(cc);
-       g_free(bcc);
        g_free(subject);
        g_free(body);
 }