On Wed, Jul 12, 2023 at 6:47 AM Scott Kitterman
wrote:
> It's not news that there's a risk for SPF associated with shared IP
> addresses.
> That's why it's in RFC 7208 (11.4) and was in RFC 4408 similarly before.
>
+1
>
> I understand your view and agree on the problem. I also sympathize
Does anyone believe that things will change if we publish an RFC which says
"Verizon Media MUST change to p=none"? I don't.
Lists have been hurt by the move to authenticated email. Point taken.
However, the world is not going back to the good old days,.
There is no hope for a list solution to
On Wed, Jul 12, 2023 at 7:30 AM Scott Kitterman
wrote:
> On Wednesday, July 12, 2023 7:04:38 AM EDT Alessandro Vesely wrote:
> > On Wed 12/Jul/2023 12:54:38 +0200 Scott Kitterman wrote:
> > > On Wednesday, July 12, 2023 3:29:34 AM EDT Baptiste Carvello wrote:
> > > ...
> > >
> > >> Why? Because
On Wednesday, July 12, 2023 7:04:38 AM EDT Alessandro Vesely wrote:
> On Wed 12/Jul/2023 12:54:38 +0200 Scott Kitterman wrote:
> > On Wednesday, July 12, 2023 3:29:34 AM EDT Baptiste Carvello wrote:
> > ...
> >
> >> Why? Because it's brittle and will only bring them more headaches? At
> >> the
On Wed 12/Jul/2023 12:54:38 +0200 Scott Kitterman wrote:
On Wednesday, July 12, 2023 3:29:34 AM EDT Baptiste Carvello wrote:
...
Why? Because it's brittle and will only bring them more headaches? At
the very least, DMARC would need to use its own 5xy reply code to avoid
the need for parsing the
On Wednesday, July 12, 2023 3:29:34 AM EDT Baptiste Carvello wrote:
...
> Why? Because it's brittle and will only bring them more headaches? At
> the very least, DMARC would need to use its own 5xy reply code to avoid
> the need for parsing the reply text…
...
This is a very good point. The IANA
It's not news that there's a risk for SPF associated with shared IP addresses.
That's why it's in RFC 7208 (11.4) and was in RFC 4408 similarly before.
I understand your view and agree on the problem. I also sympathize with the
need to technically address conditions as they exist in
Hi,
each mechanism approaches the problem in a different way:
- SPF authorizes selected hosts (machines approved to send mail)
- DKIM authenticates sender (proof of origin)
- ARC authenticate senders chain (also proof of origin, but also proof
of whole communication chain)
we can also continue
Hi,
Le 07/07/2023 à 23:58, John R Levine a écrit :
>
> Why is it up to the recipient systems (the ones that do not care) to
> make life easier for lists? Mailing list packages already do lots of
> analysis of bounce messages. How about if they fix their bounce
> processing to recognize DMARC
Hi,
Le 08/07/2023 à 20:24, Scott Kitterman a écrit :
>
> 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.
>
>
Hi,
Le 07/07/2023 à 21:09, Scott Kitterman a écrit :
> Doesn't sieve happen during delivery, after the message has been accepted?
> Is so, I don't think it's a useful comparison to make.
>
> The lack of bounce/rejection messages results in messages that vanish and
> undermines the reliability
11 matches
Mail list logo
