Subject: Moving on from the train wreck

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 17 Sep 2004 07:22:44 -0700

Given the cacophony of verbiage you guys are throwing up I am not replying
to individual emails point be point, instead I am following the repeated
directions of the chair and I am collecting my points into one post.

I am not going to use a different email client to post to this list, the
references field is NOT mandatory. And a RIM device is in any case not going
to support anything other than top posting. And in any case RFC 2822 is NOT
an IETF standard while RFC 822 is. I have a standards compliant email
client, folk who demand support for Draft standards will be ignored.

When I said I agreed with the position raised by Andy that is exactly what I
meant. And yes we are re-opening discussions that were previously closed.
That is a consequence of having train wreck.
 
I find it very difficult to see at this point any area in which the work in
the group has improved the specifications over the input documents. We seem
to have even less consensus and industry support than we started with.
 
People need to decide who they are working for. Are they trying to build
something that will benefit the wider community or are they only interested
in developing systems that benefit themseves? There is a reason I use
commercial Internet software rather than niche applications for techies, it
isn't for my benefit, it is because it is the only way I can understand
problems from the perspective of the average user.

> -----Original Message-----
> From: David Woodhouse [ mailto:[email-masked]
<mailto:[email-masked]> ]
> Sent: Wednesday, September 15, 2004 3:59 AM
> To: IETF MARID WG
> Subject: Re: co-chair judgment of consensus related to last
> call period
> of 23-Aug-2004 to 10-Sept-2004
>
>
>
> On Tue, 2004-09-14 at 20:35 -0500, wayne wrote:
> > [top quoting fixed, extra words deleted, and the Reference: header
> > restored.  All due to brain-dead mail software.]
>
> Thanks for fixing that; it's amazing how poorly people will behave in
> public fora. Personally, I configure my mailing lists to
> reject any mail
> with 'Re:' in the Subject: header but neither References: nor
> In-Reply-To: headers. Philip, you really ought to invest in some
> non-broken mail software if you want to use it in public.
>
> > "Hallam-Baker, Phillip" <[email-masked]> writes:
> > > David Woodhouse [ mailto:[email-masked]
<mailto:[email-masked]> ] wrote:
> > >> I strongly disagree with this opinion. I believe that it
> does not make
> > >> sense to have multiple scopes, and certainly not to plan
> to add even
> > >> more scopes later. I shall explain my reasoning:
> > >
> > > I agree with Andy.
> >
> > No, apparently you agree with David Woodhouse.  It is easy to get
> > confused when you don't use proper quoting.
> >
> > > I thought we should have done this all along.
> >
> > Yes, I know.  This was discussed long ago.  The rough consensus was
> > against your opinion.  I thought that while there should be multiple
> > scopes, we could have one record that covered them all.  The rough
> > consensus was against my opinion.
> >
> > Now, can we *PLEASE* stop re-raising old issues everything
> someone new
> > comes into this working group?
>
> Maybe I have indeed missed the discussion on this precise topic, but I
> suspect you might both have missed my point -- and in either case I
> apologise. Philip might be used to upside-down email and have thought
> that my first paragraph was in fact my conclusion, but I didn't expect
> that of you so it's probably my fault for not being concise enough in
> the first place.
>
> I was not saying that we should ditch either pra or mail-from
> scope and
> continue with only one or the two, which I know is an opinion
> which has
> been voiced before.
>
> I was saying that we should ditch _both_ pra and mail-from scopes and
> continue with something more appropriate.
>
> The point was that the mail-from and pra scopes are _both_ only useful
> for determining a trust level for a given mail server, by determining
> whom it belongs to. The 'domain' we use becomes nothing more than an
> arbitrary 'trust handle' which isn't even seen by most users
> anyway, as
> it's hidden in the Return-Path: or
> Resent-From:^WForwarded-For: headers.
>
> The mailfrom/pra scopes are not useful as end-to-end validation that a
> given mail really did come from the person from whom it
> claims to come.
> A mailfrom/pra 'PASS' is neither necessary nor sufficient to make that
> judgement reliably. There are both false positives and false negatives
> if one were to inadvisedly use it for such a purpose.
>
> Yet the very nature of the scopes makes it easy for the naïve user or
> admin to believe that they can be used that way. Therefore, it is
> actually counterproductive -- because it encourages a mistaken belief
> that this provides real end-to-end authentication when it cannot.
>
> My suggestion is that we should go forward with an entirely
> _different_
> scope, not just unify on either mail-from or whatever the unencumbered
> pra replacement would be.
>
> There are many possibilities which would offer us some 'handle' on the
> owner of the mail server in question, without all the problems which
> both mail-from and pra scopes suffer.
>
> --
> dwmw2
>
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 17 Sep 2004 17:16:35 +0200

