Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

2014-06-12 Thread John Sweet
On Jun 13, 2014, at 7:18 AM, "Stephen J. Turnbull" wrote: > In any case, now I wonder what they're really trying to do. They can > check for "p=reject" without sending *any* mail. That's not an integration test. It's all automated. The answer you want is, "Can I make money now?" This is how yo

Re: [dmarc-ietf] Comportment on this list

2014-05-30 Thread John Sweet
On Fri, May 30, 2014 at 1:31 AM, Brandon Long wrote: > I think many of the folks on this list don't use email the way that the > vast majority of people do. > The longer I work in email, the less I feel as though there's any consensus in how it is used, beyond the bare minimum required for it to

Re: [dmarc-ietf] Non-solution for DMARC disruption of normal email use while still offering its normal protection

2014-05-30 Thread John Sweet
There's probably no point in coding a patch unless you feel the people responsible for the codebase are likely to apply it. That's a lot of effort down a rathole, especially since some number of the intended audience feel that it's inappropriate to ask them to change anything in their software. It

Re: [dmarc-ietf] alignment and parsing logic as optionals

2014-04-17 Thread John Sweet
On Thu, Apr 17, 2014 at 10:01 AM, Joseph Humphreys < jhumphr...@salesforce.com> wrote: > It's a problem if the service provider wants to offer bounce processing by > using their own domain for the return path, which I think is not uncommon. > That puts SPF out of alignment. > I think the differen

Re: [dmarc-ietf] alignment and parsing logic as optionals

2014-04-17 Thread John Sweet
On Thursday, April 17, 2014 5:44 PM, Joseph Humphreys wrote: > At one time I suggested adding a feature to list domains that could be > considered "in alignment" with yours. So if a domain owner wanted to > authorize an email service provider, they could just add something to their > DMARC policy

Re: [dmarc-ietf] DMARC's purpose

2014-04-10 Thread John Sweet
I was intentionally vague, since several distinct changes have been proposed along those lines. That's definitely one of them. The general objection covers all of them. On Thu, Apr 10, 2014 at 10:07 AM, Kurt Roeckx wrote: > On Thu, Apr 10, 2014 at 06:59:41AM -0700, John Sweet wrote: &

Re: [dmarc-ietf] DMARC's purpose

2014-04-10 Thread John Sweet
very quickly. I'm not clear on how SPF alignment prevents this. My humblest apologies if you already covered the particulars in an earlier message, and I missed it. On Thu, Apr 10, 2014 at 7:04 AM, Dave Crocker wrote: > On 4/10/2014 8:59 AM, John Sweet wrote: > >> I see

Re: [dmarc-ietf] DMARC's purpose

2014-04-10 Thread John Sweet
I see the competing "answers" breaking down differently: - Mailing list implementation/practice must change to support From-header alignment - Never publish a p=reject policy for a domain with human (non-automated) senders "Whitelist known-good MLs" seems to me to be an effective way to elimina

Re: [dmarc-ietf] Limiting what goes in aggregate reports

2014-01-21 Thread John Sweet
I'm not sure whether the feature being requested is a) providing the sender with another DMARC tag to specify that they only want aggregate reports to include failures, or b) receivers, at their discretion, being able to choose to only report failures. I can imagine a valid use case for a), but no

Re: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400

2013-10-31 Thread John Sweet
MAAWG newcomers tend to gravitate to these discussions, so that's part of the reason why it feels like the same questions are asked over and over. FWIW, I knew the answer to the question I asked; I didn't see it in Franck's slides and wanted to hear it answered. I thought some of the people in the

Re: [dmarc-ietf] ADSP to Historic?

2013-09-11 Thread John Sweet
On Sep 11, 2013, at 2:54 PM, Dave Crocker wrote: > So I'd like to ask for comment about an effort to move RFC 5617 to Historical > status. Yes, please. Maybe a wake? I feel like there should be a wake. ADSP, we hardly knew ye. ___ dmarc mailing list