On 10/3/10 8:15 AM, Hector Santos wrote:
John R. Levine wrote:
I'm really having trouble understanding what problem you're trying to
solve here. Could you describe it in under 100 words?
Provide a restrictive acceptance policy for Author Domains so they are
able to allow domain specific exceptions where possibly different domain
authentication or authorization might be used, and where specific header
fields such as List-ID or Sender headers may be required to help further
isolate different mail-streams within the authorized domain.
This mechanism is to avoid the bad practice of using sub or cousin
domains when confronting a phishing problem with the application of
restrictive acceptance policies. This approach should also improve
delivery integrity over using the simplistic ADSP discardable assertion,
even when no other third-party domain is being authorized.
I think I understand the problems that people see with lists and ADSP,
so please just explain what the problem is with lists and DKIM. You can
assume that lists will put DKIM signatures their outgoing mail, to help
recipients recognize mail from the list.
How does it help "recipients recognize mail from the list?"
In what way does it do this?
All we heard is "words" that this is the type of thing a user wants.
In other words, John, maybe it would be "useful" for example, using my
junk gmail.com account, to have a gmail.com user setting or filter
that says:
IF MAIL IS SIGNED, AND
IF LIST-ID is "ietf-dkim.mipassoc.org"
THEN MOVE TO INBOX WITH 5 STARS
IMHO, it would be a mistake to only permit third-party services that
employ DKIM and then only request rejection of non-complaint messages.
Alternative authentication or authorization schemes could be allowed to
better encompass existing services that enterprise domains might wish to
use. By not DKIM signing with the Author Domain, the third-party
authorization could even then stipulate use of TLS as an acceptance
basis. The TPA-Label scheme would allow email to gracefully transition
to different methods.
If this is what you speak of, then great. I would like for the ESP/ISP
to offer user rules like this.
But I would like for may to have a more generic rule:
IF MAIL IS SIGNED, AND
IF ASL/ATPS/TPA is FAIL
THEN MOVE/KEEP TO SPAM BOX
or
IF MAIL IS NOT SIGNED, AND
IF ASL/ATPS/TPA is FAIL
THEN MOVE/KEEP TO REALLY BAD SPAM BOX
All I am hearing is "words", lets begin translate this into sound
rules that people can use.
Domains being flooded with phishing attacks have an incentive to offer
additional information to assist in the evaluation of messages
containing their Author Domain. As such, it would not be the ISP
offering the rules. However, there are any number of organizations able
to assist in the publishing and monitoring of these Third-Party
services. The problem with VBR is that it only considered the Author
Domain independent of an informal third-party domain service that might
be desired, where publishing public keys with pre-arranged selectors is
not a practical solution.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html