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

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 7 Oct 2004 18:15:51 -0700 (PDT)

FYI

---------- Forwarded message ----------
Date: Thu, 07 Oct 2004 15:34:38 -0400
From: [email-masked]
To: [email-masked]
Subject: I-D ACTION:draft-leibzon-responsible-submitter-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Responsible Submitter of an E-mail Message
	Author(s)	: W. Leibzon
	Filename	: draft-leibzon-responsible-submitter-00.txt
	Pages		: 18
	Date		: 2004-10-7
	
This memo defines an extension to the Simple Mail Transfer Protocol
   (SMTP) service, which allows an SMTP client to specify the
   responsible submitter of an e-mail message.  The responsible
   submitter is the e-mail address of the entity most recently
   responsible for introducing a message into the transport stream.
   This extension helps receiving e-mail servers efficiently determine
   whether the SMTP client is authorized to transmit mail on behalf of
   the responsible submitter's domain.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-leibzon-responsible-submitter-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-leibzon-responsible-submitter-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-leibzon-responsible-submitter-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: Douglas Otis <[email-masked]>
Date: Thu, 07 Oct 2004 20:37:47 -0700

> http://www.ietf.org/internet-drafts/draft-leibzon-responsible-submitter-00.txt

Here are some excerpts from this recent Submitter proposal.

| The purpose of the SUBMITTER parameter is to allow the SMTP client to 
| indicate to the server the address of the entity most recently
| responsible for injecting a message into the e-mail transport stream.

One possible view, assuming it is authenticated, would be the HELO
domain is the entity most recently accountable for injecting the
message.  This provides a clear and strong definition.  It also does not
require a modification to SMTP for this information to be obtained early
within the SMTP transaction and steers clear of many complexities.

...
| This document provides means to authenticate the DOMAIN of the 
| appropriate email address; it is not directed at the local-part.

That is good, as the HELO domain does not have a local part.
 
| A domain owner gets to determine which SMTP clients speak on behalf
| of addresses within the domain; a responsible domain owner should not
| authorize SMTP clients that will lie about local parts.

If this were done using a list of root HELO names, the mailbox domain
owner could easily describe which SMTP clients speak on behalf of this
mailbox domain, always within a single DNS lookup.  I don't understand
what is meant by lying about local parts.  It would make more sense had
this said to limit the authorization of SMTP clients to those shared by
other responsible mailbox domains.  But as these mailbox domains must
not be held accountable for this sharing, it would make even more sense
to say only the HELO domain is to be held accountable for any abuses.  
  
| In case of email submission by end-user this address can be found in
| "Sender:" header since RFC2822 specifies that Sender header represents
| "agent responsible for actual transmission of the message" and if
| Sender is not present then responsible party is email author listed
| in "From:" header.

Would it not be equivalent to saying the authenticated HELO domain plays
the role of sender?  In which case, the HELO root name list referenced
by the RFC2822 From mailbox domain can then indicate when the message is
"outside" the nominal mail channel.  Mail policy asserted by the mailbox
domain owner could also indicate whether messages "outside" the nominal
channel are to be rejected.  This prevents the problem of invited
exploits where SMTP client authentication is also attempted using this
description of this nominal mail channel with a long list of addresses. 
This long address list provides many other serious risks as well.  

| In case of email list, the responsible party is mail list and the
| address should be that of email list itself. 

Again, an authenticated HELO domain can play this role with much less
chance of spoofing.  In many cases, the HELO domain will be the same
domain as the RFC2822 sending domain. 

| In case of forwarding service, the address should be that of the
| forwarding agent or that of a user of that forwarding agent, whose
| settings caused email retransmission.

Here again, an authenticated HELO domain can play this role with much
less chance of spoofing.  The use of the HELO domain does not require a
modification to SMTP and provides a stronger and more secure named
identity.  The mailbox domain can be protected by describing the nominal
mail channel through the use of root name lists of these HELO domains.

The admonishments regarding the mailbox domain authorization of SMTP
clients is entirely misplaced, as the administrator of the SMTP client
must be held accountable, and this administrator is positively
identified by the HELO domain.  Any other domain reference would be
based upon an unverifiable assumption of the mail channel integrity.

For more details see:
http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt

-Doug

---

From: Greg Connor <[email-masked]>
Date: Fri, 08 Oct 2004 22:53:51 -0700

