On Monday 07 August 2006 14:17, Dave Crocker wrote:
Do I need a separate email for when I am living out of a suitcase for
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?
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.).
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.
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.
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.
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.
My own thoughts on how to deal with it:
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html