Re: [ietf-dkim] Re: requrements-01// security concerns regarding policy domain designations rather than delegations

On Sep 19, 2006, at 3:00 PM, Frank Ellermann wrote: RFC4408 enables various DDoS and DNS poisoning attacks as previously described. That's about as relevevant as the mail arriving with 25 DKIM signatures (one valid), after you got a million you'd figure out how to disable DKIM verificat

[ietf-dkim] I-D ACTION:draft-ietf-dkim-ssp-requirements-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF. Title : Requirements for a DKIM Signing Practices Protocol Author(s) : M. Thomas Filenam

[ietf-dkim] Jabber meeting Thursday 1500 UTC

Venue: [EMAIL PROTECTED] Date: Thursday September 21 2006 Time: 1500 UTC (1600 Dublin, 1100 New York) Duration: 1 hr Agenda: #1 agenda bash (2 min) #2 ssp-reqs issues and requirements (50) #3 further jabber session logistics (5) #4 AOB For item 2, since there are so few discrete issues [2] at

[ietf-dkim] Re: tracker/jabber info

Tim Draegen wrote: > The best I can come up with is "https://rt.psg.com/";, but > I have no access to this. If your browser supports the https at this site try user ietf password ietf, see also http://rt.psg.com For the jabber etc. check out http://tools.ietf.org/wg/dkim Frank ___

[ietf-dkim] Re: requrements-01// security concerns regarding policy domain designations rather than delegations

Douglas Otis wrote: > Only strict 2822.From policy can act as a basis for > rejection, but this does not permit non-compliant services > that will continue to be used for a long time. If senders and receivers remove non-compliant services from the picture: good riddance. I'm more worried about

[ietf-dkim] tracker/jabber info

Can someone post info on where issues are being tracked? The best I can come up with is "https://rt.psg.com/";, but I have no access to this. Thanks! =- Tim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] Re: requrements-01// security concerns regarding policy domain designations rather than delegations

Stephen Farrell wrote: > Please read that and try to move the discussion on to issues > that we can track and resolve. I've already posted my list of mostly minor issues with -01pre: > now its time to get the ssp-reqs document done Apparently d

Re: [ietf-dkim] Re: requrements-01// security concerns regarding policy domain designations rather than delegations

Frank, You may have missed my reply to Doug on this thread. Please read that and try to move the discussion on to issues that we can track and resolve. There has already been plenty of open ended discussion and now its time to get the ssp-reqs document done and move on the the protocol. Thanks,

Re: [ietf-dkim] Re: requrements-01// security concerns regarding policy domain designations rather than delegations

Douglas Otis wrote: The threats draft missed that the sending agent must be held accountable and that the DKIM signature can not play this role. As a result of this oversight caused by understatements of replay concerns among others such as use of annotations, the threat draft offers poor gu

Re: [ietf-dkim] Re: requrements-01// security concerns regarding policy domain designations rather than delegations

On Sep 19, 2006, at 10:16 AM, Douglas Otis wrote: > To avoid abusive DSNs to innocent bystanders you always need a verified Return-Path. Minimally you've to trust that it's no nonsense (e.g. if it came from a source where that's hopefully guaranteed). When the 2822.From is associated wi

Re: [ietf-dkim] Re: requrements-01// security concerns regarding policy domain designations rather than delegations

On Sep 18, 2006, at 5:27 PM, Frank Ellermann wrote: Douglas Otis wrote: DKIM is unrelated to the message envelope True, more below. Requiring the 2821.Rcpt To to match a 2822.To or CC header field email-address is not practical. Of course, anything not matched is by definition a BCC.