> -----Original Message----- > From: dmarc [mailto:[email protected]] On Behalf Of Hector Santos > Sent: Friday, May 15, 2015 9:09 AM > To: [email protected] > Subject: 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 operations. > No option to disable that. I believe we stole the idea from the original > listserv or rather we just wanted a way to give the BOUNCE guy or your own > SERVER a way distinguish the type of mail you were seeing. Error-To mean it > was for the list. >
We need to be careful when we assert meanings to terms in older RFCs. If you look at RFC822 Appendix A, none of the examples for the Sender field use a fully qualified hostname where the sender is in a different domain than From. This implies that the original intent of the Sender field was not to authorize unrelated 3rd parties to be the Sender on behalf of the From (party). > > The TPA authorization DNS zone publishing has been pushed by yourself > and another board participant and has received universally negative > feedback, or at best neutral feedback. The people here are smart and have > as much experience as anyone else and they understand what you are > saying. But they still don't agree, including me. I think it's time to make > like > the movie Frozen and let it go. > > > > -- Terry > > Terry, > > Once about the time, SPF was put down (not supported) by the same > "smart" folks leading or participating in the DKIM project and related > projects. > > SSP/ADSP was also put down only for the "Super ADSP" DMARC version to > be resurrected by the "smart" folks. Same ideas, same problems, but with a > different language. > I disagree with this assertion Hector. I was one of the folks arguing in favor of policy over reputation. ADSP was moved forward but in the end was fundamentally broken. DMARC is not "Super ADSP", there are some fundamental differences. I declined to participate in the predecessor project to DMARC because I felt it to had issues (and in hindsight I guess I was right - it was stillborn). > The "smart" folks also said: > > 1) No one will use POLICY protocols, and even if they did, > 2) No one will published restrictive policies, and even if they did, > 3) No receiver will honor them anyway, so whats the point? > > The "smart" folks were wrong on these DKIM Policy Framework counts. > > In other words, if by smart you mean, "consensus," then in all honesty, the > consensus doesn't have a good track record in leading the DKIM project. > Sometimes consensus works - sometimes it doesn't. Sometimes not attempting consensus works - sometimes it doesn't (MARID working group). > So please excuse me, and I don't mean any disrespect, if I am not too > confident or excited with the direction you would like to take this DKIM > project. The odds are very high, based on history, based on the leadership of > this DKIM project, we are heading down another failed path with more patch > work, more kludges, more "spaghetti code" and quite frankly, inadequate > integrated work. > 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 (which modify messages) taking responsibility for messages they emit is ultimately the cleanest and most workable approach. Yes it requires change on the part of some (I'm waiting for shouts of "GET OFF MY VIRTUAL LAWN"). > We are all tired of this, I suppose. I've been at it since 2003. The DNS > Lookup > query is the *ideal* IETF protocol solution and that should be one of the > working documents completed and released as an Experimental Protocol. > > Whether the private or public domain can or can not, is not the issue > because that is always going to be the case. Many will say its > really not for the hotmail.coms, its too spam polluted. That was what was > meant when many didn't believe domains will not publish records. > So it was surprising Yahoo.com created a hard policy, its also spam polluted. > It isn't about whether a domain is spam polluted (as you call it), it is whether a domain can be abused by mail claiming to be from it but which emanates from somewhere else. These are two different issues. It is also about whether a domain owner/administrator has the right/authority to determine how it's domain is used. > But policy advocates can also understand why it was done. You can instantly > begin to clean up a domain by using tight SMTP policies. > The small nimbler guys were able to do it and prove it for a long time and we > also serve ISPs, ESPs and MLMs operations with our wares! > > If you want an IETF solution, the DNS Lookup query is the easiest. > Bottom line. The registration thing is a side track and maybe "smarter" > people than us can figure that out -- and I predict someone will. So I highly > recommend the IETF get ready for it, we prepare the DNS I/O protocol model > for this, in the same way we did with DKIM STD for the Trust as a function of > the SDID. > > Policy = DKIM_POLICY(ADID, SDID=NULL) > Trust = DKIM_TRUST(SDID, AUID=NULL) > > Note the ADID and AUID are different. > > These were the conceptual DKIM POLICY+TRUST modelings we been fussing > with for a long time. > > Lets not make it so complicated, get back to basic and get it done already -- > independent of registration part. I am sure we will have plenty to say about > this component and for the most part, MOST people can handle it. Maybe > the hotmails can't and thats normal. It can't handle SPF either anyway. > _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
