Subject: Submitter shown the DOR

From: Douglas Otis <[email-masked]>
Date: Tue, 13 Jul 2004 18:09:02 -0700

In Monday's Jabber session, in the few minutes spent reviewing
Sender-ID, there was a statement made a new name may need to be created.
I had a few questions regarding Sender-ID I hoped to broach before the
topic was changed to CSV or should I say "How CSV is different from SPF
et al" that lasted two hours."  I must say, that I found such attention
remarkable. Morph lives. :^)

Submitter 01 Draft Quotes:

4.2 Processing the SUBMITTER Parameter
...
   Verifying MTAs are strongly urged to validate the SUBMITTER parameter
   against the RFC 2822 headers; otherwise, an attacker can trivially
   defeat the algorithm.

Sender-ID states in the Security Considerations:

   This extension offers no protection against a user in one domain
   spoofing another user within the same domain.

Example of a Domain of Responsibility Tag:

C: MAIL FROM:<[email-masked]>
     DOR:t:"ddddd.dddddd";x:"ddddd";a:"ttttt";
     s:"tttttttt";
     b:"tttttttttttttttttttttttttttttttttttt";
     d:"alumni.almamater.edu";
   
(a:algorithm,
 t:time-stamp,
 x:expiry,
 b:base64 signature,
 s:selector,
 d:domain)
 
Submitter adds another mailbox within the RFC 2821 parameters. The user
may not wish to expose this additional mailbox, however, and it would be
remarkable if the user was aware of specific mail infrastructure to make
such assertions in a responsible manner.  In this vein, the draft allows
the MUA to issue this information outside the SMTP server's
authentication of the client?  The goal of protecting return addresses
is thwarted if a Resent-Sender header and a matching Submitter header is
added to a message intended to continue spoofing the return address,
where this obscures the path of the message.  In other words, the return
address continues to be spoofed through permissions provided by this new
mailbox.  In addition, this new mailbox then requires yet another
accreditation, while yet the insecure pathway in need of repair to abate
a problem remains obscured. :^0

There are strong methods for commerce to ensure messages have been
received from the indicated domains.  As example, the following proposal
shows how a DNS based domain key can be used to sign the entire message.

http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-00.txt

Could such a method be used to ensure the Submitter information is not
forged?  Yes, absolutely. :^)

Change the name of Submitter to Domain of Responsibility (DOR).  This
would be the domain that authenticated the SMTP client for forwarding
rather than direct submission.  The DOR tag would be the method this
server accepts responsibility by signing the adjoining MAIL FROM
statement with a time stamp and its own domain as a statement of having
authenticated the SMTP client.  The DOR tag then locates the source of
abuse should there be a problem later uncovered with the message without
exposing more information about the user than needed.  This method would
help large ISPs ensure accreditation is properly assigned to their
customers operating different domains as well. :^)

Examples of signing individual headers is provided in:
http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-00.txt

Just as the Submitter proposal does not directly involve DNS, none of
these proposals are directly associated with DNS, so a full discussion
should involve a greater audience it would seem.  

Implications of Submitter tags:  