On Fri, Sep 17, 2004 at 07:22:44AM -0700,
 Hallam-Baker, Phillip <[email-masked]> wrote 
 a message of 233 lines which said:

> We seem to have even less consensus and industry support than we
> started with.

It is often the case in working groups. Sometimes, problems are more
complicated than they seem at the first glance and work done in common
help to push asides half-baked ideas. Hardly a failure.

[Below this point, we are off-topic.]
  
> There is a reason I use commercial Internet software rather than
> niche applications for techies, it isn't for my benefit, it is
> because it is the only way I can understand problems from the
> perspective of the average user.

Walk two or three miles to get water, instead of turning the tap, and
you will understand problems from the perspective of the average
African woman. Interesting idea.

---

From: Meng Weng Wong <[email-masked]>
Date: Fri, 17 Sep 2004 13:22:38 -0400

On Fri, Sep 17, 2004 at 04:46:14PM +0100, David Woodhouse wrote:
| 
| 1. The use of '-all' on domains which do actually send mail should be
| forbidden in both mailfrom and pra scopes, until a later date when it is
| decided that enough of the world has upgraded to cope with this.
| 

isn't that why the standards track is a standards track and
not a standards point?

if we expect it will take 1 to 3 years for the world to
upgrade, maybe we can take 1 to 3 years to move from
proposed standard to draft standard to standard.

---

From: Tom Kistner <[email-masked]>
Date: Fri, 17 Sep 2004 20:24:11 +0200

Hallam-Baker, Phillip wrote:

> references field is NOT mandatory. And a RIM device is in any case not 
> going to support anything other than top posting. And in any case RFC 
> 2822 is NOT an IETF standard while RFC 822 is. I have a standards 
> compliant email client, folk who demand support for Draft standards will 
> be *ignored*.

As some folks will ignore you after your public outing as an antisocial. 
This does not exactly bolster your credibility as a contributor to this 
group. Somehow this fits in very well with the behaviour of your current 
employer.

> I find it very difficult to see at this point any area in which the work 
> in the group has improved the specifications over the input documents. 
> We seem to have even less consensus and industry support than we started 
> with.
>  
> something that will benefit the wider community or are they only 
> interested in developing systems that benefit themseves? There is a 
> reason I use commercial Internet software rather than niche applications 
> for techies, it isn't for my benefit, it is because it is the only way I 
> can understand problems from the perspective of the average user.

So you imply that the industry is representing the largest part of the 
community. Corporations represent their shareholders, not their 
customers. This is why Microsoft is not willing to give up on its patent 
claim, even if it would also benefit their users to do so.

regards,

/tom

---

From: David Woodhouse <[email-masked]>
Date: Fri, 17 Sep 2004 19:28:47 +0100

> proposed standard to draft standard to standard.

An excellent idea. Then shall we settle upon the following:

While SRS is not officially documented or is merely a proposed standard,
the language should be that you 'MUST NOT' publish a record ending in
'-all' for a domain which does actually send mail.¹

When SRS becomes part of a draft standard _and_ is widely implemented,
that can be relaxed to 'SHOULD NOT'. Finally when SRS becomes part of a
real standard, the restriction can be relaxed entirely.

That's my preference -- to save unnecessary amounts of email being
traded back and forth, let me save time and draw up a table of what I'll
admit up-front that I'll reluctantly fall back to under pressure :)

SRS status      Preference	Acceptable
--------------------------------------------
I-D or less	MUST NOT	MUST NOT
RFC		MUST NOT	SHOULD NOT
Proposed Std.	MUST NOT	SHOULD NOT
Draft Std.	MUST NOT	SHOULD NOT
Draft++		SHOULD NOT	MAY
Standard.	MAY		MAY

Note the 'Draft++' state indicates a state where SRS is both a Draft
Standard and _also_ is found to have widespread implementation.

Also note that the same set of requirements is appropriate for PRA
w.r.t. the addition of whatever replaces the Resent-From: header.

