ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Last Call: <draft-ietf-dkim-mailinglists-10.txt> (DKIM And Mailing Lists) to BCP

2011-05-13 18:20:54
Hector Santos wrote:

Nothing wrong with DKIM=DISCARDABLE.  What is wrong is trying to 
dictate to others MLM should ignore ADSP.

As a MLM vendor, I have technical and ethical engineering obligation 
not to cause problems when taking on a new inherently incompatible 
technology that doesn't naturally fit with a MLM.

Hence, there are two general solutions for the MLM:

    MLM-LEVINE: Ignore all DKIM ADSP restrictive policies
    MLM-SANTOS: Preempt all DKIM ADSP restrictive policies

I know as a matter of fact MLM-SANTOS is a better DKIM mail 
integration fit because we implemented it.

Keep in mind that I recognize MLM-LEVINE solution but that is based on 
ignoring all originating DKIM information - pass, fail or unknown. 
The theory is based on:

   A) The Member is already authorized based on being a list member
      already,  CONCUR

   B) No expectation of getting fraud submissions, and if so, a
      negligible amount, CONCUR

   C) Ignorance for DKIM failure promoting a relaxed atmosphere of
      DKIM unknown signer mail, OBJECT.

   D) Trust the single signer domain at the SYSTEM LEVEL (global), OBJECT.

Assuming this MLM-LEVINE is the acceptable solution, then the 
optimized, lower overhead receiver operation is to first check to see 
if the signer(s) are known before even trying to verify any signature.

What I had proposed is method (rule) at the DATA filter:

   if message fails ADSP and has a LIST-ID,
      then respond 250 and discard the message

   if message fails ADSP and has no LIST-ID,
      then reject with 55x

Note, by fails ADSP, it is presumed the policy is DKIM=DISCARDABLE

To complete the logic for always accept systems:

    if message fails ADSP then discard the message

You got to understand there is a split of how systems operate; many 
systems for scalability reasons, especially in earlier days, always 
accepted the message and then applies any mail filters.  As hardware 
and software (multi-threaded OSes) improved, and also to address the 
bounce problem, more systems began to do more dynamic rejections at 
the DATA level.  The technical responsibility to issues bounces is 
very strong.  The idea of discarding was largely frown upon.

This multi-decade BOUNCE requirement mindset, which touches base with 
1986 US EPCA provisions for avoid censorship claims, has changed for 
the first time in RFC5321 with new semantics that recognizes the 
contemporary needs to "drop mail" when reasonable non-frivolous new 
considerations are appropriate.  I pushed for this recognition known 
new technology like Sender-ID and ADSP was on the horizon.

In short, Levine did a good thing by technically "legalizing" 
discarding of mail.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


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

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