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:<alice(_at_)example(_dot_)com>
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
accounts(_at_)big-bank(_dot_)com(_dot_)
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