On Nov 24, 2006, at 8:47 AM, Michael Thomas wrote:
Stephen Farrell wrote:
Frank Ellermann wrote:
As they SHOULD NOT be used on _irregular_ mailing lists. Maybe
more cases, we should ask the 'lemonade' folks what they think
about this "I (defined by 2822-From) sign everything DKIM-
complete" construct.
Good idea. Do you know who to ask? If so, do so!
Can somebody explain to me what an "irregular" mailing list is?
s/irregular/typical/
I'm afraid that some people have a more "composed" idea of SSP than
I do. I think of SSP being two distinct things:
1) An information service provided by a domain which describes
what it does as mail passes through its infrastructure
2) A mechanism for finding and fetching information provided by the
service in (1).
I know that we've been talking about rfc2822.from alone with
respect to 2 primarily, and that we've been pretty vague about
whether the information service in (1) has anything to do with any
other address header. I'm not convinced that that's right though:
our signer at Cisco by policy always signs messages which
correspond to a From: or Sender: or Listid. If SSP is just an
information service, wouldn't it be better to just describe what we
do? There seems to be no particular harm in publishing what is just
a fact.
Provided value is obtained, yes. Rather than just potentially
disruptive assertions that "all" messages of a particular header
should be signed (which breaks many normal uses of email),
associating a signing-domain with more than just email-addresses
found in headers should also be included.
1) Whether a signing domain is associated with SMTP client. When the
signing domain is used for white-listing messages, the value is
avoiding possible replay abuse.
2) Knowing whether the signing-domain is associated with the
MailFrom. The value is ensuring return of DSNs.
3) Associate email-address domains with the signing-domain. The
value would be elimination of sharing private-keys, DNS delegation,
or CNAMEs at the selectors following special arrangements with email-
address domain owners with their providers. (Overcomes unscalable
administrative overhead.)
Whether a receiver wants to find/fetch information related to
addresses is its business alone. We've envisioned From as being the
Most interesting one, but it's not clear that that's _always_ the
case, and we certainly can't prevent a receiver from having an
"unapproved" opinion about which addresses it's interested in.
When delivery integrity is improved, there is greater choice for the
domain owner, better abuse oversight for transmitting entities, and
administrative overhead reductions for both the domain owner and the
provider, these association options should not be excluded from
careful consideration.
Long and short, my feeling is: SSP publish what it actually does;
describe the mechanism for looking up anything based on a rfc2822
address, and just give some non-normative guidance about which
addresses might be interesting. Note also: phrasing things this way
avoids the tar pit of claims that we're "solving phishing", etc.
The only reason for limiting assertions to the From header is to
support a false claims about anti-phishing protection. Assessments
regarding reduction in abuse often overlook adaptation by the bad
actors, and how such a strategy ultimately reduces the integrity of
email delivery, increases susceptibility to spoofing, and creates DNS
traffic where perhaps only very small percentage might have value,
even assuming sweeping adoption by receiving entities.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
