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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 7 Aug 2006 09:39:35 -0700

> [mailto:[email-masked]] On Behalf Of Michael Thomas

> >Even then,  the main issue are the potential damages that 
> are being ignored.
> >My wife said it best when asked why even the BIG companies like 
> >WALMART, YAHOO, CISCO,  AOL.COM,  BIGBANK should also 
> support strong policies:
> >  
> >
> I can say with little hesitation that Cisco will never 
> publish the "strong"
> policy as envisioned by Mark for our user population. I'd be 
> interested to hear from Mark whether Yahoo-inc ever would for 
> their corporate users.

This is an irrational concern. 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.

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

I don't see this being the case. Five years ago there were people who wrote mail filters that were insensitive to false positives. That is not a problem today.

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.

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. 

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

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.

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.

It is not even necessary to have a different domain.

[email-masked] could become [email-masked]

You can even add in a MAC valudation code:  [email-masked]

Put a command in the client that automatically performs the mailing list subscription in the manner I suggested.

This problem is fixable, strong policy is entirely practical.

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

---

From: Damon <[email-masked]>
Date: Mon, 7 Aug 2006 13:10:31 -0400

> 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 alrea…

Speaking as a real live, currently employed, sysadmin (numbers bigger
than all the scientists in the entire world put together --- just
kidding with you Phillip)... "Yikes!"
Do I need a separate email for when I am living out of a suitcase for
6 months at Holiday Inn too? (I know I can use the same one as my
mailing list address) Now the guy I emailed is using that address in
his address book. Note to self, email him and get him to change it.
Can we figure something else out that doesn't require me (or my 200k+)
users to have to remember two separate addresses, the cases to use
each, and remember what the second one is the first time they have to
use it in 5 years?

Regards,
Damon Sauer

---

From: <[email-masked]>
Date: Mon, 7 Aug 2006 13:30:18 -0400

Damon

"Can we figure something else out that doesn't require me (or my 200k+)
users to have to remember two separate addresses, the cases to use
each, and remember what the second one is the first time they have to
use it in 5 years?"

as a sysadmin, lock out pop access and make them use web enabled mail

thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Damon
Sent: Monday, August 07, 2006 1:11 PM
To: Hallam-Baker, Phillip
Cc: [email-masked]; [email-masked]
Subject: Re: [ietf-dkim] How to reconcile passive vs active?

> 4) Signature fails to validate because of an intermediary acting for
the recipient (mailing list, forwarder, etc.).
> 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.

Regards,
Damon Sauer

---

From: Damon <[email-masked]>
Date: Mon, 7 Aug 2006 13:39:54 -0400

> as a sysadmin, lock out pop access and make them use web enabled mail

Sorry... we are a Notes shop. Might be a little easier if it were
another "shall not be named here" box but then would have to deal with
all those pesky persistance issues and other things. *sigh*

Regards,
Damon Sauer

---

From: Arvel Hathcock <[email-masked]>
Date: Mon, 07 Aug 2006 12:48:48 -0500

> 6 months at Holiday Inn too?

Sorry but, honestly, is this still a big problem in today's world?  We 
solved this long again didn't we?  Who is using the hotel's email system 
who can not also get to their corporate email either via VPN or a web 
mail interface?  At worst case, if the hotel is blocking port 25 tell 
your employees to use the MSA port or some other corporately assigned 
port.  Any mail server software these days would support any or all of 
those options.  I'm sure I'm missing something.

-- 
Arvel

---

From: Damon <[email-masked]>
Date: Mon, 7 Aug 2006 14:06:45 -0400

> those options.  I'm sure I'm missing something.

Just trying to cover all the bases.

Damon Sauer

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Aug 2006 11:17:52 -0700

> mail interface? 

Using a back-haul link to the organization's server certainly does cover many
cases of remote access (home, travel, etc.).

However it does not cover all.

Counter examples include:  Kiosk access and access through some PDAs. They often
require relying on a Submissions Agent under control of the local access
operator, not the user's organization.

We need to acknowledge this and deal with it.

