On Thu, Apr 13, 2006 at 11:40:21PM +0000, Mark Delany allegedly wrote:
On Thu, Apr 13, 2006 at 07:10:06PM -0400, Bill(_dot_)Oxley(_at_)cox(_dot_)com
allegedly wrote:
Jim,
So if they use our mta's The signatures would in fact be from cox.com as
Correct. By signing as cox.com you are accepting responsibility for
Well, that's the short version. The long version is that there are
lots of options.
If we start with the presumption that you're talking about a customer
who has their own domain, the range of options are:
1. Do nothing - assume they will or will not sign as they see
fit. Your SUBMIT server merely relays the mail closer to the
destination.
2. Detect whether the submitted email is signed and only sign with
your domain if there is no verifiable signature. As mentioned
before, this means that your domain accepts responsibility for the
email rather than your customer's domain.
3. Arbitrarily sign with your domain. If the submitter has also
signed, this delves into the multiple signature issue which as does
not yet have semantic clarity from this group. As with 2. your
domain is considered responsible for the traffic.
4. If you offer a managed service - that is, you host their DNS,
perhaps host their MX, etc. - you could also offer the service of
signing for their domain since you can generate and add the
Selector to their DNS. To my mind this is the best service model.
Clearly you'd want to authenticate their submissions, but how you
do that is a matter between you and your customer.
5. If the customer trusts you, they might supply a private key to
match a Selector so that you can sign the submissions on their
behalf.
Mark.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html