ietf-mxcomp
[Top] [All Lists]

Re: Does marid-submitter-02 really make sense?

2004-08-09 18:49:20

At Tuesday, August 10, 2004 12:48 AM "Shevek" 
<ietf-mxcomp(_at_)anarres(_dot_)org>
objected:


On Mon, 9 Aug 2004, Harry Katz wrote:

On Monday, August 09, 2004 10:24 AM ned(_dot_)freed(_at_)mrochek(_dot_)com 
wrote:

First, I am not proposing anything here. Not only is
SUBMITTER not my idea, I have been quite clear that I am
ambivalent about its inclusion in MARID.

Second, the optimization in case 1 isn't a failure case but a
success case.
There may be a throughput improvement in some MTAs if the
check can be done sooner. Mind you, I'm not saying there is
guaranteed to be such an improvement
- just that it is a possibility. Actual implementation
experience would be needed to tell for sure.

Ned is exactly correct here.  The purpose of SUBMITTER is to allow early
(i.e. at 2821-time) verification of the sender's identity, namely the
PRA.  At the IETF meetings last week there was some discussion of
whether this would result in bandwidth saving, throughput improvement,
or no benefit at all.  I tend to think there will be modest throughput
improvement, but agree with Ned that we need to verify through testing.

This is incorrect. At 2821 time, we know only who the sender CLAIMS to be
via SUBMITTER. It's not until after 2822 time, when we can compare the
SUBMITTER value to the PRA value computed from the 2822 headers that we
have verified the identity of the sender.

S.

--
Shevek                                    http://www.anarres.org/
I am the Borg.                         http://www.gothnicity.org/




The situation is actually rather amazing, AFAICT.

So long as a client has a SUBMITTER domain which can pass the receiver's
2821-time test, it will so arrange things that it will_never_ fail the SUBMITTER
== PRA? test undertaken at 2822 time.

The reason:

Section 4.1 of submitter-02 states that clients
"...MUST if necessary, insert ... RFC 2822 headers ... to .[make the PRA] ..
match the SUBMITTER address".

Now, if you look at step 1 of the PRA algorithm in core-02, the first non-empty
Resent-Sender header can supply the PRA.  There may be any number of subsequent
Resent-Sender headers - the first one wins.

So, if I were a client wishing to avoid the 'hassle' of bounces I would just
automatically prepend all messages I sent with a Resent-Sender header containing
the same as my SUBMITTER address.  The PRA algorithm will always deduce this to
be the PRA and so the 2822-time test will always be passed.

It would not matter what the 'real' headers were in the message I was asked to
send - I can always trump them with my SUBMITTER address in a leading
Resent-Sender field.

OK - this does not sound honest.

But look again at section 4.1 of submitter-02.  It *requires* the client to
adjust the headers so that SUBMITTER and PRA match, and I have shown above that
this can *always* be done.

A rather smarter / honest / helpful client could use the PRA algorithm in
reverse and try adding a From, or a Sender, or a Resent-From header in order to
pass the PRA test in preference to just going straight for a Resent-Sender
header. But why should it bother, and on what semantic basis should it / could
it choose any of the other available headers to use?

So, it appears to me that the two drafts combine to ensure that clients which
can pass the SUBMITTER test at 2811 time should *never* fail the  2822-time
test.

In fact, a client which sends a message which then fails a  2822-time test  is
non-conformant to the drafts!

HTH

Chris Haynes