ietf-dkim
[Top] [All Lists]

[ietf-dkim] Responsible SSP usage

2006-08-17 22:46:43
Just small point here, if it wasn't obvious:

The possible arrangement we have in this scenario is:

    COMPANY.COM     ---->
        |
        |                  ISP.COM  ---> 3P signed mail
        V
    MAILINGLIST.COM ---->

Where the domains company.com and mailinglist.com both have their ISP
signing on their behalf as a 3rd party.  Both have delegated the ISP in
thier SSP policy, and company.com is also a subscribed member of
mailinglist.com.

The question is why would COMPANY.COM continue to use other services which
may or may not use DKIM?  If he is going to go thru this trouble with
ISP.COM, why would it avoid the protection by also using other services?

What if MAILINGLIST.COM decides it no longer wants the ISP.COM to sign mail?

What if MAILINGLIST.COM decides to go else where with a different ISP?

In short, the problem is not the concept, but how COMPANY.COM uses his
domain promiscuously.

Does he use this mailinglist.com because he knows it also uses ISP.COM?

Does he know mailinglist.com will never sign? or that it will also use
ISP.COM?

So its all basically how company.com expect his domain to be used by others.

It could also be possible that ISP.COM is designed with some smarts and sees
that company.com is using mailinglist.com (Sender: mailinglist.com)?

In this case, it is mailinglist.com who is SUBMITTING the message, so the
ISP.COM will have some state information ahout whether it should allow this
or not because it might be considered suspicious the mail is not coming
directly from COMPANY.COM.

Maybe the company.com is also using SPF and he knows the ISP using SPF, so
in company.com SPF record, he authorize the mailinglist.com machine to send
mail to ISP.COM on its behalf.

So the concept is not flawed.  It all a matter on how the domain prepare its
policy.

As a VERIFIER, I don't see a problem here as long as it is all consistent.

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


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