Subject: 2821bis, 2822upd, email-arch
From: "Frank Ellermann" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 22 Nov 2007 09:21:11 +0100
List-Id: <ietf-822.imc.org>

Hi, the 2821bis and 2822upd drafts are "almost" ready, and clearly
better than the older RFCs.  Similarly the email-arch draft is 
"almost" ready.  A few open points are however critical, maybe
controversial, and getting them wrong would be dangerous.

Mail and SMTP is as important as HTTP, and the 2616bis folks got
a proper WG to sort our their nits.  Mail and SMTP deserve the
same care.

* 2822upd:  The NO-WS-CTL issues are critical, they do not only
  affect 2821bis, and checking all details is a difficult task.
* Email-arch:  Recent drafts such as MINGER and TBR need a term
  "border" or "boundary" MTA, and email-arch should explain what
  that is as common reference.
* "Bounce address":   IMO this is no *concept*, it is only an
  obvious *function* of the "envelope sender" concept formerly
  (STD 10) known as "reverse path".  It needs some fine tuning
  of 2821bis (mostly done) and email-arch to prsent this as
  unique idea, essential for SMTP, like a Message-ID is essential
  for NNTP.
* IPv6:  We should at least discuss Doug's proposal to get rid
  of the address fallback for IPv6.  Maybe the 2821 "bug" of not 
  mentioning AAAA can be turned into a 2821bis "feature".

 Frank

To: [email-masked]
Xref: clerew local.mime:5127
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Missing ABNF terms in 2821bis?
Date: Tue, 20 Nov 2007 13:55:49 GMT
Lines: 23
Sender: [email-masked]

In <[email-masked]> "Frank Ellermann" <[email-masked]> writes:

>Charles Lindsey wrote:

>>> Should we allow control characters in quoted-pair inside domain-literal?
> 
>> +1

>That should be "-1", shouldn't it ?

Maybe. My "+1" were intended to indicate "+1 for changing from what the
current draft says".

-- 
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: [email-masked]      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

Date: Mon, 19 Nov 2007 09:29:14 -0500
From: John C Klensin <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
cc: [email-masked], ietf-822 <[email-masked]>, [email-masked]
Subject: Re: Missing ABNF terms in 2821bis?
Sender: [email-masked]

--On Sunday, 18 November, 2007 22:48 -0600 Pete Resnick
<[email-masked]> wrote:

> 
> So, going back to my original questions:
> 
> On 11/18/07 at 5:36 PM -0800, [email-masked] wrote:
> 
>> [John Klensin wrote:]
>>> 
>>> --On Wednesday, 17 October, 2007 09:46 -0700 Pete Resnick 
>>> <[email-masked]> wrote:
>>> 
>>>> - Domain literals on the right hand side of addresses
>>> 
>>> This is the one that affects 2821bis. The control characters
>>> cannot  appear in either IPv4 address or IPv6 address domain
>>> literals. They  can, in principle, appear in General Address
>>> literal, but those  require standards track action, etc.,
>>> and one could easily cut them  off there. In other words,
>>> they are permitted in principle, but  prohibited in practice
>>> and are going to stay that way. It is  therefore probably
>>> safe to let this go.
>> 
>> Agreed. The issue is really with 2822. 2821's rules for
>> defining new  address literals offer sufficient protection
>> IMO.
> 
> So you and John are saying that we should pull NO-WS-CTL out
> of dtext?

I would be happy seeing it moved some sort of obsolete status,
e.g., moved to "accept only" and then attach to a statement that
it is enough of a source of trouble that one should be really
cautious about that.

> Should we allow control characters in quoted-pair inside
> domain-literal?

I think not.   Keep in mind that 2821bis (and 2821) prohibits
them in IPv4 and IPv6 address literals as well as in domain name
labels.  So the only possible case involves General (i.e.,
post-IPv6) literals.  No IESG in its collective right mind would
approve a syntax for those that included control characters so,
at least in the envelope or on the wire, this is a dead case.
 
> Should we allow quoted-pair at all in domain-literal?
> 
> (Remember that they all appear in the obsolete (i.e., must be
> able to handle for interpretation) syntax.)
> 
> The first is easy. The latter two are trickier, with the
> second one giving me severe heartburn.

Indeed.  I have trouble removing something that is even slightly
plausible from the list of what is already obsolete although I
could easily live with inserting a "MAY reject if this appears"
there.  To the extent to which they are tolerated in 821/2821, I
imagine it is a legacy of NVT, where some of these controls were
mistakenly (IMO) permitted as the only way (at the time) to
manage even minimal formatting.  I have no idea what they were
doing in 822 -- perhaps Dave remembers and can shed some light
on this.

>>>> - Quoted strings (which can be on the left hand size of
>>>> addresses  as well as lots of other structured header
>>>> fields)
>>> 
>>> The address part of this is a little more problematic than
>>> the case  above, but also easier, under the "you can screw
>>> only yourself by  putting one of those addresses up on your
>>> server" principle.
> 
> So John, you are saying that we should leave NO-WS-CTL in
> quoted-string?

I really do not know.  _Very_ mixed feelings.  I'd be happy to
see them go, but am a little concerned about unintended
consequences.  On the other hand, I would not lose any sleep
over keeping it because I don't mind helping stupid people enjoy
their stupidity.

>>>> - Comments (which can appear in lots of structured header
>>>> fields  including address fields)
>>>> - Unstructured text (in fields and in the body)
>>> 
>>> The rest of this is, indeed, a 2822 problem.
>> 
>> Yep, that's where it really needs to be dealt with.
> 
> And the answer to whether or not we should leave NO-WS-CTL in
> these is....?

I think you should at least have a really strong warning about
the difficulties invisible characters and characters whose
semantics may be interpreted different by the sender and
receiver can cause.  I don't have a strong opinion about how
much beyond that it is sensible to go. 

Sorry I'm unable to be more definitive this morning.

    john

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Missing ABNF terms in 2821bis?
Date:  Mon, 19 Nov 2007 14:32:41 +0100
Lines: 19
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Charles Lindsey wrote:

