Count| Bytes | Who
++---
43 ( 100%) | 418166 ( 100%) | Total
8 (18.6%) | 112534 (26.9%) | Douglas Foster
7 (16.3%) | 44854 (10.7%) | Barry Leiba
5 (11.6%) | 44191 (10.6%) | Scott Kitterman
4 ( 9.3%) | 23038 ( 5.5%) | Alessandro Vesely
Hi,
Le 15/07/2023 à 12:22, Douglas Foster a écrit :
[...]
Track 2: Exception Request
[...]
Track 2 benefits:
[...]
- Elimination of From munging is potentially available to all
participants, even those from p=reject domains
This important word here is "potentially". In practice, only an
insi
As long as the unsympathetic evaluator produces a reject or bounce, the
automatic digest approach will work well. if digest mode failover is
implemented as an operator function, it could be implemented quickly
without software changes . Automating the process seems like a minor
undertaking as w
Hi,
> The stupid evaluator says, "p=none means no problem here".
And the non-stupid evaluator knows that p=none means that the domain owner
doesn't (yet) have the appropriate sending infrastructure to have p=reject.
> The appropriate response to an authentication failure is to investigate,
I know what "p=none" means to the sender, but that is no reason to ignore
authentication failures when "p=none" or "no policy".
About DMARC wrong results:
We will always have these types of messages:
1) Domain owner messages transmitted and received with authentication
2) Domain owner messages tr
Having negotiations between senders, evaluators and lists sounds difficult.
I agree the dream would be to have at least a semi-automated solution which
works. I'd be interested to hear what you think of the following rough idea
(with the assumption that most lists today are currently doing FromMung
It appears that OLIVIER HUREAU said:
>-=-=-=-=-=-
>
>Hi,
>
>> The stupid evaluator says, "p=none means no problem here".
>
>And the non-stupid evaluator knows that p=none means that the domain owner
>doesn't (yet) have the appropriate sending infrastructure to have
>p=reject.
Or it means tha
On Sun, Jul 16, 2023 at 6:50 PM Emanuel Schorsch wrote:
> Having negotiations between senders, evaluators and lists sounds
> difficult. I agree the dream would be to have at least a semi-automated
> solution which works. I'd be interested to hear what you think of the
> following rough idea (with