If Big-Bank.com left their outbound SMTP server lists "open", then they
hope to ensure only communications directly from their mail servers
would have the "Checked for Big-Bank.com" marking. (Assuming the
customer's local ISP mail infrastructure is secure.)  If Big-Bank.com
"closed" their list, they then must vouch for the integrity of servers
used by their sub-contractors.  This may place Big-Bank.com in an
unpleasant situation.  Either have their clients see mail arrive
"Unchecked for Big-Bank.com", or "Checked for Ads-R-Us.com" or risk
trusting their subcontractors to ensure the security of these systems. 
Can you see the finger pointing? :^(

Big-Bank.com should expect those wishing to spoof their return address
to use similar domains allowed by the Submitter alternative address that
may not be fully understood by their customers.  The submitter address
could be Big-Bank.info as example, where the return address remains the
address their customers expect to see, such as [email-masked]. 
The bad news would be that if Big-Bank.com did not "close" their lists
and accept responsibility for their sub-contractors, those spoofing
their address would have the spoofed address indicated as "Checked for
Big-Bank.info" appear more convincing than their bulk ads marked as
"Unchecked for Big-Bank.com" or "Checked for Ads-R-Us.com".  For that
matter, if the lists were left "open", spoofing would continue, looking
as mail being sent through their subcontractors.  Confusing?

Not to overlook the likelihood that channel checks for this information
will not function when attacked, where these checks then become
removed.  This leaves Big-Bank.com customers to be informed not to trust
any information appearing as originating from Big-Bank.com even if their
customer's mail program indicates "Checked for Big-Bank.com".

If the goal is to stop abuse, then the DOR tag rather than the Submitter
tags provides the same function, but would never be emitted by the MUA, 
nor would it expose more user information.  The DOR tag can withstand
channel checks being disabled.  If there is abuse, the DOR tag would
allow authorities to find the door of the entity causing the problem. 
The Submitter tag allows abusers to continue to hide in the muck and
mire of often open or unscaleable lists demanded in an effort to publish
all SMTP clients used for all domains authorized to originate mail on
behalf of a domain.  

Moving closer to the source of the problem helps close the door on
abuse.  The DOR tag will allow an accurate post delivery assessment as
to the source of the problem and enable accurate accreditation of
domains and their policies.

-Doug

---

From: Tony Finch <[email-masked]>
Date: Wed, 14 Jul 2004 10:53:48 +0100

>      d:"alumni.almamater.edu";

Why not just get the originator's MSA to sign the original return path?
This gives end-to-end authentication of the MSA, does not require any
change to aliasing/forwarding systems or to SMTP, and works well with
callback verification.

Dave Crocker's BTAV draft is a start at a specification.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
CAPE WRATH TO RATTRAY HEAD INCLUDING ORKNEY: WEST OR NORTHWEST 3 OR 4 BACKING
SOUTHEAST, THEN VEERING WEST 4 OR 5 LOCALLY 6 ON WEDNESDAY. PATCHY RAIN AND
PERHAPS LOCAL MIST CLEARING TO SCATTERED SHOWERS ON WEDNESDAY. MODERATE OR
GOOD, BUT PERHAPS LOCALLY POOR IN MIST FOR A TIME. MODERATE IN NORTH BUT
SLIGHT IN SOUTH.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Jul 2004 12:10:00 -0700

> Dave Crocker's BTAV draft is a start at a specification.

http://www.brandenburg.com/specifications/draft-crocker-marid-batv-00-06dc.html

You are right, this could be used in the same manner as the BATV draft
presented at the interim meeting, if done at the entry point into the
channel, where the MUA has been authenticated by the SMTP server.  This
also has the advantage of being recognizable by the recipient of the
mail, prior to bouncing if detecting fraudulent mail and discarding it,
without slogging through the dozen or so DNS text records to decide
whether the message is a member of a set.  DOR (of access) works without
changing the way mail works nor does it require channel checks. :^)

I suggested down stream to use the SPF algorithm.  On considering the
advantages, it would be better to do this as Dave Crocker had structured
it.  I doubt DNS can scale to allow the SPF algorithm to be "closed" as
needed to abate spam and fraud.  With the submitter mailbox being
assigned by the MUA, as done with the Submitter proposal, this simply
allows fraud to continue unabated with publicly published records
allowing points of access for fraud.  It also allows deny-ability, as
anyone could become victim of fraud, both the recipient of the mail as
well as the records used to allow the fraudulent mail to be delivered,
because of Sender-ID allowably broad definitions.

With the DOR scheme, the bounce could be avoided where it saves
bandwidth as well as preventing fraud from otherwise reputable domains. 
There would also be a verifiable domain to handle abuse where this
domain is able to associate the local account with the abusive mail. 
This is much more information than that obtainable from Sender-ID which
leaves the authenticating domain indeterminate.  Sender-ID would leave
open the question as to how any abuse is to be abated or how rules are
to be enforced. Sender-ID does not permit accrediting abuse from an open
list or a broadly defined region of address space.  Because Sender-ID
can be so broadly defined, enforcement would be virtually impossible. 
The DOR tag can close the door or else a bad accreditation results. :^)

-Doug  

-Doug