headers
Hector Santos | 1 Apr 2005 01:26

Re: Extraneous CRs in transfer of draft-crocker-email-arch-04.txt


And just for final completness and the interested "Can't we all just get
along" Windows crowd..

/*  f.c -- fetch via HTTP and dump the entire session to stdout
    very stupidly.

    - ported to Windows to illustrate need to change the stdout device
      default _O_TEXT cooked mode setting to _O_BINARY raw mode.

*/

#ifdef _WIN32
#include <windows.h>
#include <stdio.h>
#include <string.h>
#include <winsock.h>
#include <fcntl.h>
#include <io.h>
#pragma comment(lib,"wsock32.lib")
#define close(a)      closesocket(a)
#define read(a,b,c)   recv(a,b,c,0)
#define write(a,b,c)  send(a,b,c,0)
#else
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruce Lilly | 1 Apr 2005 03:41
Picon

"addressing" comments on draft-crocker-email-arch-04.txt


The email architecture draft uses several terms (and neglects at least
one term) in ways that may cause or perpetuate confusion and lead to
loss of interoperability.  The specific terms used are addr-spec,
address, and mailbox.  Path and angle-addr are related terms used in the
core email RFCs, but are not mentioned in the draft.  The terms are
related, mostly by a hierarchy, and have specific uses in the message
format and mail architecture.

The differences are perhaps best illustrated by concrete examples as
well as descriptions and references:

addr-spec   blilly <at> erols.com

angle-addr  < <at> mx.mail.rcn.net:blilly <at> erols.com>

mailbox     Bruce Lilly < <at> mx.mail.rcn.net:blilly <at> erols.com>

address     Bruce Lilly: <blilly <at> erols.com>, bruce.lilly <at> gmail.com;

An addr-spec (RFCs 822, 2822) is the basic addressing specification
consisting of a local-part and domain, delimited by the special
character ' <at> '.  Every addr-spec is (syntactically) a mailbox and an
address.  No addr-spec is an angle-addr.  No angle-addrs are addr-specs.
Not all mailboxes are addr-specs.  Not all addresses are addr-specs.

An angle-addr (RFCs 822, 2822, called path in RFCs 821, 2821) is an
angle-bracketed construct which consists of an optional comma-separated
list of domains terminated by a colon (a route) followed by an addr-
spec.  N.B. although officially deprecated, a non-null route is still
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bruce Lilly | 1 Apr 2005 16:06
Picon

message-identifiers vs. "new message" in draft-crocker-email-arch-04.txt


The email architecture draft discusses"new" messages and message-ids in
several places.  Some of that discussion contradicts the core email RFCs
(822, 2822) and may cause confusion.

Here's what RFC 2822 has to say:

   The "Message-ID:" field provides a unique message identifier that
   refers to a particular version of a particular message.  The
   uniqueness of the message identifier is guaranteed by the host that
   generates it (see below).  This message identifier is intended to be
   machine readable and not necessarily meaningful to humans.  A message
   identifier pertains to exactly one instantiation of a particular
   message; subsequent revisions to the message each receive new message
   identifiers.

   Note: There are many instances when messages are "changed", but those
   changes do not constitute a new instantiation of that message, and
   therefore the message would not get a new message identifier.  For
   example, when messages are introduced into the transport system, they
   are often prepended with additional header fields such as trace
   fields (described in section 3.6.7) and resent fields (described in
   section 3.6.6).  The addition of such header fields does not change
   the identity of the message and therefore the original "Message-ID:"
   field is retained.  In all cases, it is the meaning that the sender
   of the message wishes to convey (i.e., whether this is the same
   message or a different message) that determines whether or not the
   "Message-ID:" field changes, not any particular syntactic difference
   that appears (or does not appear) in the message.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Bruce Lilly | 1 Apr 2005 16:33
Picon

Re: message-identifiers vs. "new message" in draft-crocker-email-arch-04.txt


P.S. draft section 5.2 also has a "new message" (for resending, which
retains the original Message-ID field and is therefore not in fact a
new message).
Permalink | Reply | 0 comments |
headers
Bruce Lilly | 1 Apr 2005 17:19
Picon

Re: pseudo LAST CALL - draft-crocker-email-arch-04.txt


On Thu March 31 2005 06:11, Arnt Gulbrandsen wrote:

> 2) isn't "bounces-to" a fairly good description of how most running code 
> treats the MAIL FROM address?

It's not only a description of how (RFC-compliant) running code
operates, it's specified in the relevant RFCs:

