headers
Bruce Lilly | 24 Apr 04:11
Picon

Re: 2822bis and ""@example.org


On 2007-03-28, Arnt Gulbrandsen wrote:
> 
> In 2822 that address is apparently valid. Should that be so?
> 
> I could understand it being a valid obs-this-or-that address. But it 
> seems to be quite simply valid. Message parsers must parse it, messages 
> senders may generate it.

""@[]

is also valid, as discussed here some time ago (beginning September 30, 2002).
I seem to recall that you participated in that discussion...
Permalink | Reply | 1 comment |
headers
Arnt Gulbrandsen | 24 Apr 10:42
Favicon

Re: 2822bis and ""@example.org


Bruce Lilly writes:
> ""@[]
>
> is also valid, as discussed here some time ago (beginning September 
> 30, 2002).
> I seem to recall that you participated in that discussion...

You're perfectly right, and upon rereading the thread, my opinion seems 
a sensible one. On the whole, though, I found this posting from you 
persuasive:
http://www.imc.org/ietf-822/mail-archive/msg02502.html
and I'm sorry I did not say so at the time.

Arnt
Permalink | Reply | 0 comments |
headers
Pete Resnick | 26 Apr 23:55
Favicon

draft-resnick-2822upd-01 posted


You may have noticed that 2822upd-01 was posted.

<http://www.ietf.org/internet-drafts/draft-resnick-2822upd-01.txt>
Also:
<http://www.qualcomm.com/~presnick/draft-resnick-2822upd-01.html>
<http://www.qualcomm.com/~presnick/draft-resnick-2822upd-01.xml>
<http://www.qualcomm.com/~presnick/draft-resnick-2822upd-01.txt>

Though overall very few, there are real changes from 2822 in this 
document that need review. See the changes section at the bottom. I 
did *not* go whole hog and switch to Bruce's syntax, simply because I 
wanted to limit the number of changes and see if we can't get this 
thing to Draft along with 2821bis. But I did incorporate (hopefully 
all of) the corrections that you all have pointed out over the last 
couple of years.

Please review with a fine toothed comb. If there are more than just a 
few problems, perhaps I'll ask Tony Hansen or Philip Guenther (who 
have at assorted time offered assistance) to start an issues list.

Thanks in advance for your assistance.

pr
--

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Permalink | Reply | 2 comments |
headers
Frank Ellermann | 27 Apr 00:33
Picon
Picon

Re: I-D ACTION:draft-resnick-2822upd-01.txt


Internet-Drafts <at> ietf.org wrote:

> http://www.ietf.org/internet-drafts/draft-resnick-2822upd-01.txt

Hi, where's that discussed, is here okay ?

For the <msg-id> I'd like to see a syntax also working in NetNews,
in news URIs, and in Archived-At links when they use a Message-ID.

A "canonical" version of a Message-ID is specified in
RFC.ietf-usefor-usefor-12

It has the following features:

- once created a Message-ID is "opaque", nobody's supposed to
  modify its id-right, even if that's a FQDN as it should be,
  where modifying say mixed case to lower case is tempting.
- Message-ID generators shouldn't use <quoted-pair>s unless they
  must.
- There is no NO-WS-CTL in a Message-ID.

Based on these concepts a "canonical" Message-ID is something like
this:

   msg-id          =  "<" msg-id-core ">"
                      ; maximum length is 250 octets

The maximum length is for NetNews and NNTP, and maybe this limit
is irrelevant for mail.  OTOH mail2news would be forced to reject
(Continue reading)

Permalink | Reply | 27 comments |
headers
Pete Resnick | 27 Apr 06:22
Favicon

Re: draft-resnick-2822upd-01 posted


On 4/26/07 at 4:55 PM -0500, I Resnick wrote:

>You may have noticed that 2822upd-01 was posted.
>
><http://www.ietf.org/internet-drafts/draft-resnick-2822upd-01.txt>
>Also:
><http://www.qualcomm.com/~presnick/draft-resnick-2822upd-01.html>
><http://www.qualcomm.com/~presnick/draft-resnick-2822upd-01.xml>
><http://www.qualcomm.com/~presnick/draft-resnick-2822upd-01.txt>

To make rfcdiff work, I've put a copy of RFC 2822 on my web site with 
some of the later sections rearranged so that they're in the same 
order as the current draft. You can see the diffs between the two 
here:

<http://tools.ietf.org/rfcdiff?url1=http://www.qualcomm.com/~presnick/rfc2822-fixed.txt&url2=http://www.ietf.org/internet-drafts/draft-resnick-2822upd-01.txt>

pr
--

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 27 Apr 21:05
Picon
Picon

Re: draft-resnick-2822upd-01 posted


In <p06300003c255dc5e3861@[216.43.25.67]> Pete Resnick <presnick <at> qualcomm.com> writes:

>You may have noticed that 2822upd-01 was posted.

>Though overall very few, there are real changes from 2822 in this 
>document that need review. See the changes section at the bottom. I 
>did *not* go whole hog and switch to Bruce's syntax, simply because I 
>wanted to limit the number of changes and see if we can't get this 
>thing to Draft along with 2821bis.

I think it is a great pity that you did not go that whole hog, since
Bruce's syntax was a great improvement on the present syntax, which can be
exceedingly hard to follow in many obscure situations.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 27 Apr 21:02
Picon
Picon

Compatibility wit Netnews (was I-D ACTION:draft-resnick-2822upd-01.txt)


In <463128C8.6B13 <at> xyzzy.claranet.de> Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:

>Internet-Drafts <at> ietf.org wrote:

