On 7/8/2023 3:22 PM, Tero Kivinen wrote:
Scott Kitterman writes:
You can equally argue that these receivers are merely following the
policy advice provided by the sending domain (it has reject right in
the name) and this problem is entirely generated by sender's
inappropriate use of p=reject.
True, thats why the proposed text also says you SHOULD NOT put
p=reject... :-)
If this is a SHOULD NOT mandate for the publisher, then for the
compliant receiving verifier it can be translated to:
1) Verifier SHOULD ignore p=reject domains, or
2) Verifier MAY ignore p=reject domains.
Which one is better? Is this good to have in the specs?
I don't think engineering the location where the blame lands is the
right place to focus. I've done plenty of blame avoidance
engineering in my day, but I don't think it's what the IETF should
be doing.
It would be much better when people would really remember that having
valid or not valid DMARC/DKIM/SPF for email does not tell anything
whether the email is bad/spam/unwanted.
Well, my philosophy has always been SPF and DKIM Policy modeling was
about deterministic negative filtering of the mail stream. Getting
rid of the junk with minimal false positives before feeding it to the
next stage.
It does not say the valid sender is good or bad. That would be a
reputation trust design issue we have not resolved as a IETF community
standard yet (see VBR note below).
They say there are big systems using proprietary Reputation Engines,
but the community does not have access to them. Consider, if big
systems are willing to pay a fee to the validation receiver to do a
"Good or Bad Mail" lookup at ACME Reputation service that would be
interesting and long sought by some early explorers. Yes, I said, Big
guy pay the Small guy for handling their spam correctly because there
is a significant cost associated with receivers processing mail.
Unfortunately, this would be the classic "Batteries Required" syndrome
where a receiver would need to buy and/or install branded batteries to
get that 2nd Reputation layer. If this SaaS was to materialize, what
may happen are Bad Guys beginning to target receivers who lack the
Reputation batteries or have different batteries. Smaller receivers
may be hurt by this.
Regardless whether the DMARC/DKIM/SPF is valid you always need to use
other methods to filter emails, so as you need to do that anyways
while receiving emails, there is no problems of using same things also
for p=reject messages. You can use the failed dmarc with p=reject as
one of the inputs to feed your actual email filtering system, the
dmarc p=reject SHOULD NOT BE your only email filtering system.
The combination of rules and logic that works best as a whole is
indeed a holy grail item, a golden egg at the end of the rainbow, etc.
But we do have reputation folks who believe that is all we need -
subjective reputation method. It doesn't matter what SPF or DMARC says
as long as the receiver trust the last signer. It is part of the
DKIM-BASE specs for the assessment concept.
The problem has been what other identities do we need? As DMARC has
shown, there are many DKIM Policy advocates who believe valid 1st
party Author published policies about their mail system is a good
thing. DMARC proposed the following identities are part of the PASS
evaluation equation:
SignerID 5322.Dkim-Signature "d=" domain
AuthorID 5322.From domain
UserAgentID 5322.Dkim-Signature "i=" domain/address
ReturnPathID 5321.MailFrom Domain
In summary, for me, its about filtering the failures of the protocol
rules established. If publisher says ABC and Receiver sees XYZ, there
is a detectable condition to work with. Do this first and you have a
"cleaner" stream to apply some reputation logic.
Levine's VBR "Vouch By Reference" RFC 5598 was suppose to do this part
for us. Once the mail is clean (everything is a pass), you do a VBR
look up as a function of the signer id, the author id and some
"category" tag designed for marketers. That was suppose to be an
Authorized Good Reputation lookup, I believe.
In my opinion, when VBR was invented in 2009, I didn't think VBR was
ready for prime time and people were resisting the idea of a central
repository for reputation, who owns it? But almost 15 years later,
maybe it would be more acceptable today? Only the editors of the VBR
proposal can speak as to why it wasn't pushed or help.
--
Hector Santos,
https://santronics.com
https://winserver.com
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
