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
Dear Dmarc WG,
https://tools.ietf.org/html/draft-otis-dmarc-escape-01
Made a few changes in response to several comments.
Sorry for not taking time to respond to comments individually.
Regards,
Douglas Otis
___
dmarc mailing list
dmarc@ietf.org
https:
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
> >
Hector Santos writes:
> On 4/25/2015 11:34 AM, Stephen J. Turnbull wrote:
> >
> > My personal opinion is that, on the contrary, people are already way
> > too quick to discard proposals simply because they involve changes to
> > MUAs. Of course, the reality that this is an IETF WG, and what w
Sorry for delay, Elizabeth did more fixing and I'm going through the reviews
now. See comments inline.
- Original Message -
> From: "Murray S. Kucherawy"
> To: "Franck Martin"
> Cc: "dmarc"
> Sent: Tuesday, March 31, 2015 1:01:15 PM
> Subject: Re: [dmarc-ietf] New Version Notificatio
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 4/25/2015 11:34 AM, Stephen J. Turnbull wrote:
My personal opinion is that, on the contrary, people are already way
too quick to discard proposals simply because they involve changes to
MUAs. Of course, the reality that this is an IETF WG, and what we can
do that has effect with high probabi
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
28 matches
Mail list logo
