On 2020-08-04 6:10 p.m., Dotzero wrote:
> On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton wrote:
>> On 8/2/20 5:43 PM, Douglas E. Foster wrote:
>>> As to the transparency question, it should be clear that there will be
>>> no simple solution to the ML problem.
>>
>> Actually, there is: If your domain h
On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton wrote:
> On 8/2/20 5:43 PM, Douglas E. Foster wrote:
> > As to the transparency question, it should be clear that there will be
> > no simple solution to the ML problem.
>
> Actually, there is: If your domain has users that use mailing lists,
> don't pub
On 8/2/20 5:43 PM, Douglas E. Foster wrote:
> As to the transparency question, it should be clear that there will be
> no simple solution to the ML problem.
Actually, there is: If your domain has users that use mailing lists,
don't publish 'reject' or 'quarantine' policies. Generally this means t
On 8/2/20 2:24 PM, John R Levine wrote:
>>> If they would provide a way to register a mailing list and the servers
>>> from which it comes, and allow DMARC exceptions for traffic from those
>>> registered lists, your situation would be much easier?
>
> If large mail providers were willing to whitel
This is a known issue with many calendaring frameworks. Besides the issue
of delegates who are sending on behalf of someone in another domain, most
calendaring systems send "forwarded" invitations by trying to resend in the
name of the event originator.
--Kurt
_
John R Levine skrev den 2020-08-02 23:24:
If large mail providers were willing to whitelist known mailing lists
we wouldn't need ARC.
if no one breaked dkim then we did not need arc
See previous messages for why that isn't sufficient.
missing arc will not break spf dkim, but it preserves s