Thank you William, for taking the time to write and submit this draft.

I like the idea of having a SUBMITTER extension to ESMTP, mostly because it 
allows another alternative for forwarders who don't want to munge the 
return-path ala SRS.

Some quick comments on the draft...

--"william(at)elan.net" <[email-masked]> wrote:
> 4.1 Setting the SUBMITTER Parameter Value
>
...
>
>    SMTP servers which are involved in retransmission of the message but
>    which do not cause change in the direction of SMTP transmission
>    SHOULD use SUBMITTER value they received during incoming SMTP
>    transmission as value for outgoing SMTP transmission. If there was
>    no SUBMITTER MAIL parameter during incoming transmission, then SMTP
>    server MUST NOT use SUBMITTER for outgoing transmission unless it
>    can find email address of the entity which last caused introduction
>    of a message into the email delivery system by other means.

Keeping the same Submitter at an intermediate hop might result in a Fail. 
You might consider relaxing this language a bit to allow for cases where 
the message is being passed along at points other than its initial 
injection where Submitter is most likely to Pass.

My suggestion would be to have a given mail server decide whether it is 
acting as an agent for the sender, or an agent for the receiver.  If the 
mailserver doing the sending is authorized to accept any and all mail for 
the recipient (RCPT) regardless of the sender's identity (i.e. if the 
Recipient is considered local) then it is probably an agent for the 
receiver, and it should check the Submitter value, but should probably not 
pass it on.  If the mail server doing the sending is acting as an agent for 
the Submitter, and a check that uses its own IP would result in a Pass, 
then it is OK to pass the Submitter value on.

>    An SMTP client that supports the Responsible Submitter extension and
>    that can set Responsible Submitter value MUST include the SUBMITTER
>    parameter on all messages. This includes messages containing a null
>    reverse-path in the MAIL command.

A couple exceptions might be 1. if the Submitter is the same as the return 
path, maybe it is not needed, or 2. if the client is an agent for the 
receiver, not the sender, and it has already verified Submitter itself 
(because verifying Submitter again at the next hop might fail.)

> 4.2 Processing the SUBMITTER Parameter
>

Might want to add something like, "It is important to note that the 
Submitter is not intended to bypass or replace other checks, such as return 
path or HELO, *unless* the receiver trusts the sender to substitute an 
alternate return path.  The presence of Submitter alone should not be taken 
as a substitute for other checks.  The receiver should exercise best 
judgement when setting the policy regarding when to bypass other checks."

> 5.1 Publishing DNS Authorization Records
>
>    Domains that are used as part of the Responsible Submitter address
>    SHOULD publish SPF DNS Authorization records that allow to verify
>    ip addresses of hosts that are authorized to use given domain when
>    setting SUBMITTER parameter. SPF records used for publishing this
>    information MUST use "submit" scope identifier.

Do you want to say that a scope of /submit will be used for this check, and 
if not present, then a general-purpose SPF record may be used instead? 
That would allow sites to publish a single record for all scopes, if those 
scopes have the same access characteristics anyway.

> 5.2 Checking DNS Authorization Records
>
>    For an SMTP Server to test authorization of SMTP Client to use
>    certain domain as part of the SUBMITTER parameter, the SMTP Server
>    MUST evaluate the results of check_host() function as defined in
>    [SPF-PROTOCOL] with arguments as follows:
>
>        <scope>   - the "submit" scope identifier
>        <ip>      - the ip address of the SMTP client host
>        <domain>  - the domain portion of the SUBMITTER parameter
> 	 <sender>  - the full email address in SUBMITTER parameter
>
>    If SMTP Client provided SUBMITTER argument to MAIL command then SMTP
>    Client SHOULD perform authorization check during the time of SMTP
>    transaction. The check can be performed directly at the time of MAIL
>    command or it may be easier to delay the check to later stage of SMTP
>    transmission.

I would include a note here to say that checking the validity of the 
Submitter parameter during the initial submission is a best practice, 
because it allows the receiver to stop the transaction with a 5xx error (or 
4xx for temp fail) and won't result in a bounce message being send to a 
(supposed, unverified) sender.  Checking after the fact can also be 
supported (perhaps as part of a scoring system) but receivers are 
recommended to check during initial receipt if possible.

> 5.3 Interpreting the Results of SPF Verification
>

