On Fri, 12 Aug 2011, Douglas Otis wrote:
> The outcome in either "except-mlist" or "all" remains beyond the
> sender's control.
"except-mlist" is no worse here than "unknown", which is what the vast
majority of domains will be publishing in the absence of the
"except-mlist" option.
> The sender b
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
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 f
On 8/2/11 11:43 PM, Michael Deutschmann wrote:
> On Mon, 1 Aug 2011, Douglas Otis wrote:
>> This would be a safe method to extend policy without requisite two
>> party coordination as currently expected by DKIM.
> The problem is that for the majority of From: domains claimed in incoming
> mail, the
On Mon, 1 Aug 2011, Douglas Otis wrote:
> This would be a safe method to extend policy without requisite two
> party coordination as currently expected by DKIM.
The problem is that for the majority of From: domains claimed in incoming
mail, the TPA approach is just as unfeasable as "two party
coor
On 7/28/11 2:03 PM, Mark Delany wrote:
>>> DKIM should be viewed as a Work-In-Progress still missing a viable
>>> policy layer.
>> +1. But 5+ years WIP? :) It wasn't rocket science.
> Well, 7+ years ago it was suggested that "Domain policy is nascent"
> with the stated expectation that MARID would
As you probably recall, the focus of MARID was on LMAP solutions, SPF
namely. The reputation proposals have the same problems we had here.
It was never a surprise to see the same issues - a Reputation
protocol requires Batteries and a market we were not ready for.
DKIM's pins on the side are
Michael Deutschmann wrote:
> On Wed, 27 Jul 2011, Douglas Otis wrote:
>> DKIM should be viewed as a Work-In-Progress still missing a viable
>> policy layer.
>
> So you at least agree ADSP needs reform or replacement.
The ADSP "poison pill" didn't do anyone nor DKIM any favors. It
wasted an ofte
On Wed, 27 Jul 2011, Douglas Otis wrote:
> DKIM should be viewed as a Work-In-Progress still missing a viable
> policy layer.
So you at least agree ADSP needs reform or replacement.
Here's another way to express my points. Of the policies a sender may
wish to publish in ADSP or a successor, some
> > DKIM should be viewed as a Work-In-Progress still missing a viable
> > policy layer.
>
> +1. But 5+ years WIP? :) It wasn't rocket science.
Well, 7+ years ago it was suggested that "Domain policy is nascent"
with the stated expectation that MARID would soon develop something
comprehensive
Douglas Otis wrote:
> On 7/27/11 12:13 AM, Michael Deutschmann wrote:
>> I have one comment to make which ties together both my stance on Otis'
>> doublefrom crusade, and some reforms I have argued for in ADSP.
>
> ...
>
> Michael,
>
> DKIM should be viewed as a Work-In-Progress still missing a vi
As long as the deployment of the pure DKIM protocol continues to
openly allows for blind middle-ware resigners and destruction of
author domain signatures to exist without any sort of protocol
guidelines to offer controls, its hard to see any kind of policy
concept having a chance to work - au
On Wed, 27 Jul 2011, Douglas Otis wrote:
> Your fix will not control phishing or spoofing abuse and would expose
> these domains to open-ended sources.
ADSP reforms along my lines would not create any additional exposure,
because they are only intended for senderside deployment by sites that
are c
On 7/27/11 12:13 AM, Michael Deutschmann wrote:
> I have one comment to make which ties together both my stance on Otis'
> doublefrom crusade, and some reforms I have argued for in ADSP.
>
> Basically, at present the doublefrom trick is simply *unnecessary* for
> someone trying to pass me a forged
I have one comment to make which ties together both my stance on Otis'
doublefrom crusade, and some reforms I have argued for in ADSP.
Basically, at present the doublefrom trick is simply *unnecessary* for
someone trying to pass me a forged mail. My MTA, Exim-4.76, does not
natively support ADSP.
15 matches
Mail list logo
