On Thu, Mar 26, 2015 at 11:22 PM, Stephen J. Turnbull
wrote:
> Murray's point is that "proof of illegitimacy" is probably a pipe
> dream, as shown by past experience with "policy frameworks".[1]
> Legitimacy, on the other hand, is fairly easy to prove, as DMARC shows
> in daily use by financial i
- Original Message -
> From: "Stephen J. Turnbull"
> To: "Franck Martin"
> Cc: dmarc@ietf.org
> Sent: Thursday, March 26, 2015 10:28:18 PM
> Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
>
> Franck Martin writes:
>
> > 2) Mailing lists should be able to differentiate betwe
Michael Jack Assels writes:
> > I can't think of any. Some, many, or most of them were supposed
> > to be, but it has never turned out that way. I don't know why
> > DMARC is being held to a different standard.
>
> Isn't DMARC holding itself to a different standard?
That's a reasonable in
Franck Martin writes:
> 2) Mailing lists should be able to differentiate between an Hard
>bounce and a Soft bounce (by now).
>
> http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml
>is 7 years old now.
They can, but the problem that caused
- Original Message -
> From: "Steven M Jones"
> To: dmarc@ietf.org
> Sent: Thursday, March 26, 2015 4:38:08 PM
> Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
>
> On 03/26/2015 04:22 PM, Franck Martin wrote:
> >
> > What I learn for all the combinations: It does not change mu
On 03/26/2015 04:22 PM, Franck Martin wrote:
>
> What I learn for all the combinations: It does not change much, people
> still ignore my posts :P
Franck, that's wy outside the charter of this working group...
___
dmarc mailing list
dmarc@ietf.org
h
- Original Message -
> From: "Michael Jack Assels"
> To: "Murray S. Kucherawy"
> Cc: dmarc@ietf.org, "J. Gomez"
> Sent: Thursday, March 26, 2015 4:12:13 PM
> Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
>
> On Thu, 26 Mar 2015 15:23:08 PDT,
> "Murray S. Kucherawy" wrote:
On Thu, 26 Mar 2015 15:23:08 PDT,
"Murray S. Kucherawy" wrote:
> On Thu, Mar 26, 2015 at 1:21 PM, J. Gomez wrote:
>
> > If DMARC is going to increase support costs for small email operators, I
> > may as well migrate all my clients to Google Apps or Office 365 and be done
> > with costly email
On Thu, Mar 26, 2015 at 1:21 PM, J. Gomez wrote:
> If DMARC is going to increase support costs for small email operators, I
> may as well migrate all my clients to Google Apps or Office 365 and be done
> with costly email.
>
> That is why, in my view, DMARC's p=reject has to either be reliable to
- Original Message -
> From: "J. Gomez"
> That is why, in my view, DMARC's p=reject has to either be reliable to be
> relied on, or be suppressed from DMARC's formal specification if it is going
> to mainly be equal to p=do-whatever.
>
when you see a p=reject and DMARC tells you, you sh
On Thursday, March 26, 2015 3:08 AM [GMT+1=CET], Hector Santos wrote:
> SPF had a strong REJECTION concept with RFC4408 and with the latest
> spec RFC7202, it was relaxed with allowing for quarantining ideas
> (mail separation). RFC7208 made RFC4408 more costly by adding more
> complexity for an "
On Thursday, March 26, 2015 4:08 AM [GMT+1=CET], Stephen J. Turnbull wrote:
> J. Gomez writes:
>
> > > > But I would love to be able to reliably rely on DMARC's
> > > > p=reject.
>
> Even if you can in practice, you can't get to 100.0%. Even at
> ducks-in-a-row sites like
> (which is a financi
12 matches
Mail list logo