>> http://www.ietf.org/internet-drafts/draft-resnick-2822upd-01.txt

>For the <msg-id> I'd like to see a syntax also working in NetNews,
>in news URIs, and in Archived-At links when they use a Message-ID.

>A "canonical" version of a Message-ID is specified in
>RFC.ietf-usefor-usefor-12

Indeed, the Message-ID is the principal feature of RFC 2822 which could
not be incorporated into Netnews as it stood. Draft-ietf-usefor-usefor-12,
which has now been approved by the IESG, but is likely to remain in the
RFC Editor's queue until other documents referenced by it are ready for
publication, made the minimum change to <msg-id> (essentially reducing it
to a canonicalized form) that would work. That is essentially what Frank
has described, but there are other alternative possibilities involving
further restrictions which might result in a cleaner syntax.

The essential feature required for Netnews was that, in order to compare
two <mesg-id>s for equality, a simple octet-by-octet comparison would
always suffice. Such comparisons are at the very heart of the Netnews
protocol, though they hardly arise at all in email except for the purpose
of threading articles in MUAs using the <msg-id>s that occur in References
header fields. Even there, I suspect, many threaders have simply
implemented an octet-by-octet comparison.
(Continue reading)

Permalink | Reply | 25 comments |
headers
Frank Ellermann | 30 Apr 00:50
Picon
Picon

Re: Compatibility wit Netnews


Charles Lindsey wrote:

 [canonical Message-ID]
> The essential feature required for Netnews was that, in order to
> compare two <mesg-id>s for equality, a simple octet-by-octet
> comparison would always suffice. Such comparisons are at the very
> heart of the Netnews protocol, though they hardly arise at all in
> email except for the purpose of threading articles in MUAs using
> the <msg-id>s that occur in References header fields. Even there,
> I suspect, many threaders have simply implemented an octet-by-octet
> comparison.

+1  And it's not only about "comparing" Message-IDs, it's also about
using something that's allowed in NNTP, i.e. no raw control char.s
(= NO-WS-CTL), and no ">" even within <no-fold-quote> (quoted LHS) or
<no-fold-literal> (domain literal as RHS).

Another application are Message-IDs in mailing list archives used as
Archived-AT URIs, or Message-IDs in NetNews used in news: URIs.  It's
possible to percent-encode any NO-WS-CTL, but it would be a pain.

Percent-encoding is always a kludge and harms interoperability as
soon as applications try to percent-encode something that is already
partially percent-encoded for local purposes, and then let another
application try to undo this.  The PURL resolver is an example how
that can get too easily out of hand.

 [magic SP]
> The other principle difference is that, in each header field, an
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ellermann | 30 Apr 01:25
Picon
Picon

[2822upd] Resent-* MUSTard


Hi, the following paragraphs in 2822upd-01 are incompatible with
RFC 4406:

   Resent fields are used to identify a message as having been
   reintroduced into the transport system by a user.  The purpose of
   using resent fields is to have the message appear to the final
   recipient as if it were sent directly by the original sender, with
   all of the original fields remaining the same.  Each set of resent
   fields correspond to a particular resending event.  That is, if a
   message is resent multiple times, each set of resent fields gives
   identifying information for each individual time.  Resent fields are
   strictly informational.  They MUST NOT be used in the normal
   processing of replies or other such automatic actions on messages.

      Note: Reintroducing a message into the transport system and using
      resent fields is a different operation from "forwarding".
      "Forwarding" has two meanings: One sense of forwarding is that a
      mail reading program can be told by a user to forward a copy of a
      message to another person, making the forwarded message the body
      of the new message.  A forwarded message in this sense does not
      appear to have come from the original sender, but is an entirely
      new message from the forwarder of the message.  On the other hand,
      forwarding is also used to mean when a mail transport program gets
      a message and forwards it on to a different destination for final
      delivery.  Resent header fields are not intended for use with
      either type of forwarding.

RFC 4406 uses Resent-* in "automatic actions on messages", both for
redistribution (mailing lists) and redirection (alias forwarding to 3rd
(Continue reading)

Permalink | Reply | 19 comments |
headers
ned+ietf-822 | 30 Apr 16:37

Re: [2822upd] Resent-* MUSTard


> Hi, the following paragraphs in 2822upd-01 are incompatible with
> RFC 4406:

> ...

> RFC 4406 uses Resent-* in "automatic actions on messages", both for
> redistribution (mailing lists) and redirection (alias forwarding to 3rd
> parties).  RFC 4407 uses Resent-* not only for "strictly informational"
> purposes, it evaluates Resent-* to determine the "PRA" (its "purported
> responsible address").  RFC 4405 uses this "PRA" in an SMTP extension.

> This incompatibility was approved in an appeal.

What was approved was the publication of *experimental* documents which state
that they are incompatible with exsiting standards in the area. (See the IESG
notes in RFC 4406 and 4408.) It is in no way incumbent on this effort to change
2822bis to be compatible with either of these experiments, especially since the
two experiments are incompatible with each other!

> For various technical
> reasons I think that the "PRA" is an excessively poor emulation of the
> Return-Path, and that it's stupid to introduce an entity like the "PRA"
> at this point in time shortly after RFC 3834 closed the last loophole
> where mailbots still sent auto-responses to other addresses:  Almost
> all auto-responses are now based on the Return-Path, NDRs, DSNs, MDNs,
> it makes no sense to introduce a new "PRA" sometimes resulting in the
> Sender-address which should never be used for auto-responses.

> BUT.  But while I hate the "PRA" it is not for the formal reason that
(Continue reading)

Permalink | Reply | 18 comments |

Gmane