On Sun, 2004-10-10 at 15:32, william(at)elan.net wrote:
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 clarified.
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/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/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.
On point 1 that Hector made, this system must be able to run with an
"open-ended" list without inviting exploits. This is needed to allow
providers an ability to permit any mailbox address in the messages
sent. The dual role of using the mail-channel address list as a means
of both authorizing the message and the client unfortunately makes these
open lists attractive for spammers due to unfair accountability. This
freedom is lost once these open lists become so inundated as to be
unusable. This also makes for a painful transition and an eventual loss
of freedom.
The use of an address list comes with a substantial risk which
unfortunately is the premise that SPF and Sender-ID use. The dual use
of this list invites exploits when described as "open-ended" but there
is nothing within the SPF protocol to detect this "open-ended" state.
Do you understand this problem and do you have a solution?
As related to Submitter, to prevent spoofing and allow the use of
"open-ended" lists, there must be a name that can not be spoofed in this
environment. This mechanism will likely be needed for at least half a
decade. There are no headers within the email message that can be
directly authenticated. Even Submitter exposing these early in the
transaction does not decease the ability to spoof these names in a
partially open environment.
There is nothing within the SPF protocol draft to ensure exclusion of
repeated label lookups. A popular version of Bind also makes this
oversight. The use of a script parser makes this problem worse. Do you
understand this problem and can you explain how this is overcome?
The grave problems created by the use of address lists with respect to
DNS and network integrity is solved by adopting a name list to describe
the mail-channel. Financial institutions that are heavily phished, are
not using mailing lists, and have warned their customers about their
messages not able to be forwarded, can close their lists. The solution,
for "open-ended" list exploitation as well as the DNS and network
related issues, is found by using a name list. Through the use of a
name list for the mail channel, the lists can remain open for the
majority of users for a smooth transition, and closed when needed. The
dual use address list is extremely problematic in this area. Do you
understand the problem and do you have a solution for this?
The expectations of there being a flag day or some key point where all
lists will suddenly become closed have not confronted issues in this
transition to full compliance. This compliance is put into greater
doubt should Microsoft spend a decade battling over these issues in
court. Once these lists are seen as normally being "open-ended," then
the selection of the "accountable name" used in Submitter should be
reconsidered. A strong name is needed that can be directly
authenticated in order to prove protection against spoofing and
phishing.
-Doug