[ietf-dkim] Re: Mailing lists as 2822-Sender
On Dec 1, 2007, at 1:11 PM, Frank Ellermann wrote:
John Levine wrote on the DKIM list:
This has nothing to do with DKIM, Sender-ID, or anything other than
RFCs 2822 and 822.
Doug's SSP-TPA is related to DKIM and I think it mentions the PRA.
SSP-TPA can deal with PRA related headers, but only because headers
other than From may also represent who originated the message.
The SSP-TPA draft provides a means to assert scope. Scope is broken
down into three areas:
1) From originating header (Normal SSP scope)
2) Other than From originating headers (Sender, and Resent-*)
For example, a mailing list might wish to assert identities associated
with email-addresses within the Sender header are "authenticated".
The current DKIM base specification prevents i= semantics from being
able to make this assertion.
3) TPA-SSP also provides a MAILFROM policy assertion that might be
used when issuing a DSN.
Currently, there is the F-i, O-i, and M-i assertions. From feedback
on the list, perhaps F-a, O-a, and M-a, could be added, where the i=
identity would then track the account gaining access, rather than
indicating an identity associated with an email-address found in an
originating header (Originating with a small 'o') has been
In addition to ensuring a mistake is not made regarding an assumption
of authentication or uniqueness, being able to express scope better
defends a DKIM validation process.
Levels of abuse are doubling at an interval far less than that for
hardware's performance doubling. Several product lines have been
dropped when coping with abuse was not economically practical. In
addition, detecting obfuscation techniques also demands a steep
increase in resources. (The sky is not falling, but the horizon looks
Source reputation may be a means to deal with this growing abuse
problem. Unfortunately, a rising percentage of abuse is being sent
through large provider's outbound MTAs.
Users being blocked by their own provider confronts a conflict of
interest. Often the provider's desire is to reduce operational costs
and minimize support efforts. When the large provider is completely
blocked by receiving domains, a sizeable support cost will be created
for both transmitting and receiving domains due to a resulting high
level of collateral blocking. When users are blocked individually by
many receiving domains, the user just might understand the problem to
be theirs. This understanding could be reinforced when many different
failure notifications clearly indicate their account has earned a bad
reputation. When these users contact those blocking them, support
costs will also be distributed, often to those in the business of
blocking abusive sources.
DKIM might allow such a clear user notification when SSP or TPA-SSP
records include a scope parameter.
DKIM could help solve the large domain abuse problem in a way that
justifies resources needed to validate DKIM signatures. Without an
ability for the receiver to resolve problems at a smaller granularity
than the domain, issues related to bots and replay abuse will likely
cause DKIM validation to be bypassed for all but those domains being
RFC 4406 requires to violate the quoted 2821(bis) MUSTard for its
purposes, it even got an IESG note about the fact. And (2)822(upd)
doesn't mention mailing lists explicitly. Now is a good time to get
this right, as my attempt to switch to the rfc822 list failed, I now
try the smtp list, it's a potential bug in 2821bis.
The conflict appears to be in RFC4406 section 7.2 regarding
recommendations to inject Resent-From or Sender headers when forwarding.
While Sender-ID has created problems for mailing-lists, forwarding
also causes problems. Resolving all addresses used by a domain makes
abuse less tractable, in addition to placing DNS itself in peril. If
email ever embraces IPv6, this would double the related overhead and
risk related to IP address path registration.
It this weren't such a rate-hole, TPA-SSP records could include scope
assertions declaring DKIM's relationships to SMTP clients, and whether
all outbound messages are always signed by the domain's SMTP clients.
SMTP client assertions would provide a far safer alternative to IP
address path registrations.
NOTE WELL: This list operates according to