On 8/10/11 11:18 AM, Michael Deutschmann wrote: > On Mon, 8 Aug 2011, Douglas Otis wrote: >> The concept behind the TPA scheme was to enable services on behalf of >> senders that lack requisite staffing to support this level of policy >> effort when using open-ended third-party services. The list of open > I don't see how that can work anytime soon for the use-case that concern > me, that of ordinary end-users at a consumer ISP posting to mailing lists. Your alternative creates support issues beyond the senders control when acceptance criteria by recipients conflict with actual use. The TPA scheme allows sender to establish third-party criteria beyond just conventional mailing-lists. > I suppose you could implement a central whitelist of mailing lists, but > some mailing lists are easier to forge than others. If a weak mailing > list gets on to the whitelist, then you have a policy just as easy to > bypass as except-mlist. But if a mailing list *that people actually use* > can't get on the whitelist, you have false positive rejections. The original TPA draft attempted to encompass any and all verification methods. The goal was to lessen the recipient's burden when vetting messages and allow senders a means to express the infrastructure they use. If there was a common method to authenticate SMTP transmitters cryptographically, the email attack surface could be dramatically reduced. DKIM is a poor tool at curbing spam as it can not safely assess SMTP transmitter behaviors. However, with a flexible policy layer, it might still prove useful at curbing phishing ploys. (Assuming input validation was properly applied.)
>> Why should white-listing mailing-lists or open third-party services >> become a burden for the recipient or their administrator? Better > I'm not seeking to *impose* that burden as a sender, I'm looking for the > opprotunity to *accept* that burden as a recipient, so as to reduce my > incoming false negative rate. This is about the sender policy. As a Sender, the criteria used by the recipient is pivotal. The TPA scheme allows the Sender to establish the specific criteria without expecting the recipient to guess. This scheme could also leverage any sender authentication that might be offered by DANE for example. > Many recipients can't take up the burden, and thus cannot detect forgeries > of except-mlist domains. But they lose nothing compared to the world > with just "unknown" and "discardable". (I'm not counting "all" since it > is too vague...) The outcome in either "except-mlist" or "all" remains beyond the sender's control. Without overcoming certainties, use of these policies exposes the sender's recipients to threats remain beyond the sender or their agents control. The sender benefits so let the senders do the work. A win-win for both the sender and the recipient. Guessing is lose-lose and a win for the malefactors. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
