Re: [dmarc-ietf] advice to MTAs

>It is mentioned in Section 6, but the mention there doesn't even say that >it's the DMARC result that's supposed to be recorded. That bit at least >needs to be fixed. > >Anyone else have a comment? Recording stuff in A-R is fine. Advice about how MUAs should display them is not. Considering th

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

On Sun, Jun 8, 2014 at 9:06 PM, Hector Santos wrote: > Fundamentally, any From-Corruption (good term to use) concept is bad. 30 > years of mail software/product/hosting development across multiple networks > tells me so, it ethically burns inside me as wrong and I have strong > confidence the IET

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

On 6/9/2014 2:01 AM, Matt Simerson wrote: I also fail to see how this is a security issue. Agreed. It's *really* easy to filter and block delivery for non-existent domains. That is exactly what will be required to mitigate and close this new security hole. if mail.from.tld is ".invalid

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

On Jun 8, 2014, at 10:32 PM, Brandon Long wrote: > The message is already corrupted, or there wouldn't be a problem to be solved. When the message arrives at the list, it's unlikely that it's already corrupted. What has been described is corrupting the From header by the same entity that is a

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

On 6/8/2014 10:26 PM, Murray S. Kucherawy wrote: To express how strong I feel about this If there is a charter for a new DMARC WG work, you can bet I will request that any form of 5322.From-Corruption concept be considered OFF TOPIC and OUT OF SCOPE in the new WG charter exc

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

On Sun, Jun 8, 2014 at 3:39 PM, Hector Santos wrote: > On 6/8/2014 1:00 PM, Stephen J. Turnbull wrote: > >> Phillip Hallam-Baker writes: >> >> > NNTP was designed 30 years ago. We should consider moving on. >> > The modern protocol world is JSON/REST >> >> That's off-topic for this list, IMO,

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

On 6/8/2014 1:00 PM, Stephen J. Turnbull wrote: Phillip Hallam-Baker writes: > NNTP was designed 30 years ago. We should consider moving on. > The modern protocol world is JSON/REST That's off-topic for this list, IMO, and I don't intend to discuss it unless the moderator(s) make clear that

Re: [dmarc-ietf] advice to MTAs

> Hector Santos wrote: > >> It is mentioned in Section 6, but the mention there doesn't even say >> that it's the DMARC result that's supposed to be recorded. That bit >> at least needs to be fixed. >> >> Anyone else have a comment? > > Only that it goes back to the similar SPF thing regarding

Re: [dmarc-ietf] advice to MTAs

On Sunday, June 8, 2014 5:30 PM, Murray S. Kucherawy wrote: > I'm not so sure about the SHOULD i would stay with SHOULD/MUST combo. i would, actually, even suggest it to be MUST/MUST combo, but i leave that to general consensus, as there may be reasons not to go so strong, which i'm not curren

Re: [dmarc-ietf] advice to MTAs

On 6/8/2014 11:30 AM, Murray S. Kucherawy wrote: On Sun, Jun 8, 2014 at 12:25 AM, Vlatko Salaj Only that it goes back to the similar SPF thing regarding dynamic rejections. So to be consistent for DMARC: DMARC POLICY A-R Trace Guideline REJECT --> N/A see 55x reply codes. QUARANTI

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

Stephen, Thanks for the comments... On 6/7/2014 8:08 PM, Stephen J. Turnbull wrote: > Two nits to pick. First, I'd like a whole (sub)section (containing > approximately one sentence :-) for Mediator responsibilities, even if > it's redundant with step 4 of the specification. Maybe a subsection

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

On 6/8/2014 2:46 PM, Phillip Hallam-Baker wrote: > NNTP was built to save bandwidth, Flooding protocols do not do a very good job of saving bandwidth. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org http

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

On 6/8/2014 7:00 PM, Stephen J. Turnbull wrote: > The mention of Usenet suggested a completely "out of the box" way to > sidestep DMARC impact by avoiding SMTP entirely, using NNTP as an > alternative transport. I merely wanted to make it clear that GNU > Mailman is *technically* prepared to think

Re: [dmarc-ietf] advice to MTAs

On 6/8/2014 7:18 PM, Stephen J. Turnbull wrote: > If we want to > ask the MUA developers to do something to inform the end user about > authentication results, we sure as shooting should put our protocol > where our mouth is by putting in a requirement that MTAs give them > that information. Havi

Re: [dmarc-ietf] Next IETF Meeting DMARC Related Talks

On 06/08/2014 08:41 AM, Murray S. Kucherawy wrote: > On Sat, Jun 7, 2014 at 11:32 PM, John C Klensin > wrote: > > Murray, you didn't mention whether there is any ongoing > discussion in dmarc.org and, if so, how Hector > can participate >

Re: [dmarc-ietf] advice to MTAs

Murray S. Kucherawy writes: > I'm not so sure about the SHOULD because the only interoperability > A-R enables is stuff between the verifiers and the MUAs and humans, > really. It certainly wouldn't be a bad idea for us to highlight > how useful it would be though. I'm in strong agreement wi

Re: [dmarc-ietf] advice to MTAs

Franck Martin writes: > So I'm happy with advice to MTA, and I still think we should do an > advice to the MUA, by telling what is important to us. I think the BCP is the appropriate place for recommendations to the MUA. SPF, DKIM, and DMARC are a couple of protocol layers lower than what MUA d

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

