Scott Kitterman writes:
In order to ensure OAR was added by the ML (or whoever you trust to
add it correctly) you're going to have to grovel through the
received fields and see if the MTA you trust added the field.
Re: groveling. Received fields are easy to fake and nobody signs
those
Even if I grant you that (and I'm not sure I do), I also don't know why OAR is
better than AR.
I get the impression there are two reasons for OAR:
a) A-R is likely to be stripped by intermediate MTAs, OAR isn't.
b) whoever suggested OAR didn't understand A-R semantics
Take your pick.
R's,
John Levine writes:
Even if I grant you that (and I'm not sure I do), I also don't
know why OAR is better than AR.
I get the impression there are two reasons for OAR:
a) A-R is likely to be stripped by intermediate MTAs, OAR isn't.
b) whoever suggested OAR didn't understand A-R
On Monday, June 02, 2014 12:58:47 Brandon Long wrote:
On Sat, May 31, 2014 at 6:07 AM, Stephen J. Turnbull step...@xemacs.org
wrote:
Brandon Long writes:
...
Mailman is already working on this. Unfortunately, some domains just
use a generic 5.7.x policy bounce, and other don't even give
On Monday, June 02, 2014 13:10:04 Brandon Long wrote:
On Mon, Jun 2, 2014 at 1:00 PM, Scott Kitterman skl...@kitterman.com
wrote:
On Monday, June 02, 2014 12:43:48 Brandon Long wrote:
On Fri, May 30, 2014 at 8:10 PM, John Levine jo...@taugh.com wrote:
1) Support
On Mon, Jun 2, 2014 at 1:34 PM, Scott Kitterman skl...@kitterman.com
wrote:
There is a discussion about defining new codes for email authentication
failures in progress on apps-discuss which may interest people interested
in
this particular topic.
This keeps reducing to the previous case. If you know what senders
you trust, why do you need the OAR header?
OAR and the signed mailing list means that I trust the mailing list to have
properly checked the original validation.
True, but if you trust the mailing list that far, how likely is
I proposed internally a scheme where we would compute a reputation for
mailing lists, and ones which are sufficiently high will be whitelisted for
DMARC. The issue that was presented to me is spear phishing attacks
through mailing lists (which we've seen) ...
Eww. My lists are set up so that
On Monday, June 02, 2014 15:31:36 Brandon Long wrote:
On Mon, Jun 2, 2014 at 1:36 PM, Scott Kitterman skl...@kitterman.com
wrote:
Trust in this context means trust not to lie on the OAR. Either you
trust
them not to lie (and the content can be used) or you don't and it can't be
used.
Brandon Long writes:
1) Reject posting from p=REJECT users
+1 0.2 wink
It seems like [ignoring DMARC bounces when checking if the
recipient is able to receive] should be relatively uncontroversial,
Mailman is already working on this. Unfortunately, some domains just
use a generic 5.7.x
Brandon Long wrote:
What can mailing lists do today
1) Reject posting from p=REJECT users
2) Re-write From header for p=REJECT/QUARANTINE users
3) Don't break the DKIM signature (no subject prefix, no footer)
4) Recognize DMARC reject bounce messages and don't consider them as
reason to
11 matches
Mail list logo
