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.
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.
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.
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.
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.
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.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
