John,
> When the IETF was trying to figure out what sort of anti-DMARC hackery
> to do for its mailing lists, we did some experiments. ... So we gave
> up and rewrite the From: headers.
A defect in the method used in this list (and Y!Groups, fwiw) is that
every message from the list comes
Dave,
> I look at it a little differently, it's the people (mailing list
> operators) who want to /modify/ my message that need to take steps to
> not break my DMARC in the process.
I look at it a little differently.
As an end-user of email services I don't really care about your DMARC[1],
Andrew,
> Nothin' for nothin', but this seems like an awful lot of mechanism for
> a pretty low-value piece of data, and if I'm reading you right the
> people who have to implement this (at least mailing list operators)
> need to do this so that someone _else's_ use of DMARC works, right?
I
Roland wrote:
> - Forwarders who are large enough to be monitoring deliverability can
> trivially determine whether their ARC-signing is being successfully
> validated and/or when receivers trust them enough to accept messages
> despite failing DMARC.
I see how that is possible when the
J.Gomez,
> Is this ARC thing a mechanism to know when it is safe to ignore
> the sender's DMARC policy of "p=reject"?
It helps in judging that, but isn't complete by itself (you still need a
reputation system for the intermediaries).
> And if it is such, shouldn't it be part of the DMARC
Scott,
> So the idea is that arbitrary data added from an untrusted sender
> (unknown reputation) is sufficient to override DMARC p=reject?
No, that isn't the idea at all.
It is up to the receiving service to decide how to handle the ARC information,
but the guidance is not to simply accept
Scott,
> As described in the drafts, the ARC stamp is applied by the
> intermediary, not the originator, so I don't think that works.
Yes, but the intermediaries had to sign their ARC seal, and thereby identify
themselves in a non-forgeable way.
> Even if it did, it's still just another
Dave,
It would be worth documenting both the nature of how they are harder to
use and the extent of the effect.
There is a widely held view that the only effect is a bit of visual
ugliness, rather than of any serious user detriment.
The nature of the detriments experienced by Yahoo Groups
Larry,
Except, as I and others have discovered in the past few days, DMARC does
NOT make email so much more secure, as phishers and spammers have
already found workarounds to continue their assault.
It can't by itself, no. It needs to be used together with some means to knock
out the
Dave,
That does get at attempts via the protected path, namely rfc5322.from
field domain.
However it doesn't permit measuring other aveneues of attack spoofing
the dmarc-using organization.
Hm... I guess there could be privacy problems with allowing a DMARC author
domain to request
Larry wrote:
The other was sent to a Yahoo Groups list. As Yahoo Groups has their own
workaround this worked.
Notably, Yahoo Groups' workaround is essentially suggestion 3B from the DMARC
FAQ item I operate a mailing list and I want to interoperate with DMARC, what
should I do?
11 matches
Mail list logo
