Mailing lists as 2822-Sender (was: Responsibility vs. Validity)

Scott Kitterman wrote on the DKIM list:

> On Thursday 29 November 2007 06:32, Charles Lindsey wrote:
>> Note that a mailng list expander is supposed to insert a Sender.

> IIRC it's a SHOULD and not a MUST, so one really can't rely on it.

Can you (Charles + Scott, or anybody else who knows it) please
check this ?  I thought that mailing lists are NOT supposed to
insert Sender (or Resent-*) header fields unless they wish to 
participate in PRA checks (RFC 4406).

Example:  Charles + Scott as authors (2822-From) post an answer
to a mailing list (with 2822-Sender Scott), what's the mailing
list software supposed to do if it doesn't support a 4406 PRA ?

 Frank (cc rfc822, maybe it's not exactly a DKIM question)

Re: Mailing lists as 2822-Sender

Frank Ellermann wrote:
> Scott Kitterman wrote on the DKIM list:
> 
>> On Thursday 29 November 2007 06:32, Charles Lindsey wrote:
>>> Note that a mailng list expander is supposed to insert a Sender.
>  
>> IIRC it's a SHOULD and not a MUST, so one really can't rely on it.
> 
> Can you (Charles + Scott, or anybody else who knows it) please
> check this ?  I thought that mailing lists are NOT supposed to
> insert Sender (or Resent-*) header fields unless they wish to 
> participate in PRA checks (RFC 4406).

Sender predates PRA so how can PRA regulate it?

> Example:  Charles + Scott as authors (2822-From) post an answer
> to a mailing list (with 2822-Sender Scott), what's the mailing
> list software supposed to do if it doesn't support a 4406 PRA ?
> 
>  Frank (cc rfc822, maybe it's not exactly a DKIM question)

Unless I am mis-understanding here, if so, I apologize for jumping in ....

No,  for a mailing list, Sender: is generally the mailing list's "Pseudo 
Admin Agent",  like for this list IETF-DKIM message:

     Sender: ietf-dkim-bounces <at> mipassoc.org

or like in our setup in our support lists:

Re: Mailing lists as 2822-Sender

Hector Santos wrote:

> Sender predates PRA so how can PRA regulate it?

List owners can decide that they wish to support PRA checks based
on RFC 4406 (or based on an IESG note repeated in "other" RFCs 

>> Example:  Charles + Scott as authors (2822-From) post an answer
>> to a mailing list (with 2822-Sender Scott), what's the mailing
>> list software supposed to do if it doesn't support a 4406 PRA ?
[...]

> No,  for a mailing list, Sender: is generally the mailing list's
> "Pseudo Admin Agent",  like for this list IETF-DKIM message:

>      Sender: ietf-dkim-bounces <at> mipassoc.org
> or like in our setup in our support lists:
>      Sender: listadmin <at> winserver.com

> So Scott should not be in the Sender: field.

Would the mailing list software replace the Sender: Scott header
field, or would it reject the submission ?  What I really wanted
to know, Scott mentioned a SHOULD about this issue, but which RFC
(apart from RFC 4406) talks about Sender header fields set by a 
mailing list ?  I'm looking for an RFC number, not for an example
what some lists actually do.  I think the RFCs about List header
fields and the List-ID don't mention Sender, but I could be wrong.

> The key thing is that it should never be part of a HUMAN reply

Unquoted " <at> " in From still in the wild?

Re: Unquoted " <at> " in From still in the wild?

> Hello all,
> I am fixing up the TMail mail library for Ruby.  As part of this, I am
> incorporating the patches the Ruby on Rails guys have done to the library
> for their implementation. But I am checking each one :)

> There is a test case for an unquoted  <at>  char in the from line.  Their
> handling was to whack " <at> " into the ATOM_CHARS definition.  Per RFC 2822
> 3.2.4 this is not a valid character for the ATOM set.

THat's a really terrible idea. Sooner or later anything that allows addresses
that are clearly syntactically invalid is going to run into trouble dealing
with some other agent that does enforce the rules.

> The reason they put this in is to handle a bug in Apple Mail.app which was
> not quoting the From field correctly if it contained a  <at>  symbol.  This has
> been fixed in subsequent revisions of Mail.app.

Which was the right way to address the problem. Hacking everything else out
there in order to cater to one buggy applications is a sure path to madness.

> The problem is, that
> putting  <at>  into ATOM_CHARS obviously breaks other test cases in the TMail
> library.

No kidding.

> My question is 2 fold:

> 1) Removing  <at>  is the obvious simple solution to return to the RFC2822 spec
> as Apple have fixed Mail.app, but is this "bug" implemented elsewhere the
> list members know of?

There used to be some LAN email system that used addresses of the form

    a <at> b <at> c

(I'm sorry but I forget which one it was.) Occasionally one off these
addresses would leak out onto the Internet. But that's was quite some
time ago and I haven't seen anything comparable since.

I've also seen addresses of the form

   "a <at> b" <at> c

used, but of course these are syntactically valid.

>  Should I spend the time to handle it in this edge
> case in the library?

You have basically two viable choices: Treat it as the syntax error it is or
else add quotes to make it syntactically valid. Which one is appropriate is
impossible to say without knowing a lot more about the context in which this is
going to be used.

> It looks like a bit of a hack to change the parser to
> allow this and I don't want to go there if I don't _have_ to...

You definitely don't _have_ to.

> 2) Is  <at>  actually allowed in the description area of the From field (ie:
>  From: mikel <at> me <mikel <at> me.com> ) from a revision to the RFC that I am
> unaware of?

Not unless it is quoted. Stuff like

  "a <at> b" <a <at> b>

is unfortunately pretty common (unfortunate because it is udly and unnecessary
and tends to break simplistic parsers). But

  a <at> b <a <at> b>

is clearly bogus. And if you use it I predict the results are going to be wildy
variable - there are all sorts of ways to "resolve" such an error.

				Ned

Re: Unquoted " <at> " in From still in the wild?

On Sun, 2 Dec 2007, Mikel Lindsaar wrote:
>
> The reason they put this [bug] in is to handle a bug in Apple Mail.app
> which was not quoting the From field correctly if it contained a  <at> 
> symbol.  This has been fixed in subsequent revisions of Mail.app.

Mail.app is catastrophically bad at letting a user's syntax errors leak
through into 822 and 821 address fields. (It also retrys in the face of
a permanent syntax error, without any time limit or frequency back-off.)
Breaking your code to accommodate its lameness is foolish.

Tony.
--

-- 
f.a.n.finch  <dot <at> dotat.at>  http://dotat.at/
FAEROES SOUTHEAST ICELAND: NORTHWESTERLY VEERING SOUTHEASTERLY 6 TO GALE 8,
PERHAPS SEVERE GALE 9 LATER. ROUGH OR VERY ROUGH. WINTRY SHOWERS, THEN RAIN OR
SLEET. MODERATE OR GOOD, OCCASIONALLY POOR LATER.

Handling of NO-WS-CTL in 2822bis

Pete asked me to post my position on this, so...

I believe that the best course of action is to remove NO-WS-CTL from
the generate syntax, leaving it in the interpret syntax. This includes
its use in quoted-pair/qtext, ctext, and dtext.

I think this is the right way to go because otherwise it is going to be
tought o demonstrate interoperability moving to draft. It's especially
important to remove it from quoted-string since those can be parts of
addresses, but I fail to see a reason why we should retain this for
comments or domain literals.

				Ned

Re: Handling of NO-WS-CTL in 2822bis

+1. Seems the best compromise to move forward.

	Tony Hansen
	tony <at> att.com

ned+ietf-822 <at> mrochek.com wrote:
> Pete asked me to post my position on this, so...
> 
> I believe that the best course of action is to remove NO-WS-CTL from
> the generate syntax, leaving it in the interpret syntax. This includes
> its use in quoted-pair/qtext, ctext, and dtext.
> 
> I think this is the right way to go because otherwise it is going to be
> tought o demonstrate interoperability moving to draft. It's especially
> important to remove it from quoted-string since those can be parts of
> addresses, but I fail to see a reason why we should retain this for
> comments or domain literals.
> 
> 				Ned
> 

Re: Handling of NO-WS-CTL in 2822bis

In <47549F7B.9090704 <at> att.com> Tony Hansen <tony <at> att.com> writes:

>+1. Seems the best compromise to move forward.

+1

--

-- 
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

Re: Handling of NO-WS-CTL in 2822bis

On 12/3/07 at 2:51 PM -0800, ned+ietf-822 <at> mrochek.com wrote:

>I believe that the best course of action is to remove NO-WS-CTL from 
>the generate syntax, leaving it in the interpret syntax. This 
>includes its use in quoted-pair/qtext, ctext, and dtext.

Let me explain what is involved in doing this. If people are OK with 
this, I'll go ahead. To remove NO-WS-CTL, we need to:

- Remove NO-WS-CTL from ctext, qtext, utext, and dtext. (That makes 
utext simply VCHAR.)
- Create obs-ctext, obs-qtext, and obs-dtext which contain NO-WS-CTL. 
(Question: Should they contain NUL as well?)
- Add NO-WS-CTL to obs-utext.
- Change quoted-pair to use "WS / VCHAR" instead of "text".
- Change section 2.2 to say that header fields only contain VCHARs.
- Change much of the text in the beginning of section 4 to add talk 
of NO-WS-CTL.

Is everyone sure they want to do this? Do we think this will recycle 
at Proposed? It is effectively removing what we think is an unused 
feature from the document in anticipation of Draft, but it is a 
significant textual change.

pr
--

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