On Monday, August 09, 2004 5:40 PM Philip Miller wrote:
Shevek wrote:
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.
The idea is that the DNS lookup and check can be parallelized
with the continuation of the mail transaction, and then the
final response to the DATA payload will be sent when the PRA
matches the SUBMITTER and the SUBMITTER is allowed by its
domain's DNS record.
Sure, that's one possible implementation choice, but not the only one.
The spec recommends rejection if the SUBMITTER value fails the Sender ID
check. Matching the SUBMITTER value to the 2822 headers is a separate
requirement.