Re: I-D ACTION:draft-leibzon-responsible-submitter-00.txt (fwd)

On Sun, 10 Oct 2004, Hector Santos wrote:

> I don't have any conflict of interest issues, in fact, my involvement
> has been 100% strictly on the technical merits as well as possible
> legal and social implications of the proposals.  So would it be safe
> for me to discuss client domain issues and how it relates to
> SUBMITTER without getting accused of being rude or emotional?
> The fact is I did have some comments, but when you have others
> scrutinizing people's input, publicly ostracizing them, why should
> one even bother?

You can safely assume that I look at all the comments and appreciate all 
the input. If I see that somebody has other agenda and is trying to 
hijack the thread, I do not respond and would not take their comments 
seriously, but for all other cases I do and appreciate you taking your 
time to review the proposal and would usually respond to the list or
to whoever made the comments directly (but it maybe be up to week before
I respond depending on how much other work I have).
 
> There are four key issues with SUBMITTER:
> 
> 1) Potential legal user privacy issues with the exposure of user addresses.
>
> It would be a major mistake for SMTP developers to open this Pandora Box
> when there is no technical reason to do so.  See #2

Currently user emails are exposed in "From", "Sender", "To", "Cc" and most 
important in "RCPT TO" and "MAIL FROM", none of those have brought privacy
issues that could not be overcome.  

Now the exposure during forwarding by submitter is almost certain to be 
that final recepient would see in submitter the email of original recepient
of the message (before forwarding) I don't think this too much of the 
privacy issue. But for those users that do care, the MTA can insert 
neutral mailbox like "postmaster" instead.
 
> 2) Since this is a domain-level authentication scheme, only the domain is
> required to be exposed. Not the full address.  This will solved #1.
> 
> Note: The other possible solution is to use a responsible "postmaster"
> address to avoid the exposure of user's account addresses that was
> not introduced by the legitimate user himself.

All right I agree that it would be usefull to specifically mention
possibility of using "responsible postmaster" and how it may solve 
certain privacy concerns. In the next version of the draft I will add 
paragrapth regading these issues.

> 3) Responsible domains must change at transition points where the
> original domain is no longer responsible.
Clearly this is so.

> This is a real possibility during deployment where there will be a
> high degree of heterogeneous systems.  We have seen it in practice
> where companies "explore" new advanced SMTP systems with new
> AVS concepts within their existing set or mix of SMTP software.
> 
> If it was not addressed it needs to be added to the specs. If it was
> implied in the spec, it needs clarification.

This will be addressed and clarifed. 
 
> 4) Finally, to support SUBMITTER, any client machine domain authentication
> can not be violated.

That I do not understand. 

This is not about client machine, this is about submitter address which 
in my view more of "network-wide" authentication, i.e. it represents 
address of the person or entity at particular email network which 
was responsible for making changes to direction of the message and thus
is the entity that re-submitted the email message for delivery. The 
actual machine that added submitter maybe several hops away but that 
machine would use email address which corresponds to spf record that
that lists all ip address of other local machines on same network that 
could potentially be the ones sending email out of the net and to another.

> This (#4) was pretty much what Doug is pointing out.  The IP must be secured
> if SUBMITTER is used, hence the machine domain and IP must be secured as
> well.  In fact, in my own AVS scheme, this sort of mix policy conflict is a
> trigger for rejection.

I do not disagree with premises that EHLO name must also be protected and 
that its bettter to check it before SUBMITTER or MAIL-FROM. In fact if
you did not read my comments on what needs to be checked and how see:
 http://archives.listbox.com/[email protected]/200409/0978.html

But I do disagree that "IP must be secured if SUBMITTER is used", I don't
see it as prerequisite. Either SMTP Client knows about the ip and considers
it to be machine on local network (i.e. its agent of the SMTP Client) 
and then EHLO check does not matter (unless somebody hijacked the space...)
or we have unknown ip of some server on another network and we can assume
that server to be an agent of submitter and thus do spf check of submitter
and expect that ip address to verify.

---
William Leibzon, Elan Networks:
 mailto: [email protected]
Anti-Spam and Email Security Research Worksite:
 http://www.elan.net/~william/emailsecurity/