Regarding the interpretation section, I think we should probably push for 
SUBMITTER to get a Pass result, or else it should be pretty much ignored. 
It particular, if the Submitter check doesn't result in a Pass, then it 
should not be used as a basis for establishing trust (for example, in order 
to bypass return path checks that would otherwise fail).  Might want to 
state up front that results other than Pass should not be used to extend 
trust.

> 5.3.2  Pass

A Pass result alone should not be considered sufficient to bypass other 
checks.  For example, a forwarder may use Submitter to signal that it is 
forwarding a message with a return path that it is not normally allowed to 
use, and that the receiver is requested to check Submitter and not check 
return path.  The receiver in this case should only bypass the return path 
check if it trusts the forwarder to forward mail and assert an alternate 
return path.

Or, a receiver may choose to note the submitter and return path and allow 
the MUA to decide which submitters are trusted.

> 5.4.1 Displaying Verification Results in MUA
>
>    When displaying a received message, an MUA SHOULD check message for
>    Authentication-Results headers and if last entered such header is
>    proceeded only by Received and Return-Path trace headers which appear
>    to have been added by MDA or by other MTAs which are known to be on
>    the same network as MUA, then MUA should display the value of
>    Responsible Submitter as found in "envelope-submitter" as well as
>    display to the user the results of SPF verification.
>
>    If email address of Responsible Submitter is the same as address in
>    one of the "From:" headers, then MUA should show that email address
>    as email origin and indicate by some means that it has been SPF-
>    verified based on submitter identity. If header "From:" address is
>    not the same, then origin of the email should be indicated as being
>    that of Responsible Submitter with email listed as having been sent
>    on behalf of the party listed in "From:" header. It should be made
>    clear that only Responsible Submitter part of the email origin has
>    been SPF-verified and not the header "From:" address part.
>
>    MUA may also want to find envelope-submitter values from all
>    "Authentication-Results:" headers as well as "Sender:" and all
>    "From:" headers and display them as addresses responsible for
>    transmission of the message.

Optionally, a MUA may choose to keep a list of which submitter values are 
"trusted" (such as the users own forwarding address).  If the submitter is 
trusted, *and* a previous/second Authentication Results header exists (in 
proper order to have been added by the trusted forwarder), the MUA may 
choose to display this authentication result instead.

(In other words, if a mail is claimed to be forwarded, then the submitter 
should be displayed and attributed as the sender, unless the MUA knows that 
the submitter is really a forwarding account that I have assigned as 
trusted, in which case the message can be safely attributed to whatever 
submitter came right before.  If the MUA doesn't allow users to set trust 
levels, then anyone who uses a forwarding address will see his own address 
as the Submitter for pretty much every message.)

> 6.1 Mail Submission
>
>    Under normal circumstances, Alice would configure her MUA to submit
>    her message to the mail system using the SUBMIT protocol [SUBMIT].
>    The MUA would transmit the message without the SUBMITTER parameter.
>    The SUBMIT server would validate that the MUA is allowed to submit a
>    message through some external scheme, perhaps SMTP Authentication
>    [SMTPAUTH].  The SUBMIT server would then extract her address from the
>    RFC 2822 header "Sender" or if it missing then out of first "From:"
>    header and it would set SUBMITTER parameter to this address for
>    subsequent transmissions of the message.
>
>    Note that setting SUBMITTER parameter based on values of "Sender" and
>    "From" header should be done ONLY if SMTP Server is certain that mail
>    submission is taking place, i.e. if either SUBMIT protocol is used or
>    if SMTP protocol with SMTP authentication [SMTPAUTH] is used.

Might want to refer readers to RFC 2476 and remind them that it is the 
responsibility of the SUBMIT server to verify that the person submitting 
the message is really authorized to use the claimed return-path.  It is 
legal to assert a different return path (for example if Alice would like to 
send from the current location but would like any bounces or delivery 
reports sent to her other address) BUT with two caveats.  1. The server 
accepting the initial submission SHOULD reject any message with a return 
path that cannot be verified as belonging to the submitting user (we are 
not making this part up, refer to RFC2476) and 2. the user submitting the 
message should make sure that the guest/mobile location is permitted as 
part of the return path domain's policy, because many sites will check 
return path anyway even if Submitter passes (because they don't trust 
Submitter as a forwarder of otherwise-unacceptable return paths.)

