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
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).
I don't recall being interested in payload authorization when Sender:
and Error-To: were added. It was more about providing all the help in
delivering the "bounce" back to the sender to help in some MLM related
process before List-* headers days. There were still SLIP/UUCP
transports which didn't use the Return-Path, instead used a top "From
" meta-header.
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).
Then DMARC should perhaps remove its reference as "Super ADSP."
ADSP and DMARC have the same overall ideas of using an Author policy
concept. Same problem exist. Same basic issues. Broken for all the
same basic reasons. We just didn't have the urgency back then to
address the problem because of the reputation/trust focus as a
solution. I don't think many took DMARC serious because it was a
"Reporting" tool. I just saw it proving using redundant reports what
we already knew without reports. Its not rocket science. ADSP DISCARD
worked for filtering spoofs and it needed a 3rd party hook to it to
protect the MLM resigner market. We all agreed that a resign needed
to be done in order to resolve the integrity issue.
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.
Its about many things. Laid out all the possible policy boundary
conditions that can be expected when it comes to 1st party signers and
resigners. Thats fundamental in all this because we need to take the
author domain at its word at some point.
Does the author domain have an exclusive signing policy?
Does the author domain allow resigners?
Does the domain only allow authorized resigners, if so, how?
and so on. we only got stuck on that last one. We been able to
separate the issue into a "BIG DATA" registration concern and not a
big issue for a smaller network of potential resigners.
You have to be able to describe this policy via the DMARC lookup.
Then the receivers will have a better want to handle it.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
