Jim,
The problem is, in lieu of a SSA (Special Signing Arrangment), we
don't know how MLS/MLM will behave and more importantly how the wide
distribution to members will behave.
Right now, Levine is advocating MLS/MLM to not support POLICY and to
blindly resign. So paypal will have no control over MLS/MLM behavior
regarding DKIM.
Personally, I will never sign a corporate brand domain, especially
corp.paypal.com, for a public channel. Use something else that has
less public face liability behind it. For example, I use ISDG.NET in
the public mailing list.
Whatever is used for public mailing list exposure, three things needs
to be expected:
If the GOOD/BAD submission is 1st party signed,
1) It may honored ADSP by MLM draft ready software,
2) It may be stripped
3) It may be resigned
4) The 1st party signature WILL be broken
If the GOOD/BAD submission is NOT 1st party signed,
1) It may honored ADSP by MLM draft ready software,
3) It may be resigned
We already went thru all these, and the bother line, the domain is
OPEN for ABUSE in all cases when using a relaxed or no policy.
It also goes back to the 3rd party authorization issue. But in lieu
of this, the domain can only hope for the SSA paths.
At the very least, paypal should use a MAILING LIST that is DKIM
ready. But that isn't going to help the OTHER systems that may get
spoofed DKIM 3rd party signed mail. There PAYPAL is still vulnerable.
With no authorization 3PS list or TPA concept in place, domains like
paypal will not be able to get any good level of protection in public
mailing lists.
IMV to reduce liability is to not sign at all to avoid negatively
worming up systems or use a lesser association domain name, definitely
corp.paypal.com, or god no! Bad move if they do that.
--
Jim Fenton wrote:
> No, I'm suggesting that they publish an explicit dkim=unknown if that is
> their intent.
>
> -Jim
>
>
> On Sep 7, 2010, at 4:31 AM, Douglas Otis <[email protected]> wrote:
>
>> On 9/6/10 7:59 PM, Jim Fenton wrote:
>>> If you are using a subdomain and want to be doubly sure that nobody is
>>> using the parent domain check, you might want to publish an explicit
>>> ADSP record for the domain rather than rely on the default of
>>> "unknown" if that is what you want to assert.
>> Jim,
>>
>> Are you suggesting corp.paypal.com should use ADSP dkim=all? This is
>> still likely to disrupt some mailing-list messages that corp.paypal.com
>> might desire to share, and allow spoofed messages to gain acceptance
>> using corp.paypal.com.
>>
>> How will recipients know Jon Doe <[email protected]> is less
>> trustworthy than Jon Doe <[email protected]>? Bad actors may only need
>> recipients to click on an attachment displayed as "paypal-policy.docx"
>> referencing paypal-policy.docx.exe, or a link offering details on
>> obtaining Referral Benefit pay-outs.
>>
>> Ideally, only one domain should be used to exchange email, but currently
>> ADSP is unable to safely permit this practice. Unfortunately,
>> subdomains are nearly as confusing as cousin domains. However a
>> recipient is likely to be more wary of cousin domains and to recognize
>> paypal.com and trust its subdomains more than they should in this case.
>>
>> -Doug
>> _______________________________________________
>> dkim-ops mailing list
>> [email protected]
>> http://mipassoc.org/mailman/listinfo/dkim-ops
>
> _______________________________________________
> dkim-ops mailing list
> [email protected]
> http://mipassoc.org/mailman/listinfo/dkim-ops
>
>
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
dkim-ops mailing list
[email protected]
http://mipassoc.org/mailman/listinfo/dkim-ops