One way to satisfy 1. (verification of return path) is to keep a list of 
"alternate addresses" the sender may use, and if the sender wants to add to 
the list, send him a test message at that address and ask the user to 
verify receipt by replying or clicking a link containing a secret cookie. 
(This would be similar to signing up for a mailing list.)  Once the address 
is verified, the sending user may use it as one of his alternate return 
paths.  (The page where you add more "alternate" addresses for your ISP to 
verify is also a good place to explain to the user that he or the owner of 
his other domain should add us as an authorized sender.)

If the forwarder is not implicitly trusted by the receiver, or if the 
conditions 1-2 are not met, then the Submit servers should substitute a 
return path that it CAN verify (like the user's local address instead of 
the remote address).  The user is free to set From: and Reply-To: but the 
Sender: and return path should be either local or verified-remote addresses 
and should be tied to the user by SMTP AUTH or some other method (static 
IP, pop-before-smtp, whatever)

--
Greg Connor <[email-masked]>

---

From: Greg Connor <[email-masked]>
Date: Fri, 08 Oct 2004 23:34:24 -0700

[I removed spf-discuss from the cc: list, since Doug is not a member there 
and his message therefore didn't appear on that list.]

> within the SMTP transaction and steers clear of many complexities.

Doug's reply seems to indicate either a misunderstanding of the main point 
behind SUBMITTER, or else he is trying to commandeer the discussion and 
steer it back to his favorite topic of HELO verification.

I consider it rude to take someone else's hard work and criticize it 
because it doesn't match your own "pet" issue.  But since I don't have 
direct knowledge of Doug's motives here, perhaps it's appropriate to be 
charitable here and assume a misunderstanding rather than intentional 
insult and provocation.  [for now]

> to say only the HELO domain is to be held accountable for any abuses.

Continued discussion of HELO in this context gets us further from the topic 
of the draft itself.  HELO was not mentioned in the draft (other than the 
response to EHLO should contain SUBMITTER in the capability list.)  So, I 
will try to respond to this without mentioning HELO.

I have a pretty fair idea of what "clients that lie about local parts" 
really means.  It means that the domain owner should make sure that any 
SMTP clients he chooses to authorize should check the local part against 
the known/verifiable information for the user (such as SMTP AUTH, static 
IP, pop-before-smtp, etc.)  This prevents one customer of the service 
provider from impersonating other users at the same service provider.

(My previous message describes methods that ISPs might use to verify that 
the localpart being claimed really is owned by the user being 
authenticated.  This is not new -- RFC 2476 says that the submit server 
should verify if the user is really authorized to use that particular 
return path -- William's draft is just applying something similar to the 
submitter address.)

> the role of sender?

No, it clearly would not.  A message should only have one sender, but may 
have multiple submitters on its way to destination, just as it may have 
multiple hops for each submitter.

>In which case, the HELO root name list referenced

Remainder of this paragraph ignored.

> domain as the RFC2822 sending domain.

I disagree with both statements.  The HELO domain clearly cannot play the 
role of SUBMITTER, because SUBMITTER is a mailbox, not a domain name. 
Also, the same mail server may send messages on behalf of multiple 
SUBMITTERS, but would require a RSET to change its HELO name.  Also it is 
pretty clearly not true that the HELO domain will be the same as the 
sending domain, unless we are considering changing the meaning of HELO.

Furthermore, I would point out that Doug's tone has changed here from 
questioning (such as "One possible view" or "Would it not be equivalent") 
to lecturing William and the other listmembers as to why *his* way works 
better.  This makes me believe that this is NOT all just a big 
misunderstanding, and that the behavior of taking someone else's message 
and commandeering it for his own purposes is indeed intentional.

If it is in fact intentional, I would like to point out that it is quite 
rude, and I would go so far as to say that this sort of behavior was one of 
the main stumbling blocks that made MARID fail.  Stubbornly insisting that 
one way is right, even if it doesn't have anything to do with the current 
thread, and even if the idea you are describing is specifically excluded 
from the current discussion, is not valid behavior for a collaborative 
working group.  (I know the WG chairs had a lot on their minds, but perhaps 
they should have been more strict about not allowing such selfish behavior)

> identity.

Further indication that we have moved from "not quite understanding" to 
"disagreeing and lecturing"...

> http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt

Looks like this is the essence of the sales pitch... Doug would prefer us 
not to read William's draft and instead to pay more attention to his own. 
No thanks.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 09 Oct 2004 05:58:47 -0700

> insult and provocation.  [for now]

These were earnest comments aimed at providing a fully comparable result
with few risks and changes to SMTP and with stronger identifications.

> provider from impersonating other users at the same service provider.

Such assurance should not be considered the responsibility of the
mailbox domain owner when the mail channel description is open-ended.
In this case, there is no means to make assurances with respect to these
local parts.  This should not be overlooked, as this open-ended approach
is very much needed to ensure delivery of much of the mail.  Where the
mail channel description has been declared the exclusive source of a
mailbox domain, still this would assume each SMTP client is making mail
channel checks and that each is able to constrain the use of the local
part on behalf the specific domain.  This seems to forgo the nature of
mail being relayed where the mailbox domain owner does not always
control all of these agents.

In the case where the mail channel has been declared the exclusive
source for the mailbox domain and where all the agents are controlled by
the mailbox domain owner, there may be an expectation of the local part
of the RFC2821 MailFrom being protected.  This would be a special case
that should not be assumed by the recipient.  Although the marid-mpr
draft makes the state of mail channel explicit and can also include the
RFC2822 From, SPF does not provide this information, such that no
presumptive expectations of even the mailbox domain itself being
protected is possible.

> multiple hops for each submitter.

The goal of establishing the mail channel by way of submitters can be
equally achieved using a list of authenticated HELO root names
referenced by the RFC2822 From or even the RFC2821 MailFrom as the
message source.  I don't want to lecture why it is bad to use the mail
channel description to serve the dual role of authenticating the SMTP
client. : )

