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

[Shevek <ietf-mxcomp@xxxxxxxxxxx>]

On Mon, 9 Aug 2004, Harry Katz wrote:

> On Monday, August 09, 2004 4:49 PM Shevek wrote:
> 
> > On Mon, 9 Aug 2004, Harry Katz wrote:
> > 
> > > On Monday, August 09, 2004 10:24 AM ned.freed@xxxxxxxxxxx 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.
> 
> Actually, it is correct.  From section 4.2 of the submitter-02 draft:
> 
>    If these tests indicate that the connecting SMTP client is not
>    authorized to transmit e-mail messages on behalf of the SUBMITTER
>    domain, the receiving SMTP server SHOULD reject the message and when
>    rejecting MUST use "550 5.7.1 Submitter not allowed."
> 
>    If the receiving SMTP server allows the connecting SMTP client to
>    transmit message data, then the server SHOULD determine the purported
>    responsible address of the message by examining the RFC 2822 message
>    headers as described in [SENDER-ID].  If this purported responsible
>    address does not match the address appearing in the SUBMITTER
>    parameter, the receiving SMTP server SHOULD reject the message and
>    when rejecting MUST use "550 5.7.1 Submitter does not match header."
> 
> In other words, if SUBMITTER is present and fails the Sender ID check at
> 2821 time, then the message SHOULD be rejected.  The subsequent matching
> of SUBMITTER to 2822 headers is only to confirm - if DATA is accepted -
> that the SMTP client didn't lie about the value.  

This is NOT equivalent to a verification of the sender's identity, as 
suggested above, and therefore does not permit an early success 
optimisation. There is no shortcut.[0]

It does permit early failure, but if implemented correctly, one would hope 
that the spammers would be forced to use the success case. Thus this 
optimisation offers no saving of bandwidth, CPU or anything else.

S.

[0] I fully expect many implementations to implement this as a shortcut, 
and weaken the system. The later processing is too complex and breaks the 
layers which so many MTAs are architected to respect.

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