Phillip Hallam-Baker writes: > NNTP was designed 30 years ago. We should consider moving on. > The modern protocol world is JSON/REST That's off-topic for this list, IMO, and I don't intend to discuss it unless the moderator(s) make clear that it is on-topic. What I believe is on-topic is that

Re: [dmarc-ietf] Next IETF Meeting DMARC Related Talks

--On Sunday, June 08, 2014 08:50 +0200 Dave Crocker wrote: > On 6/8/2014 8:32 AM, John C Klensin wrote: >> Murray, you didn't mention whether there is any ongoing >> discussion in dmarc.org and, if so, how Hector can participate >> there. > > That's because Hector is already active in the IET

Re: [dmarc-ietf] advice to MTAs

- Original Message - > From: "Murray S. Kucherawy" > To: "Vlatko Salaj" > Cc: dmarc@ietf.org > Sent: Sunday, June 8, 2014 5:30:33 PM > Subject: Re: [dmarc-ietf] advice to MTAs > On Sun, Jun 8, 2014 at 12:25 AM, Vlatko Salaj < vlatko.sa...@goodone.tk > > wrote: > > imo, what all current

Re: [dmarc-ietf] Next IETF Meeting DMARC Related Talks

On Sat, Jun 7, 2014 at 11:32 PM, John C Klensin wrote: > Murray, you didn't mention whether there is any ongoing > discussion in dmarc.org and, if so, how Hector can participate > there. If there are no further discussions there and dmarc.org > is turning change control over to the IETF, it migh

Re: [dmarc-ietf] advice to MTAs

On Sun, Jun 8, 2014 at 12:25 AM, Vlatko Salaj wrote: > imo, what all current DMARC deployments lack is notice to > end receiver mailbox about any DMARC validation done on a > particular message, and how it validated. > > thus, similarly to Franck's Advice to MUAs, i would propose > adding this ki

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

On Sat, Jun 7, 2014 at 12:38 PM, Stephen J. Turnbull wrote: > I'm not sure what the long list of addressees was about, but I'm not > comfortable with them. Feel free to repost my message if you wish. > > Phillip Hallam-Baker writes: > > > In the medium term, lets kill the stupidity of mailing li

Re: [dmarc-ietf] Next IETF Meeting DMARC Related Talks

--On Saturday, June 07, 2014 21:34 -0700 "Murray S. Kucherawy" wrote: > On Sat, Jun 7, 2014 at 2:58 PM, Hector Santos > wrote: > >> I might be interested in remote participation at the next >> IETF 90 meeting if there are any DKIM/DMARC related meetings >> scheduled. >> >> I have not seen an

Re: [dmarc-ietf] Next IETF Meeting DMARC Related Talks

On 6/8/2014 8:32 AM, John C Klensin wrote: > Murray, you didn't mention whether there is any ongoing > discussion in dmarc.org and, if so, how Hector can participate > there. That's because Hector is already active in the IETF's DMARC discussion list, which was an addressee of your note, as it is

Re: [dmarc-ietf] 3rd party alignment DMARC upgrade moving to RFC

On 6/8/2014 5:13 AM, Vlatko Salaj wrote: i consider my 3rd party alignment support for DMARC easy to understand, trivial enough to deploy and useful enough to cover many use cases, so i would like to move it to IETF as a, probably, independent RFC. does anybody here see interest in helping me ou

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

On 6/8/2014 12:38 PM, John Levine wrote: > In article <5393423a.2000...@gmail.com> you write: >> On 6/7/2014 6:38 PM, Stephen J. Turnbull wrote: >>> I don't know what the problem that prevented netnews from >>> obsoleting mailing lists is >> >> At base, netnews and mailing lists are entirely differ

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

In article <5393423a.2000...@gmail.com> you write: >On 6/7/2014 6:38 PM, Stephen J. Turnbull wrote: >> I don't know what the problem that prevented netnews from >> obsoleting mailing lists is > >At base, netnews and mailing lists are entirely different kinds of human >communication services. The c

Re: [dmarc-ietf] confusing 3rd party support so it remains out

Dave Crocker wrote: >On 6/7/2014 4:37 PM, Franck Martin wrote: >> Yahoo has been suggesting the ESPs use OAUTH, so the small business owner, >> can authorize >the ESP to post on its behalf via yahoo servers� Not sure if it is today >possible, but there >is a bunch of apps that has been granted

Re: [dmarc-ietf] 3rd party alignment DMARC upgrade moving to RFC

On Sunday, June 8, 2014 11:13 AM, Vlatko Salaj wrote: > i consider my 3rd party alignment support for DMARC > easy to understand, trivial enough to deploy and > useful enough to cover many use cases, so i would > like to move it to IETF as a, probably, independent > RFC. if u missed it, it's he

[dmarc-ietf] 3rd party alignment DMARC upgrade moving to RFC

i consider my 3rd party alignment support for DMARC easy to understand, trivial enough to deploy and useful enough to cover many use cases, so i would like to move it to IETF as a, probably, independent RFC. does anybody here see interest in helping me out with this procedure? u should have good e

[dmarc-ietf] advice to MTAs

imo, what all current DMARC deployments lack is notice to end receiver mailbox about any DMARC validation done on a particular message, and how it validated. thus, similarly to Franck's Advice to MUAs, i would propose adding this kind of txt to DMARC draft: "DMARC participating MTAs SHOULD inclu