>> Should we allow control characters in quoted-pair inside domain-literal?
 
> +1

That should be "-1", shouldn't it ?

>> Should we allow quoted-pair at all in domain-literal?
[...]
> But for Netnews interoperability there are still a messy problem, so:
 
> +1

Ditto.  The only RHS quoted-pairs allowed in Netnews are
\[, \\, and \], and that's only for 2822-compatibility.

 Frank

To: [email-masked]
Xref: clerew local.mime:5122
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Missing ABNF terms in 2821bis?
Date: Mon, 19 Nov 2007 11:29:24 GMT
Lines: 69
Sender: [email-masked]

In <p06250107c366c2d6fde2@[74.134.5.163]> Pete Resnick <[email-masked]> writes:

>So, going back to my original questions:

>On 11/18/07 at 5:36 PM -0800, [email-masked] wrote:

>>[John Klensin wrote:]
>>>
>>>This is the one that affects 2821bis. The control characters cannot 
>>>appear in either IPv4 address or IPv6 address domain literals. They 
>>>can, in principle, appear in General Address literal, but those 
>>>require standards track action, etc., and one could easily cut them 
>>>off there. In other words, they are permitted in principle, but 
>>>prohibited in practice and are going to stay that way. It is 
>>>therefore probably safe to let this go.

It would clearly be stupid for a future IPvn to use them, and it should
be safe to assume that will not happen.

The other issue, to be taken into account however is interoperability with
Netnews (particularly insofar as these things also tuen up in <msg-id>s).
>>
>>Agreed. The issue is really with 2822. 2821's rules for defining new 
>>address literals offer sufficient protection IMO.

>So you and John are saying that we should pull NO-WS-CTL out of dtext?

+1

>Should we allow control characters in quoted-pair inside domain-literal?

+1

>Should we allow quoted-pair at all in domain-literal?

That one is slightly trickier, as there is less justification from a
2821/IPvn POV. But even there an IPvn that relied on them would be verging
on stupidity, and the constraint placed upon future IPvn designers by
forbidding them would be miniscule.

But for Netnews interoperability there are still a messy problem, so:

+1

>(Remember that they all appear in the obsolete (i.e., must be able to 
>handle for interpretation) syntax.)

Of course.

>The first is easy. The latter two are trickier, with the second one 
>giving me severe heartburn.

A little sodium bicarbonate, perhaps :-).

>So John, you are saying that we should leave NO-WS-CTL in quoted-string?

I am neutral there, but they wouldn't be missed.

-- 
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: [email-masked]      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

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Missing ABNF terms in 2821bis?
Date:  Mon, 19 Nov 2007 09:14:08 +0100
Lines: 43
Reply-To: "Frank Ellermann" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Pete Resnick wrote:

> Should we allow control characters in quoted-pair inside 
> domain-literal?

No.  
 
> Should we allow quoted-pair at all in domain-literal?

No, please get rid of it.  \[, \\, and \] are unnecessary
in domain-literals (and incompatible with STD 66).  

> Remember that they all appear in the obsolete (i.e., 
> must be able to handle for interpretation) syntax.

I don't understand why.  There never was a domain-literal
with control characters and / or quoted pairs in the wild,
what's the idea ?

It's not the same issue as for the local part (LHS).

> John, you are saying that we should leave NO-WS-CTL in 
> quoted-string?

That would be about quoted-pair and qtext, and it affects
the 2821 <Mailbox> (similar to the 2822 <addr-spec>).  If
an "implementation and interoperability report" would show
that it anyway doesn't work, can it be moved to obsolete ?

> And the answer to whether or not we should leave NO-WS-CTL
> in these is....?

ID.klensin-net-utf8 section 2 bullet 3:

| Other than CR, LF, Space (SP, U+0020), and Form Feed (FF,
| U+000C), control characters (U+0000 to U+001F and U+007F
| to U+009F) SHOULD generally be avoided. 

For e-mail better s/FF/HT/.  Of course you can't reference
this Internet-Draft, but its general idea "stay away from
unnecessary control characters" is fine.

 Frank

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Missing ABNF terms in 2821bis?
Date:  Mon, 19 Nov 2007 08:47:18 +0100
Lines: 10
Reply-To: "Frank Ellermann" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

John C Klensin wrote:

> it may be time to invent a new metalanguage rule for, e.g., 
> "pcontent" (for printable) which consists of characters in
> the ASCII range from 20 to 7E (hex).

I'd prefer VCHAR for 21 to 7E.  SP is already covered by WSP,
and VCHAR is defined in the ABNF STD.

 Frank

Date: Sun, 18 Nov 2007 22:48:19 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: Missing ABNF terms in 2821bis?
Cc: John C Klensin <[email-masked]>, [email-masked], ietf-822 <[email-masked]>, [email-masked]
Sender: [email-masked]

So, going back to my original questions:

On 11/18/07 at 5:36 PM -0800, [email-masked] wrote:

>[John Klensin wrote:]
>>
>>--On Wednesday, 17 October, 2007 09:46 -0700 Pete Resnick 
>><[email-masked]> wrote:
>>
>>>- Domain literals on the right hand side of addresses
>>
>>This is the one that affects 2821bis. The control characters cannot 
>>appear in either IPv4 address or IPv6 address domain literals. They 
>>can, in principle, appear in General Address literal, but those 
>>require standards track action, etc., and one could easily cut them 
>>off there. In other words, they are permitted in principle, but 
>>prohibited in practice and are going to stay that way. It is 
>>therefore probably safe to let this go.
>
>Agreed. The issue is really with 2822. 2821's rules for defining new 
>address literals offer sufficient protection IMO.

So you and John are saying that we should pull NO-WS-CTL out of dtext?

Should we allow control characters in quoted-pair inside domain-literal?

Should we allow quoted-pair at all in domain-literal?

(Remember that they all appear in the obsolete (i.e., must be able to 
handle for interpretation) syntax.)

The first is easy. The latter two are trickier, with the second one 
giving me severe heartburn.

