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