> sending domain, unless we are considering changing the meaning of HELO.

This statement was aimed at the ease of mapping the mail channel in many
cases.   Yes, the HELO domain could change dependent upon the mailbox
domain being relayed, but the reason for doing so would be to properly
establish accountability.  I contend accountability can not be shifted
to a mailbox domain in any other manner.  This name can also be directly
authenticated whereas this is not possible with any other domain within
the mail channel without making assumptions of the mail channel
integrity.

> and commandeering it for his own purposes is indeed intentional.

I had requested previously that William state the broader goals of this
proposal.  This was not to elicit attacks on possible motives, but
rather a discussion of possible alternatives.  What problem does this
suite of proposals solve?  Finding a means to the same end without a
significant impact upon SMTP does not seem like commandeering for
questionable purposes.  I could say the contrary may more aptly apply. 

> they should have been more strict about not allowing such selfish behavior)

The means to the same end was what I considered important in that this
is stating a means to the same goal and my comments are directed to what
I see as serious defects that can be mended.  You seem to have
abstracted something sinister in these comments.  I think being stubborn
would be a way of describing both views it would seem.  Ignoring the
problems does not make them disappear however.  

> "disagreeing and lecturing"...

Care to comment as to why this role would not be stronger with HELO than
other derived names?

> not to read William's draft and instead to pay more attention to his own. 

I am not a salesman making a pitch that could compare to those I have
already heard.  I find it unfortunate this is the typical depth of
consideration given to potential downsides or their possible solutions. 
This is of shared goals but perhaps more focused upon ensuring
accountability is reasonably strong for there to be the possibility of
safely making assessments.

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Sun, 10 Oct 2004 09:18:54 -0400

Douglas Otis <[email-masked]> wrote:
> abstracted something sinister in these comments.

  Everyone knows you prefer EHLO checking, and why.  If you see flaws
in a proposal, then it would be preferred to discuss those flaws, and
only those flaws, in any thread centered around that proposal.  Any
reference to another method would be best left to one sentence, and a
reference URL to an I-D proposal.

  When a thread is about topic X, and you spend a significant part of
a message talking about topic Y, others can view that as trying to
change the topic of conversation.  Changing topics in the middle of a
thread usually warrants a change of subject line.

> I think being stubborn would be a way of describing both views it
> would seem.

  I have seen people on this list discuss EHLO checking in threads
with you.  Other threads you join (like this one), which are on other
topics, often end in discussing EHLO checks, with the same subject
line.  This can be viewed as thread hijacking.

>  Ignoring the problems does not make them disappear however.

  Accusing others of ignoring a problem because they don't like thread
hijacking is missing the point.

  If a proposal has flaws, then the proof of those flaws doesn't need