>>>- Quoted strings (which can be on the left hand size of addresses 
>>>as well as lots of other structured header fields)
>>
>>The address part of this is a little more problematic than the case 
>>above, but also easier, under the "you can screw only yourself by 
>>putting one of those addresses up on your server" principle.

So John, you are saying that we should leave NO-WS-CTL in quoted-string?

>>>- Comments (which can appear in lots of structured header fields 
>>>including address fields)
>>>- Unstructured text (in fields and in the body)
>>
>>The rest of this is, indeed, a 2822 problem.
>
>Yep, that's where it really needs to be dealt with.

And the answer to whether or not we should leave NO-WS-CTL in these is....?

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: [email-masked]
Cc: Pete Resnick <[email-masked]>, [email-masked], ietf-822 <[email-masked]>, [email-masked]
Date: Sun, 18 Nov 2007 17:36:30 -0800 (PST)
Subject: Re: Missing ABNF terms in 2821bis?
To: John C Klensin <[email-masked]>
Sender: [email-masked]

> Dusting off this particular bit of ancient history...

> --On Wednesday, 17 October, 2007 09:46 -0700 Pete Resnick
> <[email-masked]> wrote:

> >
> > I've copied this conversation over to ietf-822, since I think
> > that will probably be where this issue is addressed.
> >
> > On 10/17/07 at 6:51 AM -0700, [email-masked] wrote:
> >
> >>> Peter J. Holzer wrote:
> >>>
> >>>> Which reminds me: What is the reason for allowing control
> >>>> characters in email addresses?
> >>>
> >>> Idiocy.
> >>
> >> I try hard to stay out of these sorts of debates, but in this
> >> case I  am forced to agree. We are way past the point where
> >> backwards  compatibility is an acceptable excuse for
> >> something like this. It  should be obvious why  allowing
> >> nonprinting control characters in  addresses is a bad idea on
> >> many levels.
> >>
> >> And if common sense isn't enough here, how about the fact
> >> that it is  pretty clear that these things have obvious and
> >> severe  interoperability problems that will make it hard to
> >> meet the  criterua for draft standard?
> >
> > Right now, control characters are allowed in the following:
> >
> > - Domain literals on the right hand side of addresses

> This is the one that affects 2821bis.  The control characters
> cannot appear in either IPv4 address or IPv6 address domain
> literals.   They can, in principle, appear in General Address
> literal, but those require standards track action, etc., and one
> could easily cut them off there.  In  other words, they are
> permitted in principle, but prohibited in practice and are going
> to stay that way.    It is therefore probably safe to let this
> go.

Agreed. The issue is really with 2822. 2821's rules for defining new address
literals offer sufficient protection IMO.

> I'm not going to do any for the version of 2821 that I intend to
> post later tonight, but, if there is consensus that it is time
> to do away with the puppies (and I am very much in agreement
> with Ned that they should go), it may be time to invent a new
> metalanguage rule for, e.g., "pcontent" (for printable) which
> consists of characters in the ASCII range from 20 to 7E (hex).

Seems like a reasonable thing to do to me. The interesting thing is that
this excludes tab, and I actually think that's the right thing to do.

> Looking ahead to i18n issues, it may be desirable to have a
> similar rule for Unicode characters, but the characters can't be
> enumerated (in practice and to preserve version-independence) so
> the rule would have to be defined in terms of character class
> and properties.

I haven't looked at this in much detail but I suspect it's going to be tricky
to get right. For example, the tab issue, if you'll pardon the pun, expands to
include the many other ways of representing whitespace provided by Unicode. Now
think of how this might interact with BIDI rules...

> > - Quoted strings (which can be on the left hand size of
> > addresses as well as lots of other structured header fields)

> The address part of this is a little more problematic than the
> case above, but also easier, under the "you can screw only
> yourself by putting one of those addresses up on your server"
> principle.

> The rest of this is, indeed, a 2822 problem.

Yep, that's where it really needs to be dealt with.

				Ned

Date: Sun, 18 Nov 2007 20:28:47 -0500
From: John C Klensin <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
cc: ietf-822 <[email-masked]>, [email-masked]
Subject: Re: Missing ABNF terms in 2821bis?
Sender: [email-masked]

Dusting off this particular bit of ancient history...

--On Wednesday, 17 October, 2007 09:46 -0700 Pete Resnick
<[email-masked]> wrote:

> 
> I've copied this conversation over to ietf-822, since I think
> that will probably be where this issue is addressed.
> 
> On 10/17/07 at 6:51 AM -0700, [email-masked] wrote:
> 
>>> Peter J. Holzer wrote:
>>> 
>>>> Which reminds me: What is the reason for allowing control 
>>>> characters in email addresses?
>>> 
>>> Idiocy.
>> 
>> I try hard to stay out of these sorts of debates, but in this
>> case I  am forced to agree. We are way past the point where
>> backwards  compatibility is an acceptable excuse for
>> something like this. It  should be obvious why  allowing
>> nonprinting control characters in  addresses is a bad idea on
>> many levels.
>> 
>> And if common sense isn't enough here, how about the fact
>> that it is  pretty clear that these things have obvious and
>> severe  interoperability problems that will make it hard to
>> meet the  criterua for draft standard?
> 
> Right now, control characters are allowed in the following:
> 
> - Domain literals on the right hand side of addresses

This is the one that affects 2821bis.  The control characters
cannot appear in either IPv4 address or IPv6 address domain
literals.   They can, in principle, appear in General Address
literal, but those require standards track action, etc., and one
could easily cut them off there.  In  other words, they are
permitted in principle, but prohibited in practice and are going
to stay that way.    It is therefore probably safe to let this
go.

I'm not going to do any for the version of 2821 that I intend to
post later tonight, but, if there is consensus that it is time
to do away with the puppies (and I am very much in agreement
with Ned that they should go), it may be time to invent a new
metalanguage rule for, e.g., "pcontent" (for printable) which
consists of characters in the ASCII range from 20 to 7E (hex).
Looking ahead to i18n issues, it may be desirable to have a
similar rule for Unicode characters, but the characters can't be
enumerated (in practice and to preserve version-independence) so
the rule would have to be defined in terms of character class
and properties.

