I sense another summoning... truncating for clarity... On Mon, Dec 16, 2019 at 9:05 AM Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote: > So at least the second message should probably be different, > if the rule is retained. Easily able to be done. > But this being a community of RFC subject-matter experts, the text is > subject to further scrutiny. +10000000000000 :-) > The name "postconfirm" suggests a component that asks (purported) > senders of borderline messages to confirm their existence/intent to send > the message. One should indeed strive to use that sparingly. Postconfirm is a really nice tool written by the Tools Team that uses an email challenge-response system to confirm unknown people. It has grown to take on a number of other functions for the IETF, including supporting DMARC-rewriting and so forth. It is rock solid, and a pleasure to use. https://ietf.org/about/groups/tools/ https://tools.ietf.org/tools/postconfirmd/ > Do you know which of the two accounts for the bulk of the rejected traffic? A quick check this morning suggests that it is the second rule accounting for the bulk of traffic. > Anyway, perhaps more than you wanted to know, I always want to know and understand more. (Alas, there is always more to know and understand! :-) _ > But if you do want to explore your options further, you could ask on the postfix-users list. I am, and always have been, grateful for the presence and support - and knowledge! - of the community. Very seriously! As a vendor I cannot be a participant, but I am always appreciative of this and the many messages containing support and guidance I've received over the years. But John's original email on this thread explains that - even though I am interested, and even though I want things to "work right" - the decisions about what changes to make, and how to make them, do not rest with me (as the vendor.) I know that I*** leadership is here, and considering everything, and I will be happy to make whatever changes - if any - they direct me to make. Glen
