ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871bis-06.txt // Input requirements

2011-04-22 12:59:25
Michael Deutschmann wrote:

Phishing attacks are *never* controllable by the domain being phished.
Nothing forces an ISP to deploy receiverside ADSP at all.

To change that, you need to invent some sort of certification for ISPs
that they take reasonable steps to prevent forgery.  Then banks could
impose a "phishing insurance" surcharge on any user who provides a
contact address at a domain that is not certified.

My opinion (of course).

So presuming there is a discovery method lets say for ISP/ESP domains 
with ADSP Checking Support, gmail.com users will have a bank surcharge 
and hotmail.com will not?

Personally, I think a bank imposing a surcharge has legal issues, like 
anti-trust, so its probably be more of an Bank TOS where

  - Bank requires ADSP checking ready hosting domains,

  - Bank requires hosting domains checking for the bank's
    AUID authorized SDID, either as a AUID/SDID combination
    or possibly via VBR, ATPS, ASL.

  - Bank offering their own 1st party email hosting service.

It will depend on what authorized signer (SDID) the bank will select. 
  If its a 1st party signature (AUID==SDID) then POLICY support 
discovery is needed.  If a 3rd party signature is used (AUID!=SDID), 
then now we move into the bank discovering what hosting domains will 
authorized the specific 3rd party AUID!=SDID condition.  IMO, for an 
external SDID vendor, the bank may have a concern relying on hosting 
domain trusting all messages signed solely based on the same SDID.

-- 
Hector Santos, CTO
http://www.santronics.com


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