> - Quoted strings (which can be on the left hand size of
> addresses as well as lots of other structured header fields)

The address part of this is a little more problematic than the
case above, but also easier, under the "you can screw only
yourself by putting one of those addresses up on your server"
principle.

The rest of this is, indeed, a 2822 problem.

> - Comments (which can appear in lots of structured header
> fields including address fields)
> - Unstructured text (in fields and in the body)

   john

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Authentication-Results: header draft
Date:  Mon, 12 Nov 2007 07:58:59 +0100
Lines: 93
Sender: [email-masked]

Murray S. Kucherawy wrote:

  [skipping the cleared nits, thanks] About 'iprev':
>> I like it, but better copy some "security considerations"
>> from RFC 4408 and the reverse mapping I-D.

> OK, I'll look into this stuff.

Okay, buy some asbestos.  Wayne added the PTR processing
limit of ten names to SPF because there can be lots of
names, e.g. an IP of a Web hoster.

>> IMO <version> for a header field is hopeless, besides
>> you can't have two different unrelated <version>
>> definitions in the ABNF.  Just kill the first (used in
>> <header>).

> I don't follow.  There can't be later versions of the
> Authentication-Results: header specification that might
> require some means of disambiguation?

Version numbers as in MIME-Version: 1.0 or in v=spf1 make
me nervous, nobody's going to upgrade their software just
because a future RFC hopes they'll do.  Assuming that A-R
gets traction it will be what you specify now.

Header field names (or FWIW "tags" introducing text in a
TXT or SPF record) are no limited resource, if somebody
really wants an Authentication-Results-Episode-2 header
field in a future RFC let them do it.

I'd be also worried if the <version> offers "them" to
http://en.wikipedia.org/wiki/Embrace%2C_extend_and_extinguish
Authentication-Results "version 1" by a bogus "version 2".

If you keep it anyway one of the two <version> needs a new
name.

>> The idea to allow [CFWS] before and after "." in the
>> <propspec> is outright horrible, please get rid of it.

> Why is it horrible?  Spaces and wrapping have no semantic
> importance

CFWS can be also a comment, it will confuse naive parsers
implementing what 99.99% of all <procspec> will do, simply
smtp.from or senderid.resent-sender without embedded CFWS.

You use <dot-atom-text> elsewhere, that has no CFWS before
or after its dots.  CFWS can contain stuff like NO-WS-CTL,
obs-FWS, quoted-pair, nested comments over several lines.

RFC 2822 says that folding SHOULD be limited to placing
the CRLF at higher-level syntactic breaks.  Explicitly
allowing it within <procspec> calls for unnecessary trouble.

Maybe it's only a matter of taste, I'd stay away from it.

>> value = [CFWS] ( token / addr-spec ) [CFWS]
[...]
> <addr-spec> is what I'm looking for there.  I can switch
> to that one.  I don't see any productions that I don't
> want in that case.

One potential problem, do you need an "empty value" for an
"empty reverse path" or similiar situations ?  You don't
have angle brackets for <> if you use <addr-spec> or the
equivalent 2821 <Mailbox>.

>> Example 3:  Should spf=pass smtp.mail=[email-masked]
>> actually be spf=pass smtp.from=[email-masked] ?
>> Ditto in example 4+5.

Not sure if you have that.

>> I think you'd better add an example for auth=pass where
>> that's added by the MSA.

> Why would the MSA add that for outbound mail?

MSAs typically do SMTP AUTH, see RFC 4409 and RFC 5068,
they could wish to note their authentication efforts in
a header field.  But I now guess that's not the scenario
you have in mind, you want the border MTA to strip any
old Authentication-Results in section 5 of the draft.

I'm not sure if that's a good idea, "trace header fields"
are meant to stay, aren't they ?

 Frank
-- 
Repost, Cc: to list didn't work for new address

Date: Fri, 09 Nov 2007 11:50:57 -0800
From: "Murray S. Kucherawy" <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: Authentication-Results: header draft
Sender: [email-masked]

Frank Ellermann wrote:
>
> In your table you limit spf2.0/mfrom to smtp.from.  I think you
> also need smtp.helo just as for v=spf1, because RFC 4406 states
> that spf2.mfrom is the "mfrom" defined in RFC 4408.
>   
Added.

> I think you could remove the "smpt.from" line from senderid, or
> add smtp.helo just in case, if implementations treat it like
> v=spf1.  
>   
Added smtp.helo.
> Another nit, what's the point of "smtp.helo" vs. "smtp.ehlo"
> in your table ?  I think it muddies the waters for MUAs trying
> to make sense of it.
>   
Removed smtp.ehlo, and modified the value to cover both the HELO and the 
EHLO case.

> Third nit, please update RFC 2554 (now 4954).  What you have
> as [IANA-HEADERS] RFC 2434 should be RFC 3864 and normative.
>   

Fixed.

> The proposed 'iprev' authentication is apparently the same as
> "v=spf1 ptr -all" minus the processing limits for PTR checks
> in RFC 4408.  One "IETF certified troll" will whine, you're
> in deep shit with this idea.  You should provide a reference
> to I-D.ietf-dnsop-reverse-mapping-considerations, and maybe
> acknowledge April Lorenzen's prior art "VarA".
>   
>   
>> Hoping to hand it off to our IETF AD soon
>>     
>
> IMO (s)he needs a fair warning about this 'iprev' beast.  I
> like it, but better copy some "security considerations" from
> RFC 4408 and the reverse mapping I-D.
>   

OK, I'll look into this stuff.
> In section 2.2 you forgot the terminating CRLF for <header>.
>   

Added.

> IMO <version> for a header field is hopeless, besides you
> can't have two different unrelated <version> definitions in
> the ABNF.  Just kill the first (used in <header>).  
>   
I don't follow.  There can't be later versions of the 
Authentication-Results: header specification that might require some 
means of disambiguation?

