Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy

On 5/15/15 5:09 PM, Terry Zink wrote: > Hector, > >> You should give DMARC+ATPSrev4 a shot. It works great. > My perception of your +1 to your solution is this: "I run my own mail server > and moderate my own DNS zone. I have a couple of users on my domain. > Everything works so easy." > > Yet

Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy

> On May 15, 2015, at 8:09 PM, Terry Zink wrote: > > Hector, > >> You should give DMARC+ATPSrev4 a shot. It works great. > > My perception of your +1 to your solution is this: "I run my own mail server > and moderate my own DNS zone. I have a couple of users on my domain. > Everything works

Re: [dmarc-ietf] Sender: vs. From: (was Re: Simple authorization offers reasonable control over messaging resources)

On 5/15/15 8:52 AM, Dave Crocker wrote: > On 5/14/2015 11:27 PM, Terry Zink wrote: >>> The Sender header field when present has been defined for decades >>> to represent the sending agent! >> Maybe, maybe not. > > Sorry, but there isn't much maybe about it. > > The definition in the spec has bee

Re: [dmarc-ietf] Sender: vs. From: (was Re: Simple authorization offers reasonable control over messaging resources)

On 5/15/2015 11:52 AM, Dave Crocker wrote: But it is not an operationally practical choice. The problem is that when that identifier is different from the content identifier, we have the task of figuring out whether the identity in the Sender: field is 'authorized' to operate on behalf of the i

[dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy

G'day. In looking for ways to make a DMARC-style function succeed when the message transits an intermediary, the current approach has mostly been proposing one or another wholesale solution. This creates a complex space for discussion and tends towards some version of deadly embrace. It might be

Re: [dmarc-ietf] Sender: vs. From: (was Re: Simple authorization offers reasonable control over messaging resources)

On 5/15/2015 12:35 PM, Murray S. Kucherawy wrote: > On Fri, May 15, 2015 at 8:52 AM, Dave Crocker > wrote: > > [*] In case folk miss the point, the Sender identifier is /always/ > present, even when the Sender: field is not. If this isn't clear to > anyone,

Re: [dmarc-ietf] Sender: vs. From: (was Re: Simple authorization offers reasonable control over messaging resources)

On Fri, May 15, 2015 at 8:52 AM, Dave Crocker wrote: > > [*] In case folk miss the point, the Sender identifier is /always/ > present, even when the Sender: field is not. If this isn't clear to > anyone, I encourage re-reading Section 3.4.2 of RFC 5322. > Did you mean 3.6.2? -MSK _

Re: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources

> -Original Message- > From: Hector Santos [mailto:hsan...@isdg.net] > Sent: Friday, May 15, 2015 2:04 PM > To: MH Michael Hammer (5304) > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Simple authorization offers reasonable control over > messaging resources > > On 5/15/2015 11:07 AM, M

Re: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources

On 5/15/2015 11:07 AM, MH Michael Hammer (5304) wrote: This is one of the reasons I have held back from participating in the discussions/attempts to come up with authorizations for unrelated 3rd parties. Even recognizing the resistance from various quarters, 3rd parties and intermediaries (

Re: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources

On 5/15/2015 11:07 AM, MH Michael Hammer (5304) wrote: Maybe, maybe not. Sender is a RFC822 header (since the 80s). Its been around for a long time. Our MLS added it along with the "Error-To" for MLM operations. No option to disable that. I believe we stole the idea from the original listse

[dmarc-ietf] Sender: vs. From: (was Re: Simple authorization offers reasonable control over messaging resources)

On 5/14/2015 11:27 PM, Terry Zink wrote: >> The Sender header field when present has been defined for decades >> to represent the sending agent! > > Maybe, maybe not. Sorry, but there isn't much maybe about it. The definition in the spec has been clear since the construct was invented, in 1977

Re: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources

> -Original Message- > From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Hector Santos > Sent: Friday, May 15, 2015 9:09 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Simple authorization offers reasonable control over > messaging resources > > On 5/15/2015 2:27 AM, Terry Zi

Re: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources

On 5/15/2015 2:27 AM, Terry Zink wrote: The Sender header field when present has been defined for decades to represent the sending agent! Maybe, maybe not. Sender is a RFC822 header (since the 80s). Its been around for a long time. Our MLS added it along with the "Error-To" for MLM operatio

Re: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources

On Thu, May 14, 2015 at 11:27 PM, Terry Zink wrote: > > The Sender header field when present has been defined for > > decades to represent the sending agent! > > Maybe, maybe not. Outlook desktop client shows the Sender: header as > " on behalf of <5322.from>", but neither Hotmail/outlook.com nor