ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Issue: Deployment Guide Section 6.1/6.5 (ADSP/Forwader) conflict

2009-10-20 01:22:50
John Levine wrote:

What is ironic about all this DKIM forwarding issue is the same issue
that SPF forwarding had.  This was one of the marketing advantages of
DKIM - that it didn't have a forwarding problem.

Well, it does. ...

It's also possible -- we'll have to see what happens -- that mailing
lists could change their behaviour to take better advantage of DKIM
(with the specs that are already published).  That's not an option
they had with SPF.

The sensible way for lists to change their behavior is to SIGN THE
MAIL THEY SEND. 

People apparently seem to have trouble distinguishing between mail Bob
sent directly to you, and mail that Bob sent to a list which decorated
his message and then passed along to you.  DKIM makes that easy to
handle -- when the list signs its mail, you can reliably tell that no
matter what's on the From line, this message is from the list so you
can do whatever you do with list mail without having to worry about
who sent it to the list in the first place, just like you do now.


John,

I don't think there is an issue with the little angel sitting on the 
left side of the shoulder, but the little devil that is sitting on the 
right.

Unless there is suggestion that we have some List-ID whitelist 
inclusion concept or some other reputation concept, in lieu of this, 
we are not protecting domains from the little devil.

A mechanism that claims to protect one side, needs to cover the other 
side as well.  The Remailer needs to consider the BAD side is the DKIM 
  coin.

It is not enough for receivers to see 3rd signatures that has good 
information about, but what the receiver does not get about them.

Again, there are two parts to the implementation that makes it 
prohibitive to adopt:

   1) Receivers
   2) Receivers/Remailers

The receivers can filter the ADSP based 3rd party signature violations.

At the #1 receiver it is final destination. There is no forwarding to 
occur.  No issue here, and there is no issue with #1 not supporting 
ADSP.

The same is true with the #2 receiver component.

However, when it comes to the #2 remailers, it becomes more sensitive. 
    It can no longer ignore the ADSP protected domain allowed in by #2 
Receiver regardless if #2 receivers supported ADSP or not.

I know what we can do to our #2 Remailer:

   1) Common to all or most list systems.

      The submission user has to be a member, if not, its not
      processed.

   2) Filter ADSP domains, do not process it.

PRO:

   - Spoofed member domain submissions are protected

   - No membership downlink reject problems.

   - No membership threat of subscription removal.

CON:

   - Member Domains that mistakenly use a restricted
     policy are filtered.

If remailers do not honor ADSP, you can effectively swap the PROs and 
the CONs:

PRO:

   - Member Domains that mistakenly used a restricted
     policy are ALLOW to be submitted.

CON:

   - Spoofed member domain submissions are no longer protected

   - Membership downlinks create reject problem.

   - Membership threat of subscription removal.


I do not think that is just pure speculation. But software engineering 
  intuition and foresight.

--
HLS
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>