> The idea to allow [CFWS] before and after "." in the
> <propspec> is outright horrible, please get rid of it.
>   
Why is it horrible?  Spaces and wrapping have no semantic importance so 
you could crush the entire decommented header down by removing all 
whitespace of any kind and still be able to use the value of the header 
field.

> The <mailbox> is likely the <Mailbox> in RFC 2821, not the
> <mailbox> in RFC 2822, you'd get a parser problem with the
> latter.   Maybe you mean 2822 <addr-spec>, in both cases
> add the damned [CFWS] before and after the alternative:
>
>   value = [CFWS] ( token / addr-spec ) [CFWS]
>
> Better check which 2822 obs-cenities I've lost by going
> from <mailbox> to <addr-spec>, but I think you don't need
> <obs-angle-addr> with <obs-route>.  But maybe you need an
> empty path, I'm not sure where that is in RFC 2822.
>
>   
<addr-spec> is what I'm looking for there.  I can switch to that one.  I 
don't see any productions that I don't want in that case.
> Shouldn't the header field be a *trace* header field ?
> I don't see this at the moment in your I-D, please add it
> if it's missing.
>   

Section 4.1 already says it SHOULD be treated as a trace header field.

> Example 3:  Should spf=pass smtp.mail=[email-masked]
> actually be spf=pass smtp.from=[email-masked] ?  Ditto
> in example 4+5.  It's rather odd that the example 4 border
> MTA bothers to check spf and sender-id after an auth=pass,
> ditto in example 5.  I think you'd better add an example
> for auth=pass where that's added by the MSA.
>  
>   
Why would the MSA add that for outbound mail?

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Authentication-Results: header draft
Date:  Fri, 9 Nov 2007 17:52:30 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 27
Reply-To: "Frank Ellermann" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Murray S. Kucherawy wrote:

 <http://tools.ietf.org/html/draft-kucherawy-sender-auth-header>
> I just sent this off to ietf-822 and MAAWG's "techincal" list.

You should also send it to the "message headers" expert review
list when the I-D is in a state where its ABNF passes validation.

Ad 2, I'm no big Received-SPF fan, but it's certainly defined in
an RFC, registered (1), and implemented for some years now (2),
it even got a related erratum (3).

On the "message headers" review list (4) you could already ask
for a provisional registration of "Authentication-Results" until
the I-D is fleshed out (5) and approved resulting in a permanent
registration.

 Frank

1: http://www.iana.org/assignments/message-headers/perm-headers.html
2: http://mipassoc.org/pipermail/mail-vet-discuss/2007q4/000211.html
3: http://www.rfc-editor.org/errata_search.php?rfc=4408
   http://www.openspf.org/RFC_4408/Errata#received-spf-bad-examples
4: http://www.ietf.org/pipermail/ietf-message-headers
   http://dir.gmane.org/gmane.ietf.message-headers
5: http://article.gmane.org/gmane.ietf.rfc822/11975

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Authentication-Results: header draft
Date:  Fri, 9 Nov 2007 03:48:08 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 78
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Murray S. Kucherawy wrote:

> I just sent this off to ietf-822 and MAAWG's "techincal" list.

In your table you limit spf2.0/mfrom to smtp.from.  I think you
also need smtp.helo just as for v=spf1, because RFC 4406 states
that spf2.mfrom is the "mfrom" defined in RFC 4408.

RFC 4408 uses the term "MAIL FROM identity", but it's obviously
the same concept.  For an empty reverse path RFC 4408 constructs
an ersatz-"mfrom" postmaster@<sender> using the "HELO identity"
as <sender>.  Most relevant v=spf1 drafts had "MAY check HELO",
later changed to "SHOULD check HELO", because it's obviously a
good idea to do it anyway when it was always allowed.

I think this means that spf2.0/mfrom and v=spf1 have the same
semantics wrt smtp.helo, receivers SHOULD check HELO / EHLO as
obvious shortcut because they'd check it anyway for an empty
reverse path.  In practice it would be a bad idea to publish
spf2.0/mfrom instead of v=spf1, so it might be irrelevant.

I think you could remove the "smpt.from" line from senderid, or
add smtp.helo just in case, if implementations treat it like
v=spf1.  

Another nit, what's the point of "smtp.helo" vs. "smtp.ehlo"
in your table ?  I think it muddies the waters for MUAs trying
to make sense of it.

Third nit, please update RFC 2554 (now 4954).  What you have
as [IANA-HEADERS] RFC 2434 should be RFC 3864 and normative.

The proposed 'iprev' authentication is apparently the same as
"v=spf1 ptr -all" minus the processing limits for PTR checks
in RFC 4408.  One "IETF certified troll" will whine, you're
in deep shit with this idea.  You should provide a reference
to I-D.ietf-dnsop-reverse-mapping-considerations, and maybe
acknowledge April Lorenzen's prior art "VarA".
  
> Hoping to hand it off to our IETF AD soon

IMO (s)he needs a fair warning about this 'iprev' beast.  I
like it, but better copy some "security considerations" from
RFC 4408 and the reverse mapping I-D.

In section 2.2 you forgot the terminating CRLF for <header>.

IMO <version> for a header field is hopeless, besides you
can't have two different unrelated <version> definitions in
the ABNF.  Just kill the first (used in <header>).  

The idea to allow [CFWS] before and after "." in the
<propspec> is outright horrible, please get rid of it.

The <mailbox> is likely the <Mailbox> in RFC 2821, not the
<mailbox> in RFC 2822, you'd get a parser problem with the
latter.   Maybe you mean 2822 <addr-spec>, in both cases
add the damned [CFWS] before and after the alternative:

  value = [CFWS] ( token / addr-spec ) [CFWS]

Better check which 2822 obs-cenities I've lost by going
from <mailbox> to <addr-spec>, but I think you don't need
<obs-angle-addr> with <obs-route>.  But maybe you need an
empty path, I'm not sure where that is in RFC 2822.

