Hiya, Thanks for taking a read of the draft.
On 04/03/2020 04:55, Ben Schwartz wrote: > I'm still not entirely clear on how this is supposed to work, which is why > I would appreciate the worked example. It seems like, in addition to RDBD, > your filter also needs some kind of "appears-related" heuristic, and a list > of "high-trust" domains, on the theory that one should block messages > containing repudiated domains that look similar to a high-trust domain. > However, I don't think this is likely to be a reasonable use of the > existing rdbd-tags, neither of which amounts to an accusation of phishing > per se. (Consider, for example, the entire ".sucks" TLD.) Tend to agree that new tags are likely needed any time one wants better-defined semantics. (That's maybe the core of the design attempt here.) > Regardless of the use case, I think a more detailed example would be > helpful for understanding what heuristics are needed, and to what extent > RDBD would make the use case easier. Ack. Will try add something. Cheers, S.
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