Whether dealing with it means saying "we don't handle that case" or defining how
things DO work with those scenarios, is a matter for group creativity and
consensus.

But please let's not make the same mistake as the path registration folks, and
pretend these cases are not important.

My own thoughts on how to deal with it:

1.  Document the back-haul scenarios that make this a non-problem.

2.  Handle the cases in which it *is* a problem, such as by describing how to
use different d= names to distinguish stable, organization-based mail from mail
sent by (possibly mobile) individuals.  We need to remember that d= creates the
ability to have different sub-domains for DKIM than show up in the rfc2822.From
field.

Thoughts?

d/

-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 7 Aug 2006 11:20:48 -0700

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  

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

> 4) Signature fails to validate because of an intermediary acting  
> for the recipient (mailing list, forwarder, etc.).
>
>
> 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

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 7 Aug 2006 14:45:51 -0400

> > who can not also get to their corporate email either via VPN or a web

Or through port 465 or 587 (depending on your choice of MUA and SSL or TLS).
>
> Using a back-haul link to the organization's server certainly does cover
> many cases of remote access (home, travel, etc.).
>
> Counter examples include:  Kiosk access and access through some PDAs. They
> often require relying on a Submissions Agent under control of the local
> access operator, not the user's organization.

You can't prevent mail from being sent from anywhere on the internet without 
preventing mail from being sent anywhere from the internet.  It's as simple 
as that.

> Whether dealing with it means saying "we don't handle that case" or
> defining how things DO work with those scenarios, is a matter for group
> creativity and consensus.
>
In the restrictive policy case we are discussing, this is a feature, not a 
bug.

> But please let's not make the same mistake as the path registration folks,
> and pretend these cases are not important.
>
They are important, but part of the tradeoff.  In this case the tradeoffs are 
different than those with path registration techniques.  Their importance 
will be different.  We need to explain the tradeoff and that's about all we 
can do.  Sending domains will need to decide what's best for them and their 
user base.

> 1.  Document the back-haul scenarios that make this a non-problem.
This will be necessary.

> 2.  Handle the cases in which it *is* a problem, such as by describing how
> to use different d= names to distinguish stable, organization-based mail
> from mail sent by (possibly mobile) individuals.  We need to remember that
> d= creates the ability to have different sub-domains for DKIM than show up
> in the rfc2822.From field.
>
Policy is (in the drafts published so far) keyed off of From.  If you key it 
off of the signing domain instead, you've very nicely defeated the entire 
point of the exercise.

If I'm standing at a kiosk, how do I have any control over how a message sent 
through that kiosk gets signed?  I don't think I do.

Once again, restricting the legitimate sources of messages from a domain is 
the goal of the restrictive policy.  This is a feature.  We need to be clear 
about what the likely impacts are, but we don't need to feel bad that there 
are restrictions.

Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 7 Aug 2006 19:16:49 -0400

----- Original Message -----
From: "Scott Kitterman" <[email-masked]>

> If I'm standing at a kiosk, how do I have any control over how
> a message sent through that kiosk gets signed?  I don't think I do.

I see several things:

If you going to use an email address via this kiosk,  you should make sure
your SSP record says

        "optional signing by my domain."    or
        "3rd party signatures allowed (with no list)"

You are using a "neutral device", therefore you really should not be using
restrictive policies.

On the flipside, if I had a restrictive policy, I would not want someone
using my email address from a Kiosk machine in an open-ended manner.  At the
very least I am taking an proactive measure to help protect my domain from
possible external abuse.

Also, assuming the kiosk vendor is ambitious and adds DKIM-SSP v1.0 software
support, it would do the following:

1) Add support to check for restrictive policies that an user may use.   If
the address is found restrictive, i.e. the kiosk is not able to sign on the
user's domain behalf,  then it will immediate popup a message:

            Sorry, this email address is DKIM protected.
            Use another email address.

2) It will add a checkbox to the header input form:

        From: ____________________
        To:  ____________________
        Subject:  ____________________
        [_] Sign message using Mr. Kiosk DKIM Service (*)
              * Adds $1.99 surcharge.

SSP is the Bomb!!! <g>

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com