Shouldn't the header field be a *trace* header field ?
I don't see this at the moment in your I-D, please add it
if it's missing.

Example 3:  Should spf=pass smtp.mail=[email-masked]
actually be spf=pass smtp.from=[email-masked] ?  Ditto
in example 4+5.  It's rather odd that the example 4 border
MTA bothers to check spf and sender-id after an auth=pass,
ditto in example 5.  I think you'd better add an example
for auth=pass where that's added by the MSA.
 
 Frank

Date: Thu, 8 Nov 2007 14:32:30 -0800 (PST)
From: "Murray S. Kucherawy" <[email-masked]>
To: [email-masked]
Subject: Authentication-Results: header draft
Sender: [email-masked]

I have a draft for a new RFC2822-style header to be used to convey e-mail 
authentication results between MTAs and user agents.  The draft has been 
undergoing evolution and review for some time now and I'd like to open it 
up to a wider audience now in hopes of handing it off to the IETF area 
director soon to begin the RFC process.  The latest version is available 
here:

https://datatracker.ietf.org/drafts/draft-kucherawy-sender-auth-header/

Discussion about it takes place on a mailing list referenced toward the 
bottom of that draft.  Feel free to send feedback to me directly or 
(preferably) by joining the list and discussing it there.

--
Murray S. Kucherawy ===================== [email-masked]
Principal Engineer           Sendmail, Inc.                Emeryville, CA, USA
(510) 594-5400                                         http://www.sendmail.com

Date: Mon, 05 Nov 2007 14:48:09 -0800
To: Qian Sun <[email-masked]>, [email-masked]
From: SM <[email-masked]>
Subject: Re: New Disposition type: Inline Subordinate
Sender: [email-masked]

Hi Qian,
At 23:09 04-11-2007, Qian Sun wrote:
>RFC 2183 defines two basic disposition types, i.e. "inline" and "attachment".
>But sometimes we need a more elaborate presentation than the 
>existing disposition
>types. For example, the current advertisement way in Email or Webpage is very
>"evil", sometimes it is difficult for the users to distinguish the 
>real contents
>from advertisement, and this is disgusting or confusing. Nowadays many email
>service providers insert advertisements in the user's email. The inserted
>advertisements normally are displayed at the end of the email, but 
>sometimes the
>boundary between advertisements and other real contents is not clear. So that
>the recipient may be misunderstanding, the advertisements might be 
>regarded as
>the real contents the sender writes.

If the sender does not want his/her message to be misunderstood 
because of advertisements, he/she could use a service which doesn't 
insert such content.

>However, advertisement is absolutely necessary for the development 
>of internet
>and mobile applications. In order not to interfere with users much, 
>the technology

I doubt that advertisement is absolutely necessary for the 
development of the Internet.

>for sending advertisement kindly is needed. Email, MMS, IM and SIP 
>messages may
>use MIME as their content body, the advertisement could also be inserted into
>the message body as a MIME content. Maybe a new disposition type can 
>be defined
>to help users distinguish the advertisement and the real contents. 
>Its definition
>is like this:

If a new disposition type was defined, it might be used by some 
parties to remove that part of the content.

>A bodypart should be marked "inline-subordinate" if it is intended 
>to be displayed automatically upon display of the message, but it 
>should not block other displayed bodyparts, e.g., bodyparts with a 
>regular "inline" disposition type. It is RECOMMENDED that the client 
>render the content marked by inline-subordinate in a separate place 
>away from other inline contents.

Advertisers tends to look for more visibility.  If it's away from 
other inline content, the advertisers won't see their message as 
being visible to their audience.  There's also the question of 
compatibility with legacy MUAs.  Defining a new disposition type 
won't solve the problem.

Regards,
-sm

Date: Mon, 5 Nov 2007 05:20:03 -0600
To: "Mikel Lindsaar" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Non destructive folding/unfolding (ie, no insertion of whitespace in unfolding)
Cc: [email-masked]
Sender: [email-masked]

On 11/1/07 at 12:35 PM +1100, Mikel Lindsaar wrote:

>One situation I have is where a X-header field and Reply-To field 
>has a single piece of text that is longer than the 78 octet limit, 
>but has no white space break.
>
>For example:
>
>Reply-To: 
><[email-masked]>
>
>The library currently folds this line as:
>
>Reply-To:CRLF
>LWSP<1234-1234-1234-1234...blah-with-no-further-fold

That's OK.

>Now, I have two questions.
>
>1) I believe that putting the CRLF immediately after the : in the 
>header field name is in violation of 2822 specifically that the 
>header line should contain the name, a colon, the field and 
>terminated by a CRLF.  Would this be a correct interpretation?

No. Following every colon after the header field is "[CFWS]". It's OK 
to fold there.

>2) Irregardless of (1), what is the correct handling of a piece of 
>text in the field that is longer than 78 characters, but contains no 
>whitespace to fold?  ie, in unfolding, no whitespace can be inserted 
>back into the original text which would be destructive to the 
>original text.

In the X-header field case, if you've got longer than 78 in the field 
body, just leave it. If it's longer than 998, then you're going to 
have to break it.

In the Reply-To field case, you've got other options. You can put in 
the fold before or after the "<", the ">",  the "@", and any "," 
between addresses if there's more than one. That's destructive of the 
original sent form, but it won't be a problem semantically for 
anything parsing. This isn't a general rule, though. It only applies 
to fields that specifically take addresses. There are other similar 
situations.

>I saw one mention of doing this:
>
>Reply-To: <1234-1234-1234-1234-1234-12\CRLF
>LWSP34-1234-1234-1234
>
>But I can not find this in the RFC 2822 and my library breaks on 
>this when it tries to unfold, so I am not sure if my library's 
>unfolding function is at fault or if my folding implementation is 
>incorrect.

