Rich Kulawiec writes:
> But that's not really relevant here. The flooding propagation
> model of Usenet is quite different from the model used by mailing
> lists.
I'm not sure if it's been made clear already or not, but the Gmane
model (copied by the experimental Mailman add-on) is a NNTP net
Matt Simerson writes:
> If message headers and footers are so popular, how do you explain
> the continued "please unsubscribe me posts" sent to practically
> every mailing list?
Bell curve. Some people are 2-sigma self-centered, and others are
2-sigma clueless. What else is new?[1]
Note tha
On 6/10/2014 6:55 PM, Dave Warren wrote:
I've been surprised how many otherwise-technically-competent people
use subject tags to filter mailing lists. However, I suspect much/most
of this could go away if MUAs started displaying List-* information in
a useful way, and made filtering on those hea
On 2014-06-10 13:32, Matt Simerson wrote:
If message headers and footers are so popular, how do you explain the continued "please
unsubscribe me posts" sent to practically every mailing list? Message trailers have insured
that the answer is *right there* in every single message. Message traile
On 6/10/2014 4:21 PM, Stephen J. Turnbull wrote:
Hector Santos writes:
> Will you implement it? You need to implement it as part of the LSP
> integration.
What LSP integration? DMARC is an agreement between Author Domains
and destination hosts. Mediators are not party to it.
Once you g
On Jun 10, 2014, at 1:21 PM, Stephen J. Turnbull wrote:
> Hector Santos writes:
>
>> understand you are a LSP. DMARC effects you differently, but we can't
>> throw out the proverbial baby.
>
> I don't care what *you* do with your proverbial baby. The point is
> that *LSPs* are mostly not in
Hector Santos writes:
> Will you implement it? You need to implement it as part of the LSP
> integration.
What LSP integration? DMARC is an agreement between Author Domains
and destination hosts. Mediators are not party to it. It's arguable
that the host MTA should be checking DMARC authen
On Tue, Jun 10, 2014 at 12:56 PM, Vlatko Salaj
wrote:
>
> the story of my life... i'm always in minority, fighting for
> survival.
>
>
It is entirely possible to fight for the minority without acting this way.
It's unfortunate that you feel like your lifetime of frustration has to be
taken out o
Colleagues,
Under the procedures of BCP 94, the list administrators have decided to
moderate the access of Vlatko Salaj to the mailing list, effective
immediately, until 10 July 2014. If Mr. Salaj posts anything, it will come
to us first, and we shall permit the message to be posted only if, in o
On Tue, Jun 10, 2014 at 12:56 PM, Vlatko Salaj
wrote:
> u ppl keep repeating that. however, u never say what IS the reason.
> why don't u enlighten us, then?
>
Instead of assuming the reason and thus making false accusations, you
could've asked for the details first.
> maybe we'll bitch less i
On Tuesday, June 10, 2014 9:42 PM, Murray S. Kucherawy
wrote:
> The reason DMARC is not (presently) in the IETF stream has
> nothing to do with any of the above points.
u ppl keep repeating that. however, u never say what IS the reason.
why don't u enlighten us, then?
maybe we'll bitch less
On Tue, Jun 10, 2014 at 12:16 PM, Vlatko Salaj
wrote:
> > That, sir, is false, both as to fact and as to causality.
> > The choice was among different varieties of pain, but
> > no amount of preparation would have made the pain avoidable.
>
> that's a completely wrong assumption. they all knew DM
On 6/10/2014 3:16 PM, Vlatko Salaj wrote:
On Tuesday, June 10, 2014 9:01 PM, Stephen J. Turnbull
wrote:
LSP are just feeling the pains of their early ignorance of the
technology.
That, sir, is false, both as to fact and as to causality.
The choice was among different varieties of pain, but
On Tuesday, June 10, 2014 9:09 PM, Phillip Hallam-Baker
wrote:
unfortunately, Phillip, there's no hope for us
to agree on these things.
everything u say seems so double-faced and cynical,
it's beyond my best hope to comply.
nothing personal ofc.
simply cause i majored both philosophy and com
On Tue, Jun 10, 2014 at 2:28 PM, Vlatko Salaj wrote:
> On Tuesday, June 10, 2014 8:01 PM, Phillip Hallam-Baker
> wrote:
>
>
>> There is a traffic jam in Cambridge/Boston
>> several times a day as the lifting bridge opens to let some plutocrat
>> sail his yacht through at rush hour. Several thous
On Tuesday, June 10, 2014 9:01 PM, Stephen J. Turnbull
wrote:
>> LSP are just feeling the pains of their early ignorance of the
>> technology.
> That, sir, is false, both as to fact and as to causality.
> The choice was among different varieties of pain, but
> no amount of preparation would hav
Hector Santos writes:
> LSP are just feeling the pains of their early ignorance of the
> technology.
That, sir, is false, both as to fact and as to causality.
The LSPs were not "ignorant" of DMARC or its component technologies --
e.g., Mailman already had mitigations (courtesy of Franck Marti
On Tue, Jun 10, 2014 at 11:20 AM, Hector Santos wrote:
>
> It is more easier, more feasible, more safe, to just reject/discard
>>> the failed message (due to policy) at the backend and be done with it.
>>>
>>
>> In your opinion.
>>
>
> It is the expert opinion of million of IETF-MAN-HOURS and SM
On Tuesday, June 10, 2014 8:01 PM, Phillip Hallam-Baker
wrote:
> There is a traffic jam in Cambridge/Boston
> several times a day as the lifting bridge opens to let some plutocrat
> sail his yacht through at rush hour. Several thousand people have to
> wait half an hour to get to work for one p
On 6/10/2014 9:55 AM, Stephen J. Turnbull wrote:
Hector Santos writes:
> Are you oppose to any other domain using strong policies or just
> certain ones?
Domains where users have until now felt free to use their mailboxes as
they see fit (posting to mailing lists, as From: in on-behalf-of
s
On Mon, Jun 9, 2014 at 12:06 AM, Hector Santos wrote:
> On 6/8/2014 10:26 PM, Murray S. Kucherawy wrote:
>>
>>
>> To express how strong I feel about this
>>
>> If there is a charter for a new DMARC WG work, you can bet I will
>> request that any form of 5322.From-Corruption concept
On Sun, Jun 08, 2014 at 08:46:00AM -0400, Phillip Hallam-Baker wrote:
> NNTP was designed 30 years ago. We should consider moving on. The
> modern protocol world is JSON/REST
Let's not be so quick to dismiss NNTP: it's a more elegant weapon from
a more civilized age. ;) It has long since proven i
Hi Alessandro,
On Tue, Jun 10, 2014 at 8:14 AM, Alessandro Vesely wrote:
> First, weak signatures which are not part of a chain should be ignored
> by verifiers. An authentication chain can be defined as a set of
> valid DKIM signatures and possibly an SPF authentication of delegated
> domains
On Tue, Jun 10, 2014 at 8:41 AM, Vlatko Salaj
wrote:
>
> i'm still waiting for u to address the spoofing hole
> u left wide open with this approach.
>
> no, i won't accept "short-lived" as a solution, cause that's
> easy to circumvent.
>
>
It means you have a limited time to reuse a delegation si
Dave Crocker wrote:
>
> Actually I have a pretty typical view, relative to folks who have to
> direct experience with human factors, UI/UX, cognitive, memory and
> attention models, and the like. And as I said, I made a point of
> testing my summary judgement with a group of real experts, last sum
On Tue, Jun 10, 2014 at 9:19 AM, Hector Santos wrote:
>
>> The person on this list that actually represents a mailing list so far
>> seems to like the idea, and has explained why to some extent. I think
>> that's much more valuable feedback.
>>
>
> More valuable than other feedback?
> [...]
>
F
On 6/10/2014 10:00 AM, Murray S. Kucherawy wrote:
On Tue, Jun 10, 2014 at 12:41 AM, Vlatko Salaj
mailto:vlatko.sa...@goodone.tk>> wrote:
"introducing new ML requirements" has already been
characterised as not an ML solution. we have a few
of them already, and all much simpler than an
Dave Crocker writes:
> I am assuming that working with filtering engines is better than trying
> to work with 1-3 billion end users.
That's a pretty stiff requirement. I'd be satisfied if a simple
indicator, e.g. based on parsing Authentication-Results, saved 1-3 end
users from a phishing atta
On Tuesday, June 10, 2014 5:00 PM, Murray S. Kucherawy
wrote:
>> DKIM-Delegate suffers from replay attacks, and when not,
> DKIM is already replayable.
i'm not talking about DKIM, i'm talking about DKIM-D.
i'm still waiting for u to address the spoofing hole
u left wide open with this approac
On Tuesday, June 10, 2014 4:59 PM, Murray S. Kucherawy
wrote:
> Or do you mean something else when you say "new ML requirements"?
i wasn't talking about DKIM-Delegate, nor is this its thread,
so, while i will get to ur arguments in DKIM-D thread, they miss
the point here.
--
Vlatko Salaj ak
On Sat 07/Jun/2014 12:43:57 +0200 Dave Crocker wrote:
>
> I've been stewing on this idea for awhile and Murray pressed to get it
> into writing, adding his usual, significant enhancements to the original
> concept. We've gone a couple of rounds before releasing it, but it's
> still nascent enough
Murray S. Kucherawy writes:
> > It would require MLM to not drop DKIM headers... Still some
> > configuration on MLM side, but less in the way messages are
> > modified
>
> That's a much less visible and thus probably more tolerable change
> for MLM operators.
Mailman added an *optional* c
Franck Martin writes:
> Sure but you have a strong DKIM signature and a weak DKIM
> signature, using about the same domain, it is like the strong DKIM
> signature did not exist...
Of course, the strong signature exists for the forwarding third party.
What the destination should do, is a quest
On 6/10/2014 4:19 PM, Murray S. Kucherawy wrote:
> Yes but are you assuming you only put the weak DKIM signature, when
> you specifically know you are emailing a mailing list?
>
> Or what about a receiver which is not a mailing list? You are just
> allowing better replay of the mes
On Tue, Jun 10, 2014 at 7:13 AM, Franck Martin
wrote:
> --
>
> On Tue, Jun 10, 2014 at 6:58 AM, Franck Martin
> wrote:
>
>> --
>>
>> On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin
>> wrote:
>>
>>> This is interesting, however it seems to m
- Original Message -
> From: "Dave Crocker"
> To: "Murray S. Kucherawy" , "Franck Martin"
>
> Cc: dmarc@ietf.org
> Sent: Tuesday, June 10, 2014 4:06:13 PM
> Subject: Re: [dmarc-ietf] Fwd: New Version Notification for
> draft-kucherawy-dkim-delegate-00.txt
>
> On 6/10/2014 4:03 PM, Mur
On 6/10/2014 1:27 PM, Barry Leiba wrote:
>> > Each of those conditionals will not actually be satisfied. User's
>> > tend not to notice such things. The tend not to understand what
>> > they mean. Even when they understand, they tend to evaluate
>> > choices poorly. They tend to apply choic
- Original Message -
> From: "Murray S. Kucherawy"
> To: "Franck Martin"
> Cc: "Dave Crocker" , dmarc@ietf.org
> Sent: Tuesday, June 10, 2014 4:03:16 PM
> Subject: Re: [dmarc-ietf] Fwd: New Version Notification for
> draft-kucherawy-dkim-delegate-00.txt
> On Tue, Jun 10, 2014 at 6:58 AM
On 6/10/2014 11:22 AM, Stephen J. Turnbull wrote:
> Dave Crocker writes:
> > Everything gets much easier if we specify guidance for filtering
> > engines, before humans come into the picture.
>
> But now you are assuming filters that are very close to 100% accurate!
No.
I am assuming that work
- Original Message -
> From: "Stephen J. Turnbull"
> To: "Barry Leiba"
> Cc: "Dave Crocker" , dmarc@ietf.org
> Sent: Tuesday, June 10, 2014 3:33:16 PM
> Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.
>
> Barry Leiba writes:
>
> > But the more important point is
On 6/10/2014 4:03 PM, Murray S. Kucherawy wrote:
> Assuming by "strong DKIM signature" you mean the originator signature
> that covers the whole message, then given the MLM is going to invalidate
> it, it basically doesn't exist.
If it happens to survive (such as to recpients of the original mess
On Tue, Jun 10, 2014 at 6:58 AM, Franck Martin
wrote:
> --
>
> On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin
> wrote:
>
>> This is interesting, however it seems to me that DMARC should be more
>> aware of it if used.
>>
>
> Why? This is a way of satisfying the align
On Jun 10, 2014, at 2:47 PM, Murray S. Kucherawy wrote:
> On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin wrote:
> This is interesting, however it seems to me that DMARC should be more aware
> of it if used.
>
> Why? This is a way of satisfying the alignment requirement on the DKIM side.
>
On Tue, Jun 10, 2014 at 12:41 AM, Vlatko Salaj
wrote:
> "introducing new ML requirements" has already been
> characterised as not an ML solution. we have a few
> of them already, and all much simpler than any YADAs.
>
The person on this list that actually represents a mailing list so far
seems t
- Original Message -
> From: "Murray S. Kucherawy"
> To: "Franck Martin"
> Cc: "Dave Crocker" , dmarc@ietf.org
> Sent: Tuesday, June 10, 2014 3:47:56 PM
> Subject: Re: [dmarc-ietf] Fwd: New Version Notification for
> draft-kucherawy-dkim-delegate-00.txt
> On Mon, Jun 9, 2014 at 11:52 PM
Hector Santos writes:
> Are you oppose to any other domain using strong policies or just
> certain ones?
Domains where users have until now felt free to use their mailboxes as
they see fit (posting to mailing lists, as From: in on-behalf-of
services, etc) should not suddenly impose "p=reject"
On Tue, Jun 10, 2014 at 12:23 AM, Vlatko Salaj
wrote:
> DKIM-Delegate suffers from replay attacks, and when not,
> introduces whitelisting which, kind of, breaks its premise.
>
DKIM is already replayable.
I don't see how this introduces whitelisting requirements.
> also, we need a solution th
On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin
wrote:
> This is interesting, however it seems to me that DMARC should be more
> aware of it if used.
>
Why? This is a way of satisfying the alignment requirement on the DKIM
side. DMARC doesn't need to know it's there. The same is true of ATPS,
Barry Leiba writes:
> But the more important point is that you're presupposing that the
> changes are "better",
Yes and no. Obviously, if it is impossible to improve the MUAs,
there's no point in discussing it. In that sense, I have to presume
that improvements exist. That doesn't mean I ass
On 6/10/2014 7:27 AM, Barry Leiba wrote:
>The premise of your proposal is that users will notice that there's
> extra information, know what to do with it, and do the right thing,
> with reasonable consistency.
...
> Each of those conditionals will not actually be satisfied. User's
On 6/9/2014 10:38 PM, Barry Leiba wrote:
Putting as much value on RFC5322 From as DMARC does follows
conventional wisdom, but I believe that wisdom is flawed.
Of course, that speaks to the advice you want to give: tell UIs that
they should show the From addr-spec to users always. But be clear
a
> >The premise of your proposal is that users will notice that there's
> > extra information, know what to do with it, and do the right thing,
> > with reasonable consistency.
...
> > Each of those conditionals will not actually be satisfied. User's
> > tend not to notice such things. Th
On 6/10/2014 2:16 AM, Stephen J. Turnbull wrote:
I'm not proposing additional validation. As I've said before, I have
no quarrel with the DMARC protocol or its component protocols (at
least I've not found a reason to dislike it yet), although I strongly
dislike Yahoo!'s policy use of "p=reject"
Dave Crocker writes:
>The premise of your proposal is that users will notice that there's
> extra information, know what to do with it, and do the right thing,
> with reasonable consistency.
Yes, yes, yes, and yes.
> Each of those conditionals will not actually be satisfied. User's
> t
On Tuesday, June 10, 2014 9:18 AM, Dave Crocker wrote:
> https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/
[it] introduces new ML requirements.
>>> So rather than offer dismissive, summary comments,
>>> please offer criticisms of technical substance.
>> i would rather not
DKIM-Delegate suffers from replay attacks, and when not,
introduces whitelisting which, kind of, breaks its premise.
also, we need a solution that doesn't risk of being modified
by any middle man on message path. DKIM can't offer that,
and will never be able to.
--
Vlatko Salaj aka goodone
http
On 6/10/2014 9:11 AM, Vlatko Salaj wrote:
> On Tuesday, June 10, 2014 8:49 AM, Dave Crocker wrote:
>>> https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/
>>> the master-piece of DKIM messiness. unfortunately,
>>> it doesn't solve current ML problem, but introduces
>>> new ML require
On Tuesday, June 10, 2014 8:49 AM, Dave Crocker wrote:
>> https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/
>> the master-piece of DKIM messiness. unfortunately,
>> it doesn't solve current ML problem, but introduces
>> new ML requirements.
> So rather than offer dismissive, sum
58 matches
Mail list logo
