On 4/29/15 12:09 AM, Stephen J. Turnbull wrote:
> Franck Martin writes:
>
> > I think we should refrain to blame anything or anyone.
>
> I think that there is no solution attractive to email users possible
> without naming names.
>
> AFAIK[1], it is a fact that the problems that have made "DMARC
On Wed, Apr 29, 2015 at 6:26 AM, Michael Jack Assels <
mjass...@encs.concordia.ca> wrote:
> Right. I'd been avoiding that because I saw this as a relatively minor
> change to Murray's draft-kucherawy-dkim-transform-00, but if message
> wrapping is considered a nonstarter, a new I-D is in order, a
On 29 Apr 2015 09:11:57 EDT,
"John R Levine" wrote:
> > I'm still hoping for something that users will like, so I guess it's back
> > to the drawing board.
>
> The usual next step is to write up the proposal as an I-D and send it in,
> so we have a concrete description. Even if we decide not
I'm still hoping for something that users will like, so I guess it's back
to the drawing board.
The usual next step is to write up the proposal as an I-D and send it in,
so we have a concrete description. Even if we decide not to use it,
having a spec to refer to is often useful when looking
On 28 Apr 2015 19:25:36 EDT,
"John R Levine" wrote:
> Discussions on the Mailman list say that users hate wrapped messages,
> because in most MUAs they look really ugly.
OK, I'll concede that. They don't bother me, but I don't count for much.
> I still don't see what the advantage is compare
Franck Martin writes:
> I think we should refrain to blame anything or anyone.
I think that there is no solution attractive to email users possible
without naming names.
AFAIK[1], it is a fact that the problems that have made "DMARC" a
four-letter word across the Internet are almost entirely du
John R Levine writes:
> Discussions on the Mailman list say that users hate wrapped
> messages, because in most MUAs they look really ugly.
It's worse than that. As of 6 months ago, it was impossible to read
wrapped messages (as implemented by Mailman, anyway) in Apple Mail for
iOS.
As for "r
I think I've failed to communicate. Yes, the pristine original message
will be appropriately MIME-wrapped, with the list decorations becoming
separate MIME parts, but the MUA is not expected to do anything except
to present the MIME message to the final recipient.
Discussions on the Mailman lis
On 28 Apr 2015 17:04:31 EDT,
"John R Levine" wrote:
> > 4. Because the Sender Domain signature is valid and contains tf= and stf=
> >tags, Recipient validators reconstruct the original message ...
>
> Oh, it's message wrapping. There are easier ways to do that without
> changing DKIM: ha
- Original Message -
> From: "Franck Martin"
> To: "R E Sonneveld"
> > I believe a number of the Mediators, described in par. 3.2 of
> > https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-01, cannot
> > easily be changed. To give an example: recently when I was working for
>
- Original Message -
> From: "Terry Zink"
> To: dmarc@ietf.org
> Sent: Tuesday, April 28, 2015 11:26:00 AM
> Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
>
> > Who knows? Perhaps Yahoo and AOL would suffer "user diaspora&qu
On 4/28/15 11:35 AM, John Levine wrote:
>> Are we going to say "The big four email providers pushed their problems onto
>> everyone else" ?
> Yes, of course. But as we've seen, we have little ability to push
> back.
Dear John,
Standing up to abusive domains requires a fallback policy
compatibl
- Original Message -
> From: "Rolf E. Sonneveld"
> To: "John Levine" , dmarc@ietf.org
> Cc: superu...@gmail.com
> Sent: Thursday, April 16, 2015 3:21:33 PM
> Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
>
> Now I think S
4. Because the Sender Domain signature is valid and contains tf= and stf=
tags, Recipient validators reconstruct the original message ...
Oh, it's message wrapping. There are easier ways to do that without
changing DKIM: have the list send the message as a single entry MIME
digest. Mailm
On 28 Apr 2015 12:51:42 EDT,
"John R Levine" wrote:
> > This is merely an attempt to find a mechanism whereby DMARC and MLMs could
> > cooperate, up to the point where subscriber Recipient validators could
> > honour an Author domain's p=reject, without removing the original author's
> > mailbox
> Are we going to say "The big four email providers pushed their problems onto
>everyone else" ?
Yes, of course. But as we've seen, we have little ability to push
back.
R's,
John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listi
> Who knows? Perhaps Yahoo and AOL would suffer "user diaspora" if they
> kept publishing p=reject and MLMs decided to be DMARC-compliant when
> reinjecting messages.
I see a lot of "Yahoo and AOL did this", "Yahoo and AOL don't care", "Yahoo and
AOL pushed their problems onto everyone else", e
On Tuesday, April 28, 2015 6:11 AM [GMT+1=CET], Stephen J. Turnbull wrote:
> J. Gomez writes:
>
> > That would force DMARC-compliant Mediators to reject (or accept
> > but not resend) incoming email from p=reject domains,
> > irrespective of whether such mail passes or not the initial
- Original Message -
> From: "Scott Kitterman"
> To: dmarc@ietf.org
> Sent: Thursday, April 16, 2015 7:11:14 AM
> Subject: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
>
> Another example of a potential solution is receivers amalgamating data f
This is merely an attempt to find a mechanism whereby DMARC and MLMs could
cooperate, up to the point where subscriber Recipient validators could
honour an Author domain's p=reject, without removing the original author's
mailbox from the From header.
Unless I've missed something, I don't see how
On 27 Apr 2015 21:29:51 -,
"John Levine" wrote:
> >Even if we were all to concur that altering the From by adding the list is
> >the right way forward here (an intriguing idea at the moment), ...
>
> Just for the record, I haven't been responding to arguments about
> rewriting the From: lin
On 4/27/2015 2:44 PM, Murray S. Kucherawy wrote:
So it seems to me the points of contention here are:
1) Is the MLM violation of the SHOULD NOT cited above the kind of
violation that we accept based on how "SHOULD NOT" is defined in
RFC2119? It seems to me that it is, especially given how long
On Mon, 27 Apr 2015 12:38:15 PDT,
"Murray S. Kucherawy" wrote:
> Even if we were all to concur that altering the From by adding the list is
> the right way forward here (an intriguing idea at the moment), the question
> of ordering would need to be addressed, and then how that applies to all
> t
On Mon, 27 Apr 2015 11:44:38 PDT,
"Murray S. Kucherawy" wrote:
> On Mon, Apr 27, 2015 at 4:17 AM, Michael Jack Assels <
> mjass...@encs.concordia.ca> wrote:
>
> > On Sun, 26 Apr 2015 12:21:04 +0200,
> > "J. Gomez" wrote:
> >
> > > On Sunday, April 26, 2015 2:25 AM [GMT+1=CET], Stephen J. Turnb
On Tuesday, April 28, 2015 3:39 AM [GMT+1=CET], Stephen J. Turnbull wrote:
> Hector Santos writes:
> > On 4/26/2015 8:34 PM, Stephen J. Turnbull wrote:
>
> > > The problem is that all are detested by some users, and none are
> > > actually liked by any user. Therefore we developers continue t
Murray S. Kucherawy writes:
> The question to me is whether the message that the MLM software emits is
> the same as the original message. If it is, then the Author ought to be
> preserved across the MLM. If it is not, then the MLM emits a new message,
> and it actually SHOULD NOT keep the A
J. Gomez writes:
> That would force DMARC-compliant Mediators to reject (or accept
> but not resend) incoming email from p=reject domains,
> irrespective of whether such mail passes or not the initial
> incoming DMARC checks.
Yahoo! and AOL are bigger than MLMs. MLMs would be
On Apr 27, 2015, at 2:29 PM, John Levine wrote:
>> Even if we were all to concur that altering the From by adding the list is
>> the right way forward here (an intriguing idea at the moment), ...
>
> Just for the record, I haven't been responding to arguments about
> rewriting the From: line be
Hector Santos writes:
> On 4/26/2015 8:34 PM, Stephen J. Turnbull wrote:
> > The problem is that all are detested by some users, and none are
> > actually liked by any user. Therefore we developers continue to seek
> > alternatives -- but all desirable alternatives require cooperation of
> >
On 4/27/2015 6:20 PM, Scott Kitterman wrote:
Lets not lump "mailing list" into the same kind or group of MLM
operations. I care. I have a product to market.As a side note,
there is a legal argument to make when a MLM has intentionally ignored
a security protocol designed to protect a domain a
On Monday, April 27, 2015 06:11:57 PM Hector Santos wrote:
> On 4/27/2015 5:51 PM, Scott Kitterman wrote:
> >> What? There is an spec for DMARC. With the current DMARC specification,
> >> anyone can do almost anything and still claim to be DMARC-compliant. What
> >> about if to claim being DMARC-co
On 4/27/2015 5:51 PM, Scott Kitterman wrote:
What? There is an spec for DMARC. With the current DMARC specification,
anyone can do almost anything and still claim to be DMARC-compliant. What
about if to claim being DMARC-compliant, Receivers could not reinject alien
messages into the email infra
On 4/27/2015 4:23 PM, J. Gomez wrote:
Smooth operation?
Mediators don't really need to change, but their entry points need to
support DKIM+POLICY. For example, the Mediator receiver can simply
support honoring restrictive policies and it doesn't need to bother
with much else.
That is interest
On Mon, Apr 27, 2015 at 2:37 PM, J. Gomez wrote:
> Apart from the CANNOT bit, is that different from where we are today?
>
> Well, the CANNOT part would impede the whole lot of problems we are trying
> to solve, wouldn't it so?
>
Maybe. I was just confirming that that's the only part that's dif
On Monday, April 27, 2015 11:33:50 PM J. Gomez wrote:
> On Monday, April 27, 2015 11:25 PM [GMT+1=CET], John Levine wrote:
> > > Couldn't the DMARC specification spell out that Receivers claiming
> > > to be DMARC-compliant, when choosing to *accept* incoming messages
> > > from Senders publishing
Original Message From: Murray S. Kucherawy
On Mon, Apr 27, 2015 at 1:23 PM, J. Gomez wrote:
Couldn't the DMARC specification spell out that Receivers claiming to be
DMARC-compliant, when choosing to *accept* incoming messages from Senders
publishing p=reject (irrespective of whether such
On Monday, April 27, 2015 11:25 PM [GMT+1=CET], John Levine wrote:
> > Couldn't the DMARC specification spell out that Receivers claiming
> > to be DMARC-compliant, when choosing to *accept* incoming messages
> > from Senders publishing p=reject (irrespective of whether such
> > accepted messages
>Even if we were all to concur that altering the From by adding the list is
>the right way forward here (an intriguing idea at the moment), ...
Just for the record, I haven't been responding to arguments about
rewriting the From: line because I don't any way they will lead to
anything useful, and
>Couldn't the DMARC specification spell out that Receivers claiming to be
>DMARC-compliant, when choosing to *accept* incoming messages from Senders
>publishing p=reject (irrespective of whether such accepted messages passed
>or not the DMARC checks), CANNOT after-the-fact reinject such received
>m
On Mon, Apr 27, 2015 at 1:23 PM, J. Gomez wrote:
> Couldn't the DMARC specification spell out that Receivers claiming to be
> DMARC-compliant, when choosing to *accept* incoming messages from Senders
> publishing p=reject (irrespective of whether such accepted messages passed
> or not the DMARC c
On Monday, April 27, 2015 7:09 AM [GMT+1=CET], Hector Santos wrote:
> On 4/25/2015 6:24 AM, Rolf E. Sonneveld wrote:
> > >
> > > I'd like to note that it is the presence/existance of actor
> > > "Mediator" which induces the DMARC compatibility problems with
> > > indirect flows.
> > >
> > > I.e.
On Mon, Apr 27, 2015 at 12:27 PM, J. Gomez wrote:
> > The question to me is whether the message that the MLM software emits
> > is the same as the original message. If it is, then the Author ought
> > to be preserved across the MLM. If it is not, then the MLM emits a
> > new message, and it act
Original Message from: Murray S. Kucherawy
> The question to me is whether the message that the MLM software emits
> is the same as the original message. If it is, then the Author ought
> to be preserved across the MLM. If it is not, then the MLM emits a
> new message, and it actually SHOULD NOT
On Monday, April 27, 2015 2:34 AM [GMT+1=CET], Stephen J. Turnbull wrote:
> > Well, I don't "attack" anyone, I express my opinion about what I
> > think would be the easiest and lest painful --considering the email
> > system as a whole-- solution to the problem.
>
> It's already available, and a
On Mon, Apr 27, 2015 at 4:17 AM, Michael Jack Assels <
mjass...@encs.concordia.ca> wrote:
> On Sun, 26 Apr 2015 12:21:04 +0200,
> "J. Gomez" wrote:
>
> > On Sunday, April 26, 2015 2:25 AM [GMT+1=CET], Stephen J. Turnbull wrote:
> >
> > > The From header field is not in the public domain, and not
On Mon, 27 Apr 2015 07:17:05 EDT,
Michael Jack Assels wrote:
> [...]
> From: "Need enhancement? See http://bad-example.com";
> ,
> Sender:
> DKIM-Signature: [...]i=bad-example.com[...]
> DKIM-Signature: [...]i=example.org[...]
> [...]
Sigh. All instances
On 4/26/2015 8:34 PM, Stephen J. Turnbull wrote:
GNU Mailman, for example, provides several DMARC mitigations. The
traditionally available "just forward" configuration is still
available, but disliked strongly because users really like have
unsubscribe and archive links in the footer. The "ste
On Sun, 26 Apr 2015 12:21:04 +0200,
"J. Gomez" wrote:
> On Sunday, April 26, 2015 2:25 AM [GMT+1=CET], Stephen J. Turnbull wrote:
>
> > The From header field is not in the public domain, and not available
> > for appropriation. "Taking ownership" of something that isn't yours is
> > properly c
On 4/25/2015 6:24 AM, Rolf E. Sonneveld wrote:
I'd like to note that it is the presence/existance of actor
"Mediator" which induces the DMARC compatibility problems with
indirect flows.
I.e., if you supress the Mediator, all is fine and dandy. That fact
should at leat put some pressure on Media
On Apr 26, 2015, at 5:34 PM, Stephen J. Turnbull wrote:
>
> That's possible, but really, only yahoo.com and aol.com matter. No
> Yahoo! or AOL affiliate that I've checked other than those two
> publishes p=reject or even p=quarantine, and in fact I've never seen
> p=reject on a domain that pos
J. Gomez writes:
> Is the message Subject in the public domain? Is the message Body in
> the public domain? Why are many mailing lists taking liberties with
> them?
Our interpretation is that no liberties are being taken: we have tacit
permission from the authors. I've *never* seen an author
On Sunday, April 26, 2015 2:25 AM [GMT+1=CET], Stephen J. Turnbull wrote:
> J. Gomez writes:
>
> > > What else do you propose that we do?
> >
> > Well, if you ask... Mediators could take ownership of the
> > Header-From whenever their involvement results in the Originator's
> > DKIM signature be
J. Gomez writes:
> > What else do you propose that we do?
>
> Well, if you ask... Mediators could take ownership of the
> Header-From whenever their involvement results in the Originator's
> DKIM signature being invalidated.
The From header field is not in the public domain, and not availab
On Saturday, April 25, 2015 4:29 PM [GMT+1=CET], Stephen J. Turnbull wrote:
> J. Gomez writes:
>
> > What costs are Mediators currently taking to improve
> > validation/authentication of the email system as a whole?
>
> Isn't it obvious that Mediators bear all of the burden that *both*
> ends do
J. Gomez writes:
> What costs are Mediators currently taking to improve
> validation/authentication of the email system as a whole?
Isn't it obvious that Mediators bear all of the burden that *both*
ends do? Of course, we perform both roles on each message. We verify
signatures and filter mes
On 4/25/2015 6:32 AM, J. Gomez wrote:
>>> I.e., if you supress the Mediator, all is fine and dandy.
...
>> > and what benefits do they get in return?
> The benefit to Mediators is that they will avoid becoming an obsolete
> artifact of the past, like open SMTP relays.
The word that is needed he
On Saturday, April 25, 2015 12:24 PM [GMT+1=CET], Rolf E. Sonneveld wrote:
> On 04/25/2015 11:50 AM, J. Gomez wrote:
> > On Thursday, April 16, 2015 4:11 PM [GMT+1=CET], Scott Kitterman
> > wrote:
> >
> > > I will probably regret this, but since people are throwing around
> > > things like Paret
On 04/25/2015 11:50 AM, J. Gomez wrote:
On Thursday, April 16, 2015 4:11 PM [GMT+1=CET], Scott Kitterman wrote:
I will probably regret this, but since people are throwing around
things like Pareto to argue in favor or against specific solution
areas, I thought it might be useful to take a step
On Thursday, April 16, 2015 4:11 PM [GMT+1=CET], Scott Kitterman wrote:
> I will probably regret this, but since people are throwing around
> things like Pareto to argue in favor or against specific solution
> areas, I thought it might be useful to take a step back and look at
> what might make a
On 4/16/2015 8:16 PM, Scott Kitterman wrote:
+1 Extremely bias.
Lets keep in mind that there are two minimum receivers generally with
a MLM transaction that also need to be part of the cost and impact
analysis:
MDA1 -- receiver and resigner
MDA2 -- final user(s) receiver(s).
Another so
On April 16, 2015 8:05:25 PM EDT, Douglas Otis wrote:
>
>
>On 4/16/15 3:40 PM, Scott Kitterman wrote:
>> I think it would be better to await the results of the recently
>chartered dbound working group. Whatever DMARC does should, in the end,
>align to that, so it would be better not to have this g
On April 16, 2015 7:06:02 PM EDT, Hector Santos wrote:
>On 4/16/2015 6:21 PM, Rolf E. Sonneveld wrote:
>
>> Now I think Scott is right that we need to make a step back and his
>> analysis might help us to know on which solutions we'd best spend
>most
>> of our time. However, having said that, I'm
On 4/16/15 3:40 PM, Scott Kitterman wrote:
> I think it would be better to await the results of the recently chartered
> dbound working group. Whatever DMARC does should, in the end, align to that,
> so it would be better not to have this group expend effort in that area for
> now.
Dear Scott
>yes, but the problem with cost imposed on third parties is that it is
>valued different by the one who imposes it on someone else and the one,
>on which is it imposed.
Well, sure. If I can force you to solve my problem, as far as I'm
concerned that's a free solution. I hope we agree we want t
On 4/16/2015 6:21 PM, Rolf E. Sonneveld wrote:
Now I think Scott is right that we need to make a step back and his
analysis might help us to know on which solutions we'd best spend most
of our time. However, having said that, I'm afraid that we're biased
by our discussions around the 'DMARC/Mail
On April 16, 2015 5:57:10 PM EDT, Douglas Otis wrote:
>
>
>On 4/16/15 2:26 PM, Scott Kitterman wrote:
>> I don't think market share in the abstract is useful for
>> this discussion. Per my utility analysis, the question is
>> not percent of market (however that is defined), but
>> breadth of marke
On 04/16/2015 11:20 PM, John Levine wrote:
Rolf kind of said what I'm thinking here: I agree that we need to look at
the costs. But are we willing, or not willing, to accept costs that are
not zero?
Sure, everything has some cost. Something I should have made clearer
is the difference between
On 4/16/15 2:26 PM, Scott Kitterman wrote:
> I don't think market share in the abstract is useful for
> this discussion. Per my utility analysis, the question is
> not percent of market (however that is defined), but
> breadth of market scope being sufficient to enable
> interoperability when it'
On Thursday, April 16, 2015 05:20:01 PM Hector Santos wrote:
> On 4/16/2015 4:58 PM, Murray S. Kucherawy wrote:
> > On Thu, Apr 16, 2015 at 11:34 AM, John R Levine wrote:
> >> At least, we need to look at what non-technical costs they push onto
> >> other
> >> parties.
> >>
> >> Some changes have
>Rolf kind of said what I'm thinking here: I agree that we need to look at
>the costs. But are we willing, or not willing, to accept costs that are
>not zero?
Sure, everything has some cost. Something I should have made clearer
is the difference between the costs of changes one imposes on one's
On 4/16/2015 4:58 PM, Murray S. Kucherawy wrote:
On Thu, Apr 16, 2015 at 11:34 AM, John R Levine wrote:
At least, we need to look at what non-technical costs they push onto other
parties.
Some changes have insignificant non-techincal costs and are not
controversial, e.g., adding a List-ID hea
On Thursday, April 16, 2015 01:58:59 PM Murray S. Kucherawy wrote:
> On Thu, Apr 16, 2015 at 11:34 AM, John R Levine wrote:
> > At least, we need to look at what non-technical costs they push onto other
> > parties.
> >
> > Some changes have insignificant non-techincal costs and are not
> > contr
On Thu, Apr 16, 2015 at 11:34 AM, John R Levine wrote:
> At least, we need to look at what non-technical costs they push onto other
> parties.
>
> Some changes have insignificant non-techincal costs and are not
> controversial, e.g., adding a List-ID header for the benefit of recipients
> who kno
I don't have a summary. To the extent I mentioned any specific proposal it was
meant to be merely exemplary. The point, is to come up with a framework to
discuss solution utility. Because there is a certain breadth of deployment
needed for interoperability for some solutions, I don't think Pa
On 04/16/2015 08:34 PM, John R Levine wrote:
The most tedious and unhelpful discussions here have implicitly (or
perhaps explicitly) assumed that receiver nontechnical costs don't
matter, then repeatedly pointed out the true but useless fact that
there are single party mediator changes with trivi
The most tedious and unhelpful discussions here have implicitly (or
perhaps explicitly) assumed that receiver nontechnical costs don't
matter, then repeatedly pointed out the true but useless fact that
there are single party mediator changes with trivial technical costs.
Useless because it pres
On Thu, Apr 16, 2015 at 9:31 AM, John Levine wrote:
> The most tedious and unhelpful discussions here have implicitly (or
> perhaps explicitly) assumed that receiver nontechnical costs don't
> matter, then repeatedly pointed out the true but useless fact that
> there are single party mediator cha
Scott,
what is your summary with all this?
We probably should understand optimization concepts such as Pareto Optimality
and Query Dissemination. Both are applicable here as well.
I've actually have two receivers; one for the mediator and one for the
end-users. The problem was that Levine
>That leads to six combinations: Originator/Big, Originator/Small,
>Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small.
This is indeed useful. But I think it's also important to look at
technical vs. nontechnical costs for each actor. The whole reason
we're having this discussion
Scott,
Thanks for laying the problem space out in this manner.
Mike
> -Original Message-
> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Scott Kitterman
> Sent: Thursday, April 16, 2015 10:11 AM
> To: dmarc@ietf.org
> Subject: [dmarc-ietf] Indirect Mail Flow S
I will probably regret this, but since people are throwing around things like
Pareto to argue in favor or against specific solution areas, I thought it might
be useful to take a step back and look at what might make a solution (or set
of solutions) useful to pursue.
For indirect mail flows like
81 matches
Mail list logo