That's broken. It won't unfold correctly.
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Mon, 05 Nov 2007 16:40:30 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], Qian Sun <[email-masked]>, [email-masked]
Subject: Re: New Disposition type: Inline Subordinate
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> 
> [email-masked] writes:
>> OK, [...]
> 
> Thanks. I wanted to say all that, but was too tired to write clearly.
> 
> There is one more thing. The hucksters who are gluing advertising onto 
> other people's outgoing mail may reasonably be assumed to do it in HTML 
> too (if not now then soon), by inserting a new <div>...</div> in 
> existing messages and adding some CSS. It is unreasonable to assume that 
> they'll prefer to use separate and labelled bodyparts.
> 
> Arnt

What I find fascinating is that this gentleman's belief or sense it a 
industry right to advertise on the back of others and mailers should 
pass thru unprohibited foregoing any receiver and/or user safety measures.

Right. With todays email clients, its not really a requirement to have 
MIME based text/html context tags.  The body is detected and rendered 
accordingly.  Yahoo and others wrap their outgoing user mail with <div> 
advertisment windows.  I recall back in the late eighties how this 
created a STRIPPING WAR among mailers.  One added, One Stripped! The 
irony is is that the stripper only worked when you paid the vendor :-)

Fortunately, the email clients are getting better with such things, such 
as blocking image webbots by default. TBIRD controls this very nicely, 
as well as controlling phishing HTML links that have display domain and 
link references mismatches, example:

   <a href="http://1.2.3.4">http://some_highvalue_domain.com</a>

But the clear dangers today is WEB 2.0 or basically Javascript. With the 
advent of AJAX and JSONP, this is fast becoming the rule, rather than 
the exception.   We preach unobstrusive designs (fall back to web 1.0) 
but far too many are forcing web 2.0 only designs.  DNSREPORTS.COM is a 
prime example of this unfortunate evolution.  It won't no longer work 
unless you have JavaScript enabled and its NOT using JAVASCRIPT for the 
great DNS reports it offers.  No fallback. It using JSONP/AJAX to 
seemlessly track activity.

We just went completed a new project and release implementing Web 2.0 
features to our web mail system but not before we found many dangers 
with how many of the message content now viewed today.  The problem? 
The ajax libraries out there do no filter by default.

Anyway, -1 on this suggestion. :-)

-- 
HLS

Date: Mon, 5 Nov 2007 21:22:25 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: New Disposition type: Inline Subordinate
Cc: Qian Sun <[email-masked]>, [email-masked]
Sender: [email-masked]

[email-masked] writes:
> OK, [...]

Thanks. I wanted to say all that, but was too tired to write clearly.

There is one more thing. The hucksters who are gluing advertising onto 
other people's outgoing mail may reasonably be assumed to do it in HTML 
too (if not now then soon), by inserting a new <div>...</div> in 
existing messages and adding some CSS. It is unreasonable to assume 
that they'll prefer to use separate and labelled bodyparts.

Arnt

From: [email-masked]
Cc: [email-masked]
Date: Mon, 05 Nov 2007 11:26:29 -0800 (PST)
Subject: Re: New Disposition type: Inline Subordinate
To: Qian Sun <[email-masked]>
Sender: [email-masked]

> Hello 'email people'

> RFC 2183 defines two basic disposition types, i.e. "inline" and "attachment".
> But sometimes we need a more elaborate presentation than the existing disposition
> types. For example, the current advertisement way in Email or Webpage is very
> "evil", sometimes it is difficult for the users to distinguish the real contents
> from advertisement, and this is disgusting or confusing. Nowadays many email
> service providers insert advertisements in the user's email. The inserted
> advertisements normally are displayed at the end of the email, but sometimes the
> boundary between advertisements and other real contents is not clear. So that
> the recipient may be misunderstanding, the advertisements might be regarded as
> the real contents the sender writes.

> However, advertisement is absolutely necessary for the development of internet
> and mobile applications. In order not to interfere with users much, the technology
> for sending advertisement kindly is needed. Email, MMS, IM and SIP messages may
> use MIME as their content body, the advertisement could also be inserted into
> the message body as a MIME content. Maybe a new disposition type can be defined
> to help users distinguish the advertisement and the real contents. Its definition
> is like this:

> A bodypart should be marked "inline-subordinate" if it is intended to be
> displayed automatically upon display of the message, but it should not block
> other displayed bodyparts, e.g., bodyparts with a regular "inline" disposition
> type. It is RECOMMENDED that the client render the content marked by
> inline-subordinate in a separate place away from other inline contents.

> Opinion?

OK, let's start with this notion that "advertising is absolutely necessary for
the development of internet and mobile applications". I have big problems with
this assertion, but even if I accept it as a given, it doesn't necessarily
follow that the right way to do ads is to insert them into the messages people
send as separate MIME objects. The obvious alternative is for ads to be
displayed locally by the client. Of course this doesn't provide a advertiser
with a way of getting their crap^H^H^H^Huseful and informative material in
front of the eyes of remote recipients who are pahing for their email some
other way and have no association with the service inserting the ads, but I'm a
long way from convinced that's a model we should encourage in any way, shape,
or form.

That said, having a way to tag some material in a message as requiring some
degree of separation from other material when displayed makes a certain amount
of sense. However, this specific case really isn't subordinate to the other
material in the mesage. Rather, it's a separate, secondary object. A name like
"inline-secondary" would be better IMO.

Naming aside, I'm also not convinced that defining a new disposition type for
this is the right approach. For one thing, new types won't be properly handled
by existing software and it is unlikely that handling for unknown types will
default to inline in all cases. Perhaps it would be better to make  this a
parameter. Existing implementations should simply ignore unknown parameters. So
I guess if this is going to be done I'd like to see it as a new parameter of
some sort. 

Indeed, were it not for the installed base issue it seems pretty clear to me
that this really should be handled by defining a new multipart subtype.

				Ned

Date: Mon, 05 Nov 2007 15:09:39 +0800
From: Qian Sun <[email-masked]>
Subject: New Disposition type: Inline Subordinate
To: [email-masked]
Sender: [email-masked]

Hello 'email people'