However -- unless I'm mistaken, the MARID drafts don't actually document
SRS, while they do document the requirement to add a header when
forwarding. So the language in the marid-pra draft would be tied to its
_own_ progression through the standards-track, while the language in the
marid-mailfrom draft would be tied to the progress of something else
which does not yet exist. While that's unfixed, we remain on the first
line of my table above.

I consider the lack of documentation of SRS (or indeed of any other
mechanism which must be implemented to correct the flawed assumptions of
the original SPF) to be a serious technical omission in the current
marid-mailfrom draft.

The PRA folks have documented the required fix for _their_ flawed
assumptions, and once the choice of header is fixed it's not so onerous,
so it stands a reasonable chance of getting deployed and hence fixing
their assumptions. The mailfrom folks desperately need to catch up.

-- 
dwmw2

¹ I'd also accept qualifying this with "unless the previous mechanisms
do not depend on the deployment of SRS". For example, if I were using a
stunt DNS server in conjunction with the 'exists' mechanism and my
existing BATV implementation, or if I were using marid-mailfrom simply
to publish a list of 'acceptable' localparts for my domain without any
IP-based restrictions, then the
use of '-all' would make sense even today.

---

From: David Woodhouse <[email-masked]>
Date: Fri, 17 Sep 2004 16:46:14 +0100

On Fri, 2004-09-17 at 07:22 -0700, Hallam-Baker, Phillip wrote:
> Given the cacophony of verbiage you guys are throwing up I am not
> replying to individual emails point be point, instead I am following
> the repeated directions of the chair and I am collecting my points
> into one post.

I did send a lot of email and for that I have already apologised to the
co-chairs after the three message guideline was mentioned to me.

Now that I am posting anyway, I offer my apology to the other
participants too. I shall limit my posting in future.

I made three main technical points which I then argued in support of;
none of which you appear to have addressed directly. They were:

1. The use of '-all' on domains which do actually send mail should be
forbidden in both mailfrom and pra scopes, until a later date when it is
decided that enough of the world has upgraded to cope with this.

Others said that this should be a site-specific policy, but we as a
group are here to co-ordinate _interoperability_ rather than preside
over a system which degenerates into chaos. By publishing RFCs we set up
rules which are to be followed to ensure compatibility -- an RFC 'MUST
NOT' is a rule which should be followed to ensure interoperability, not
a law which we would jail you for disobeying. 

As a compromise I suppose I would accept Rik van Riel's suggestion of a
SHOULD NOT. Others who vehemently opposed my suggestion of 'MUST NOT'
were also amenable to that.

2. The reuse of the Resent-From: header is not in accordance with
current practice, and not in accordance with many interpretations of
RFC2822. 

Although the latter point has been disputed, the former has not -- and
no reason has been put forward for the choice of 'Resent-From:' instead
of the introduction of a new and unambiguous header. Therefore I assume
that consensus has been reached, and this will be changed in the next
draft which describes the pra scope. As a straw man, I propose the use
of 'Forwarded-For:' in replacement.

3. The ability of forwarders to use SRS or the Forwarded-For: header to
change the 'responsible' domain renders the 'trust question' into simply
a matter of how much we trust the (owner of) the individual mail server
which is offering the mail. We are _not_ offering true end-to-end
authentication of messages, and it would be counterproductive for us to
give the illusion of doing so; there are other working groups looking at
real answers to that problem.

Thus, the odious requirements which are made of forwarders by the
mailfrom and pra scopes are unnecessary. We should look for alternative
'trust keys', rather than the domain in the RFC2821 MAIL FROM or RFC2822
headers respectively, which serve merely to identify the entity which is
responsible for the server in question.

Rand Wacker stated that he is concerned about the current direction,
because there hasn't been a lot of technical discussion about the
implications of changing the return-paths. With the note that this
applies just as much to the pra scope as the mailfrom scope, I agree
wholeheartedly with his opinion. The use of SRS and Forwarded-For: to
'take responsibility' for forwarded email seems to have been bolted on
as an afterthought, without much thought given to the implications.

> I find it very difficult to see at this point any area in which the
> work in the group has improved the specifications over the input
> documents. We seem to have even less consensus and industry support
> than we started with.

That in itself is useful information and should be considered deeply.

-- 
dwmw2