to include discussions of EHLO checking.  Leave it out of the
discussion, spend time talking about the flaws, and you're less likely
to get accused of having sinister intent.

  Alan DeKok.

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 10 Oct 2004 12:47:49 -0400

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?

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

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.

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

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.

4) Finally, to support SUBMITTER, any client machine domain authentication
can not be violated.

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.

Hope this helps

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Douglas Otis <[email-masked]>
Date: Sun, 10 Oct 2004 14:09:34 -0700

> thread usually warrants a change of subject line.

There was about a draft submitted as indicated by the subject line.  I
read this draft and made comments directed at problems seen with the
reasoning proffered to support of these substantial changes.  I
described the problem and offered a context to describe solutions. 

This was reviewing 18 lines of draft text with 36 lines of comments
largely constrained to offering alternatives for the names attempted to
be passed by Submitter.  To understand the basis for Submitter seems to
require reviewing the elemental goals, and how they can be safely
achieved.  These statements were to elicit a discussion on these basics.
> line.  This can be viewed as thread hijacking.

This misses the points being made by suggesting this was about HELO
domain name checks.  An allowance for an open comparison of related
problems and solutions for these problems is appropriate.  Comments
regarding suspected motives is inappropriate and do not dismiss the
substance of these concerns.  I have no desire for forums that ignore
grave problems.  This forum, if earnest in endeavor, should address,
support, defend, or explain the basis for critical decisions.

> hijacking is missing the point.

The topic Re: I-D ACTION:draft-leibzon-responsible-submitter-00.txt 
seems to be the ideal thread for comments related to concerns regarding
the text of this draft and the stated aims.  

> to include discussions of EHLO checking.

This was not about EHLO checking.  In fact, it has little to do with
EHLO checking.  It was about using a name list rather than an address
list to overcome problems related to knowing when the list is open,
dealing with the problems of an open list, enabling stronger preventions
of spoofing and phishing, and establishing fair accountability for
discovered abuse.  When done properly, this removes the need for the
entire Submitter proposal!

Going into lecture mode, a name list rather than an address list solves
many problems that place mail and DNS at serious risk as with SPF or
Sender-ID.  When implemented with a name list, this still allows
tracking the sender by either the the From, or the MailFrom and largely
makes the PRA algorithm unneeded, but still possible.   

>   Leave it out of the discussion, spend time talking about the flaws,
> and you're less likely to get accused of having sinister intent.

I will be happy to limit discussion to specific areas, provided this
does not artificially exclude valid solutions.  Offering a solution to a
problem also dismisses a view this problem is just a burden that must be
endured as a cost for change.  The goals for MARID were reasonable and
there are possible solutions.  SPF or Sender-ID/Submitter, as currently
structured, are not reasonable solutions.

Thank you for your advise.  I know I must remain guarded. 

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 10 Oct 2004 15:32:31 -0700 (PDT)

> scrutinizing people's input, publicly ostracizing them, why should

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).
 
> 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.
 
> 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.

> original domain is no longer responsible.
Clearly this is so.

> implied in the spec, it needs clarification.

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

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.

> 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-masked]/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-masked]
Anti-Spam and Email Security Research Worksite:
 http://www.elan.net/~william/emailsecurity/

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 11 Oct 2004 10:10:17 -0400

Douglas Otis <[email-masked]> wrote:
> read this draft and made comments ...

  My message was clear that everyone understood you did that.  The
problem was when you appeared to be doing more.

>> [ EHLO && thread hijacking ]
>
> problems and solutions for these problems is appropriate.

  Then start a new thread which is intended to talk about open
comparisons.

> Comments regarding suspected motives is inappropriate and do not
> dismiss the substance of these concerns.

  There was no attempt to dismiss the substance of your concerns.
There were attempts to get you to realize that threads allegedly about
a topic should remain on that topic, or should change the subject
line.  (As has been done here)

>  This forum, if earnest in endeavor, should address, support,
> defend, or explain the basis for critical decisions.

  This can be done without turning any topic to EHLO checking.

> Thank you for your advise.  I know I must remain guarded. 

  I do not ask you to remain guarded.  I ask you to expose any and all
flaws in proposals.  This exposure does not require repeated
statements as to the benefits of other proposals.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Oct 2004 15:09:50 -0700

On Sun, 2004-10-10 at 15:32, william(at)elan.net wrote:
> This will be addressed and clarified. 
>  

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