RFC 2183 defines two basic disposition types, i.e. "inline" and "attachment".
But sometimes we need a more elaborate presentation than the existing disposition 
types. For example, the current advertisement way in Email or Webpage is very 
"evil", sometimes it is difficult for the users to distinguish the real contents 
from advertisement, and this is disgusting or confusing. Nowadays many email 
service providers insert advertisements in the user's email. The inserted 
advertisements normally are displayed at the end of the email, but sometimes the 
boundary between advertisements and other real contents is not clear. So that 
the recipient may be misunderstanding, the advertisements might be regarded as 
the real contents the sender writes.

However, advertisement is absolutely necessary for the development of internet 
and mobile applications. In order not to interfere with users much, the technology 
for sending advertisement kindly is needed. Email, MMS, IM and SIP messages may 
use MIME as their content body, the advertisement could also be inserted into 
the message body as a MIME content. Maybe a new disposition type can be defined 
to help users distinguish the advertisement and the real contents. Its definition 
is like this:

A bodypart should be marked "inline-subordinate" if it is intended to be displayed automatically upon display of the message, but it should not block other displayed bodyparts, e.g., bodyparts with a regular "inline" disposition type. It is RECOMMENDED that the client render the content marked by inline-subordinate in a separate place away from other inline contents.

Opinion?

Cheers,
Qian

Date: Thu, 01 Nov 2007 10:48:15 +0000
To: "Mikel Lindsaar" <[email-masked]>, [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: Non destructive folding/unfolding (ie, no insertion ofwhitespace in unfolding)
Sender: [email-masked]

At 01:35 01/11/2007, Mikel Lindsaar wrote:

>Hello list,
>
>This is my first post, so I apologise if this has already been
>covered.  I searched through the full text archive file of ietf-822
>(after going through the full itef-smtp archive file) and could not
>find a concrete answer to my question.
>
>I am improving/fixing bugs in a Email library for Ruby - I didn't
>originally write the library, so I am being very careful in any
>changes I make.
>
>One situation I have is where a X-header field and Reply-To field has
>a single piece of text that is longer than the 78 octet limit, but has
>no white space break.
>
>For example:
>
>Reply-To: 
><[email-masked]>
>
>The library currently folds this line as:
>
>Reply-To:CRLF
>LWSP<1234-1234-1234-1234...blah-with-no-further-fold
>
>Now, I have two questions.
>
>1) I believe that putting the CRLF immediately after the : in the
>header field name is in violation of 2822 specifically that the header
>line should contain the name, a colon, the field and terminated by a
>CRLF.  Would this be a correct interpretation?

As I understood it this was OK. For a general unstructured header 
field, it begins with optional FWS, so can be folded there. The 
'Reply-To' is a bit different because it's structured, but I thought 
that FWS could be added at will around the address fields in a 
reply-to field. (I can't find the description of this at the moment 
in RFC 2822, but I'm pretty sure it's OK as that's what section 2.2.2 
seems to say

>2) Irregardless of (1), what is the correct handling of a piece of
>text in the field that is longer than 78 characters, but contains no
>whitespace to fold?  ie, in unfolding, no whitespace can be inserted
>back into the original text which would be destructive to the original
>text.

Just leave it longer than 78

78 is a 'soft' limit, 998 is the hard limit.

Section 2.1.1 -
Each line of characters MUST be no more than
    998 characters, and SHOULD be no more than 78 characters, excluding
    the CRLF

>I saw one mention of doing this:
>
>Reply-To: <1234-1234-1234-1234-1234-12\CRLF
>LWSP34-1234-1234-1234

NO - this will break things. You can only fold at FWS, you can't 
randomly insert FWS into a structured header field...

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Non destructive folding/unfolding (ie, no insertion of whitespace in unfolding)
Date:  Thu, 1 Nov 2007 11:03:32 +0100
Lines: 26
Sender: [email-masked]

Mikel Lindsaar wrote:
  
> The library currently folds this line as:
 
> Reply-To:CRLF
> LWSP<1234-1234-1234-1234...blah-with-no-further-fold

That depends, if you replace LWSP by one or more WSP
it's correct, if you allow another CRLF in LWSP it's broken.

> I believe that putting the CRLF immediately after the : in the
> header field name is in violation of 2822

NAK, wild guess, maybe you confused "header field" with
"header line".  The "header field" consists of the "header
field name" (incl. colon) followed by the "header field body"
(could be empty). The "header field body" can be "folded"
resulting in more than one line, and you can always insert
FWS (e.g. CRLF + WSP) behind the colon.

For values of "always" excluding NetNews articles, where
you can't fold a "header field" before the first non-WSP in
the "header field body", and where you need a "magic SP"
behind the colon (CRLF does not pass as "magic SP" ;-)

 Frank

Date: Thu, 1 Nov 2007 00:24:26 -0700
From: Bill McQuillan <[email-masked]>
To: RFC822 <[email-masked]>
Subject: Re: Non destructive folding/unfolding (ie, no insertion of whitespace in unfolding)
Sender: [email-masked]

On Wed, 2007-10-31, Mikel Lindsaar wrote:

> For example:

> Reply-To: <[email-masked]>

> The library currently folds this line as:

> Reply-To:CRLF
> LWSP<1234-1234-1234-1234...blah-with-no-further-fold

Quoting RFC-2822:

2.1.1. Line Length Limits

   There are two limits that this standard places on the number of
   characters in a line. Each line of characters MUST be no more than
   998 characters, and SHOULD be no more than 78 characters, excluding
   the CRLF.

I would say that the above Reply-To is a good reason to take advantage of
the SHOULD and extend the line beyond 78 characters.

I also believe that the example of folding by the existing library is
accceptable and does not violate RFC-2822.

> I saw one mention of doing this:

> Reply-To: <1234-1234-1234-1234-1234-12\CRLF
> LWSP34-1234-1234-1234

Actually, I think a strict parser would evaluate this by removing the CRLF
and then handling the LHS of the address as:

  1234-1234-1234-1234-1234-12\ 34-1234-1234-1234 

This is probably not what you want!

-- 
Bill McQuillan <[email-masked]>