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
