[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  
authenticated.
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.
<rant>
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  
very dark.)
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  
phished.
</rant>

> 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.
-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html