RFC 2821, section 3.3:

      MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>

   This command tells the SMTP-receiver that a new mail transaction is
   starting and to reset all its state tables and buffers, including any
   recipients or mail data.  The <reverse-path> portion of the first or
   only argument contains the source mailbox (between "<" and ">"
   brackets), which can be used to report errors (see section 4.2 for a
   discussion of error reporting).

N.B. "used to report errors"

RFC 821, section 3.3:

           MAIL <SP> FROM:<reverse-path> <CRLF>

         This command tells the SMTP-receiver that a new mail
         transaction is starting and to reset all its state tables and
         buffers, including any recipients or mail data.  It gives the
         reverse-path which can be used to report errors.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Dave Crocker | 1 Apr 2005 17:37

Re: pseudo LAST CALL - draft-crocker-email-arch-04.txt


>  N.B. "used to report errors"

Finding the best, single term to describe the rfc2821.mailfrom address has 
been a challenge.  In the latest round of the document, I latched onto 
'bounces' because that seems to be a term preferred by the community.  I have 
been more concerned about having the term move usage away from 'sender' or the 
like than i have about precise conformance to rfc2821 vocabulary.

since my concern has been problematic, established terminology, one other 
benefit of the term 'bounces' is that there is no ambiguity at all.  no one 
can think the references is to any other place that has an address.

given the rfc2821 language, it is tempting to change the document to use the 
term "errors".  the problem, then, is that it might be confused with 
"errors-to".

but, as I say about all the content of the email-arch document, the deciding 
factor is any indication of community preference.  

If folks have a preference, they need to voice it.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net
(Continue reading)

Permalink | Reply | 3 comments |
headers
Keith Moore | 1 Apr 2005 19:36
Picon

list traffic in iso-8859-6?


is there any particular reason why a couple of the messages that have 
been posted here recently (one by Dave, one by Bruce) have used charset 
iso-8859-6 (Arabic)?

reason I ask is, my Mac Mail client displays the digits in Arabic (e.g. 
"rfc٢٨٢١" rather than "rfc2821").  I'm not sure whether that's 
consistent with iso-8859-6 or not, but it does make the messages 
difficult for me to read.

Keith
Permalink | Reply | 3 comments |
headers
Carl S. Gutekunst | 1 Apr 2005 20:06

Re: pseudo LAST CALL - draft-crocker-email-arch-04.txt


>given the rfc2821 language, it is tempting to change the document to use the 
>term "errors".  the problem, then, is that it might be confused with 
>"errors-to".
>
>but, as I say about all the content of the email-arch document, the deciding 
>factor is any indication of community preference.
>
"Community preference" for a standards track document should be the 
community of people who read and implement standards, of course; and I'm 
reluctant to speak to that. I live in the world of operations staff and 
highly educated end users, even the best of whom are uncertain about 
which parts of the message are contained in the header and which in the 
envelope. For many years I've tried -- and failed -- to craft language 
that would allow these people to reliably verbalize "RFC2821 MAIL FROM" 
or "RFC 2822 From." Six months ago, we (at Habeas) started using the 
term "bounce address" and the result has been amazing. No one ever needs 
the term exaplained more than once; and from then on the dialog 
continues with no confusion or ambiguity. For the first time in 15 
years, ordinary people can say what they mean and have it understood.

If the architecture doc does not standardize on the term "bounce 
address," it should at least acknowledge that the term is very useful 
for its clarity in ordinary human conversation.

<csg>

//
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Moore | 2 Apr 2005 00:11
Picon

Re: pseudo LAST CALL - draft-crocker-email-arch-04.txt


> Finding the best, single term to describe the rfc2821.mailfrom address
> has  been a challenge.  In the latest round of the document, I latched
> onto  'bounces' because that seems to be a term preferred by the
> community. 

Formally, I'd say "notification address" or some such, because the
address is where various kinds of notifications (nondelivery, delivery, 
delay, receipt/read, and responses from robots) get sent by default.

Informally, I'd say "bounces".  It's not as precise but it has a higher
recognition factor.

It's like the difference between "receipt notification" and
"return receipt".  The latter term is meaningless, but everyone seems
to (think they) know what it means anyway.

Keith
Permalink | Reply | 1 comment |
headers
Dave Crocker | 2 Apr 2005 01:37

Re: list traffic in iso-8859-6?


>  is there any particular reason why a couple of the messages that have been
>  posted here recently (one by Dave, one by Bruce) have used charset iso-
>  8859-6 (Arabic)?

my mua (pocomail) is set to use us-ascii and i've enabled QP in headers.  

sometimes the mua screws up, but i haven't been able to determine when or why.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net
Permalink | Reply | 0 comments |

Gmane