[ietf-dkim] How to reconcile passive vs active?

[Douglas Otis]

On Aug 7, 2006, at 9:39 AM, Hallam-Baker, Phillip wrote:

> Cisco is not a typical email user, it is not currently a target of  
> the type of attack that would make one want to publish strong policy.

Mike is correct to suggest that Cisco represent a typical domain  
sending and receiving email.  The domains wanting to make an  
assertion that secondary services such as "mailing-lists are never  
used" are likely limited to the relatively few domains subject to  
spoofing attacks.

> A more rational concern would be that you think you will be  
> required to deploy strong policy and that it will have bad effects.

It would be dangerous to limit a policy assertion so narrowly.  There  
should be at least two possible assertions.  "All messages pertaining  
to this policy are signed, with the possible exception of common  
email related services" and "All messages pertaining to this policy  
are signed without exception".  The first policy represents an  
expectation that sources known to provide these services will carry  
messages that may not retain a valid signature.  This first policy  
reduces the range of valid sources and allows the listing of related  
domains while also incurring fewer delivery issues.


> The reason that I expect people to implement reporting, fix the  
> mailing lists and all the other infrastructure that will eventually  
> make even Cisco want to publish strong policy is that doing so will  
> help reduce administration costs and false positives.

Publishing a reporting email-address does not seem to offer any  
significant advantage over an adopted convention.


> I would much rather put up a response server to provide feedback  
> than have people contact me to tell them I am blocking good mail.

Are you suggesting two types of reporting addresses?

being-blocked@
"Your site is blocking our messages to recipients that have  
specifically requested this information. Continued blocking will  
greatly harm our enterprise."

been-blocked@
"Your site is being blocked due to a high percentage of your messages  
representing unsolicited bulk email."


> I would much rather authenticate my mail than have it mistaken for  
> spam.

There is also a desire to void complaints that email is not being  
delivered for invalid reasons.


> There are four possibilities for a legit mail sent with  
> authentication.
>
> 1) Signature Validates:
> 2) Signature fails to validate because the originator screwed up
> 3) Signature fails to validate because the sender screwed up
> 4) Signature fails to validate because of an intermediary acting  
> for the recipient (mailing list, forwarder, etc.).
>
>
> The first case is success, the second and third cases are self  
> healling.
>
> Its only the fourth case that leads to an issue and it is easy for  
> Cisco to fix. They simply issue a separate email address for  
> receiving mail from mailing lists. Many of them seem to do this  
> already. I note that Michael is one of them.

There is still value in a domain assuring that all messages are being  
signed.  This policy assertion should accommodate a stipulation  
regarding the use of non-complaint services.  An assertion that a  
particular domain signs all message and uses non-complaint services  
reduces the amount of blocking this may otherwise permit, but is also  
be less likely to cause delivery failures.


> Worst case is that everyone has to resubscribe to mailing lists  
> that are habitual manglers of signatures in a way that is  
> incompatible with people's mail service using a different address  
> that works.

Allowing the stipulation regarding the types of services used,   
messages without the expected signature might cause the source to be  
evaluated on the basis of being a "provider of non-complaint  
services."  It may take years, if not decades, for a separate  
category of evaluation not to be needed.  The "All messages  
pertaining to this policy are signed, with the possible exception of  
common email related services" offers significant value over not  
being able to add _any_ additional constraints when evaluating the  
source.

-Doug