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

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] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

Elizabeth Zwicky writes: > No, I mean to say that "never stopped" does not mean "never slowed > down", it means "never stopped". OK. I'll remember that. In any case, now I wonder what they're really trying to do. They can check for "p=reject" without sending *any* mail. (I know, you're not

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

On 6/12/14, 3:59 PM, "Stephen J. Turnbull" wrote: >Elizabeth Zwicky writes: > > > I did not say that the levels were the same; I said the attackers > > have not gone away. They are not at high volume, but they're sure > > sitting there checking to see whether or not it's working. > >What you sa

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

Franck Martin writes: > > The problem there is that not all lists use the List-* fields. > > Well, if they don't use these headers, I don't think they would > make any other modification for any upcoming scheme. I don't think that's a good heuristic. Most of the schemes we're talking about

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

Printed on recycled paper! > On Jun 12, 2014, at 21:54, "Murray S. Kucherawy" wrote: > >> On Thu, Jun 12, 2014 at 12:33 PM, Elizabeth Zwicky >> wrote: >> >> >> On 6/12/14, 9:36 AM, "Terry Zink" wrote: >> >> >> Franck Martin wrote: >> >> >> >> I found that to build the override list for m

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

Murray S. Kucherawy writes: > Interesting. So DKIM-Delegate is syntactically the same as DKIM-Signature, > but with augmented semantics? Or did you have something else in mind? That's what I had in mind. But the semantics are not merely augmented, they're conceptually different. DKIM-Delega

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

On Jun 12, 2014, at 5:04 PM, Stephen J. Turnbull wrote: > Matt Simerson writes: > >> I'm not sure we need to be considerate of such behavior. If it's >> malware, reject it outright. > > Can't do that. Many viruses attach themselves to legitimate messages. > If the author is the boss, rejectin

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

Phillip Hallam-Baker writes: > My point is that mail is an old protocol and people who expect that > it can be kept going unaltered in its original form serving all the > purposes that it was never designed for but have emerged over time > are going to be upset no matter what. True, as far as

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

Matt Simerson writes: > I'm not sure we need to be considerate of such behavior. If it's > malware, reject it outright. Can't do that. Many viruses attach themselves to legitimate messages. If the author is the boss, rejecting it would be, uh, bad. Steve _

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

Terry Zink writes: > > Franck Martin wrote: > > > > I found that to build the override list for mailing list, I could > > log DMARC rejected emails that contained a List-Id or List-Post > > header. Once reviewing the logs (once a week, or once a month), > > you can make an easy decision if y

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

On Thu, Jun 12, 2014 at 4:05 PM, Stephen J. Turnbull wrote: > Can't both the version bump issue and the token signature issue be > ameliorated by incorporating the token signature in the DKIM-Delegate > field? > > There's a protocol collision on the t= tag which would need to be > addressed, but

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

John R Levine writes: > > And humor aside, please state the technical changes to the existing DKIM > > specification that are being made with DKIM-Delegate. > > If a signature has an rsf= tag, verifiers ignore it unless there's a > matching signature from a domain the rsf= points to. > >

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

Elizabeth Zwicky writes: > I did not say that the levels were the same; I said the attackers > have not gone away. They are not at high volume, but they're sure > sitting there checking to see whether or not it's working. What you said, exactly, is But I do, in fact, have data, and that da

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

Dave Crocker writes: > On 6/12/2014 11:58 AM, Stephen J. Turnbull wrote: > > Dave Crocker writes: > > > > > The scenario being discussed is for a recipient who gets both signatures > > > when they are valid, but who does not know about DKIM-Delegate. > > > > I didn't understand that from

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

On Jun 12, 2014, at 12:33 PM, Elizabeth Zwicky wrote: > On 6/12/14, 9:36 AM, "Terry Zink" wrote: > > -- there are also all the non-transparent forwarders (for instance, > enterprise systems which do malware filtering on mail). And those system are going to do malware filtering on the message

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

On Thu, Jun 12, 2014 at 12:33 PM, Elizabeth Zwicky wrote: > > > On 6/12/14, 9:36 AM, "Terry Zink" wrote: > > >> Franck Martin wrote: > >> > >> I found that to build the override list for mailing list, I could log > >>DMARC rejected > >> emails that contained a List-Id or List-Post header. Once r

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

On 6/12/14, 9:36 AM, "Terry Zink" wrote: >> Franck Martin wrote: >> >> I found that to build the override list for mailing list, I could log >>DMARC rejected >> emails that contained a List-Id or List-Post header. Once reviewing the >>logs >> (once a week, or once a month), you can make an e

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

> -Original Message- > From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Terry Zink > Sent: Thursday, June 12, 2014 12:37 PM > To: Franck Martin; Matt Simerson > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. > > > Franck Martin wrote:

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

> Phillip Hallam-Baker writes: > > As Craster insists: My domain, my rules. True. But Craster gets killed by getting stabbed in the neck. -- Terry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

Phillip Hallam-Baker wrote: On Wed, Jun 11, 2014 at 1:00 PM, Martin Rex > wrote: Phillip Hallam-Baker wrote: > Hector Santos mailto:hsan...@isdg.net>> wrote: >> >> Let me ask, what if a fedex.com employee use this email domain for

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

On Thu, Jun 12, 2014 at 12:53 AM, Vlatko Salaj wrote: > > DKIM-Delegate does not need or use any externally-maintained list. > > please, solve this spoofing example: > Asked and answered already, here (and elsewhere): http://www.ietf.org/mail-archive/web/dmarc/current/msg01250.html There's no n

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

> DKIM-Delegate does not need or use any externally-maintained list. please, solve this spoofing example: 1. so, a sender sends DKIM-D with every email, regardless whether    it is meant for a mailing list or not, cause they maintain no    whitelist to make a difference, 2. sender sends an emai

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

On Wed, Jun 11, 2014 at 1:00 PM, Martin Rex wrote: > Phillip Hallam-Baker wrote: > > Hector Santos wrote: > >> > >> Let me ask, what if a fedex.com employee use this email domain for > >> subscribing to the IETF list? > > > > Any subsequent problems are irrelevant unless FedEx, the owner of > >

[dmarc-ietf] Checking Signing Practices (CSP)

Please define "fault". Also "lookup". I doubt I'm the only one who doesn't understand what you mean by these words. A lookup is a callout, a shim, a hook, a "blackbox" query, a "function generator" and so on. In this case, the lookup is a DNS-based query. We can today offer a practical funct

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

> Franck Martin wrote: > > I found that to build the override list for mailing list, I could log DMARC > rejected > emails that contained a List-Id or List-Post header. Once reviewing the logs > (once a week, or once a month), you can make an easy decision if you want to > add the found IPs in

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

- Original Message - > From: "Matt Simerson" > To: dmarc@ietf.org > Sent: Wednesday, June 11, 2014 11:13:55 PM > Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. > > > On Jun 10, 2014, at 10:15 PM, Stephen J. Turnbull wrote: > > > Matt Simerson writes: > > > >>

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

Hi Murray, On Tue 10/Jun/2014 19:56:30 +0200 Murray S. Kucherawy wrote: > 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 signa

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

On 6/12/14, 3:10 AM, "Stephen J. Turnbull" wrote: >John R Levine writes: > > > For this application I don't see x= as much protection. If a bad guy > > subscribes to the list or gets messages via something like gmane, he > > can do the mutate and spam in close to real time. > >Is this a prac

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

And humor aside, please state the technical changes to the existing DKIM specification that are being made with DKIM-Delegate. If a signature has an rsf= tag, verifiers ignore it unless there's a matching signature from a domain the rsf= points to. This is not backward compatible, since verif

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

John R Levine writes: > For this application I don't see x= as much protection. If a bad guy > subscribes to the list or gets messages via something like gmane, he > can do the mutate and spam in close to real time. Is this a practical concern, though? The levels of spam etc that drove Yahoo

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

On 6/12/2014 11:58 AM, Stephen J. Turnbull wrote: > Dave Crocker writes: > > > The scenario being discussed is for a recipient who gets both signatures > > when they are valid, but who does not know about DKIM-Delegate. > > I didn't understand that from previous posts. At least Hector seems >

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

Dave Crocker writes: > The scenario being discussed is for a recipient who gets both signatures > when they are valid, but who does not know about DKIM-Delegate. I didn't understand that from previous posts. At least Hector seems to be concerned (though not exclusively so) with the case I pres

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

On 6/12/2014 10:32 AM, John R Levine wrote: > We disagree. Yup. But I don't mind your being wrong... And humor aside, please state the technical changes to the existing DKIM specification that are being made with DKIM-Delegate. Keep in mind the fact that TCP uses IP, and does not change it.

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

There is nothing about DKIM-Delegate that changes DKIM. We disagree. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ dmarc mailing list dmarc@ietf.org https:/

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

On 6/12/2014 10:12 AM, John R Levine wrote: > Adding a new tag doesn't need a version bump so long as it's OK for > verifiers that don't understand the tag to ignore it. This needs a > version bump since the intention is that the signature isn't interesting > unless it's paired with a forwarder's

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

Answering four messages at once: > Someone sends off a message to a mailing list with the two DKIM > signatures and DKIM-Delegate. Someone else, perhaps a list > subscriber, notes that the weaker signature doesn't cover the body, so > he replaces the body with nose enlargement spam and blasts i

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

Matt Simerson writes: > That just seems to reinforce the point that the message alterations > are far more popular with list *operators* than they are with list > *users.* *shrug* List operators are my constituency. If you, as a list (site) operator, choose to do things differently, more powe

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

Hector Santos writes: > > You would simply not use DKIM-Delegate if that's your policy. > > Again, the fault. Please define "fault". Also "lookup". I doubt I'm the only one who doesn't understand what you mean by these words. > The policy is X, but Y is seen. The payload can be > DKIM-