On 30 Mar 2023, at 10:32, Douglas Foster wrote:
Here is a quick attempt at a definition:
Interoperability:Two (or more) entities cooperating to achieve a
mutual
objective"
Not quite. If a third party does something that causes failure even when
two entities do cooperate on their mutual
On March 29, 2023 9:40:39 PM UTC, Todd Herr
wrote:
>Colleagues,
>
>Can someone please point me to a mailing list server or other indirect mail
>flow that I might somehow engage with so that I can experience the pain of
>not having a message reach its destination when sent with a policy of
>p=r
On Thu, Mar 30, 2023 at 11:01 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Someone please explain to me why everyone should make themselves more
> vulnerable to ransomware and other attacks so that mailing lists can avoid
> being inconvenienced and avoid having secure operatin
> Our spec needs to fix the evaluators, and their products, not the sender
policy.
No: it should be doing both.
Let’s look at it this way:
Suppose a general-use email provider called “Hooya” promulgated a policy
that said receiving domains should bounce any message from a hooya.com
sender that w
If my cigarette smoke inconveniences 100 people on my plane flight, should
I come prepared to go smokeless or should they come prepared with masks?
The mailing list problem is created by mailing list practices, and it is
the mailing lists problem to solve the problem they created.
We actually have
Here is a quick attempt at a definition:
Interoperability:Two (or more) entities cooperating to achieve a mutual
objective"
Interoperability can perhaps be illustrated by design for a VPN tunnel or
other encryption mechanism:
1) You have to know the identity of the other party. It does not
It appears that Murray S. Kucherawy said:
>-=-=-=-=-=-
>
>On Thu, Mar 30, 2023 at 8:56 AM Barry Leiba wrote:
>
>> 2. Without the workaround, the real pain is not that a message from
>> Comcast posted to the list doesn't get to you (though that's true): the
>> real pain is that if Valimail reject
It appears that Todd Herr said:
>Can someone please point me to a mailing list server or other indirect mail
>flow that I might somehow engage with so that I can experience the pain of
>not having a message reach its destination when sent with a policy of
>p=reject?
>
>I post to various IETF mail
It appears that Murray S. Kucherawy said:
>-=-=-=-=-=-
>
>On Wed, Mar 29, 2023 at 8:59 PM Douglas Foster <
>dougfoster.emailstanda...@gmail.com> wrote:
>
>> MUST seems to take us back to the unfinished debate of 3 years ago, where
>> some asserted that DMARC did more harm than good and should onl
On Thu, Mar 30, 2023 at 7:30 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> There is no interoperability problem.
>
How are you defining interoperability?
"p=reject" when used on domains that send non-transactional messages
disrupts interoperability of the email ecosystem in w
On Thu, Mar 30, 2023 at 8:56 AM Barry Leiba wrote:
> 2. Without the workaround, the real pain is not that a message from
> Comcast posted to the list doesn't get to you (though that's true): the
> real pain is that if Valimail rejects (bounces) those messages, the Mailman
> software will eventual
1. IETF has installed a very ugly workaround to the problem, rewriting the
"from" header field. It's absolutely a workaround, and not a proper
solution.
2. Without the workaround, the real pain is not that a message from Comcast
posted to the list doesn't get to you (though that's true): the real
There's no need for me to define it: I intentionally did not word my
proposed text that way. I think my proposed text is clear about who MUST
NOT use p=reject and why... and, as I said in my response to Scott, I'm
happy to add an explicit statement that it's an issue of interoperability
with exist
I'm happy with that suggestion.
Barry
On Thu, Mar 30, 2023 at 6:00 AM Scott Kitterman wrote:
>
> Would you feel any better if the MUST NOT was followed by 'to preserve
> interoperability '? That's implicitly there and I believe technically
> correct. If you value other properties of the syst
I have a question for the group; I have read RFC7960, but I feel my
question merits reiteration for those of us on this list (like me) that
may have differing opinions on this topic from experience as a consumer
of the standard, and having worked with many of these "general purpose"
domains at
There is no interoperability problem.
An evaluator has an unlimited right to block any incoming message for any
reason.
Specifically, an evaluator has the right to block any message which he
determines to be insufficiently authenticated.
If a sender wants a message to be accepted, he carries the
Colleagues,
Can someone please point me to a mailing list server or other indirect mail
flow that I might somehow engage with so that I can experience the pain of
not having a message reach its destination when sent with a policy of
p=reject?
I post to various IETF mailing lists from my work addr
Would you feel any better if the MUST NOT was followed by 'to preserve
interoperability '? That's implicitly there and I believe technically correct.
If you value other properties of the system higher than interoperability, then
the advice may not apply, which is fine.
Scott K
On March 29, 2
Suppose we use your language. Some domains will still reject your advice,
so evaluators still need to apply intelligence to their disposition
decisions, if they care about pleasing their account holders.
Mailing lists take a calculated risk by forwarding with changes. Doing so
creates a trust p
On Wed 29/Mar/2023 15:25:19 +0200 Murray S. Kucherawy wrote:
On Wed, Mar 29, 2023 at 8:59 PM Douglas Foster wrote:
MUST seems to take us back to the unfinished debate of 3 years ago, where
some asserted that DMARC did more harm than good and should only be used
for transactional mail, which se
On Wed, Mar 29, 2023 at 10:15 AM Barry Leiba
wrote:
> I'm very much against text such as this, as I think it encourages
> deployments that are contrary to interoperability and to the intent of
> p=reject.
>
> I contend that p=reject (as with the similar construct in the older ADSP)
> was intended
I’m just not sure how we determine what is high-value.
comcast.com: p=reject
comcast.net: p=none
xfinity.com: p=quarantine
The top one is corporate, middle is consumer, bottom is consumer (but not
actually used) & customer comms (sub-domains). They’re all used in various
ways for internal mess
I'm very much against text such as this, as I think it encourages
deployments that are contrary to interoperability and to the intent of
p=reject.
I contend that p=reject (as with the similar construct in the older ADSP)
was intended for high-value domains and transactional mail, and that it was
n
On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick wrote:
> If you agree that interoperability is increased, then I'd suggest that you
> actually do agree that the proposed text is appropriate.
>
>
> I don't know that I agree that interoperability is increased...
I'm having trouble squaring proposed l
On Wed, Mar 29, 2023 at 7:18 PM Alessandro Vesely wrote:
> I'd mention indirect mail flows explicitly, rather than referring to
> generic
> interoperability problems. But several mailing list adopted expedients in
> order to overcome those problems. Furthermore, there are experimental
> protoco
On Wed, Mar 29, 2023 at 8:59 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> MUST seems to take us back to the unfinished debate of 3 years ago, where
> some asserted that DMARC did more harm than good and should only be used
> for transactional mail, which seemed to mean PayPal
MUST seems to take us back to the unfinished debate of 3 years ago, where
some asserted that DMARC did more harm than good and should only be used
for transactional mail, which seemed to mean PayPal and not much else.
On Wed, Mar 29, 2023, 6:18 AM Alessandro Vesely wrote:
> On Tue 28/Mar/2023 10
On Tue 28/Mar/2023 10:15:04 +0200 Barry Leiba wrote:
I raised this issue in the DMARC session in Vienna, and have let it
sit for a while so as not to derail other discussion. As we're pretty
close to finished with the DMARCbis document, I'd like to raise it
again, this time with specific propose
28 matches
Mail list logo
