> I suppose the tl;dr version of my last reply is:
>
> The registration problem is not a red herring because it doesn't exist, but
> because it
> is intractable. Thus, any response to the third-party problem that relies on
> a solution
> to that problem (which includes ATPS, DSAP, and TPA) is
On Sat, May 9, 2015 at 10:33 PM, Anne Bennett
wrote:
> Hmm, Hector, I think you've forced me to convince myself that you're
> on the right track: I think that the "registration problem" is a red
> herring after all. There's no deterministic way to decide what's a
> legitimate mailing list (or ot
On Sat, May 9, 2015 at 10:33 PM, Anne Bennett
wrote:
> Hmm, Hector, I think you've forced me to convince myself that you're
> on the right track: I think that the "registration problem" is a red
> herring after all. There's no deterministic way to decide what's a
> legitimate mailing list (or ot
On Sunday, May 10, 2015 01:33:48 AM Anne Bennett wrote:
> Hmm, Hector, I think you've forced me to convince myself that you're
> on the right track: I think that the "registration problem" is a red
> herring after all. There's no deterministic way to decide what's a
> legitimate mailing list (or o
Hector,
>> Now of course we all know that if I used "!all" in my SPF
>> record, this would break messages from my users who:
>
> Do you mean "-ALL" hardfail policy?
Yes, sorry.
>>1 - ... are currently offsite but set their From: line to
>>my domain, then submit mail through another
>> No. Most domains aren't subject to significant phishing attacks, so
>> for them it's useful for incoming mail from Paypal et al, but not for
>> outgoing mail.
>
>I take it that a *significant* phishing attack is one where the
>5322.From domain is involved with money, and the hook is a URL at a
On 09 May 2015 20:43:34 -,
"John Levine" wrote:
> >Isn't the ideal objective of DMARC to be so reliable that *everybody*
> >uses it with p=reject.
>
> No. Most domains aren't subject to significant phishing attacks, so
> for them it's useful for incoming mail from Paypal et al, but not for
On 5/9/15 8:07 AM, Murray S. Kucherawy wrote:
> On Sat, May 9, 2015 at 2:00 AM, Stephen J. Turnbull
> wrote:
>
>> > Agreed again. And as Terry has said and I think we can infer about
>> > other large operators, it's incorrect to assume (and plain wrong to
>> > assert) that this is an easy pr
Hi Terry,
No one ever proposed an open-ended user access to DNS or APIs that
access the backend, server side files. No, thats a clear security
threat. As a design rule of SE thumb, you MUST never give normal
and/or unregulated users access to system level operations. That is
typically rese
>Isn't the ideal objective of DMARC to be so reliable that *everybody*
>uses it with p=reject.
No. Most domains aren't subject to significant phishing attacks, so
for them it's useful for incoming mail from Paypal et al, but not for
outgoing mail.
> At that point, 5322.From addresses will all
>
On May 9, 2015 1:13:15 PM EDT, Hector Santos wrote:
>Your bar is too unrealistically high for typical IETF project work that
>is still in the experimental stages. You should be thankful, we
>didn't apply this bar to the SPF experiment.
It wasn't brought to be the IETF until it had substantial d
On May 9, 2015 1:09:09 PM EDT, "Stephen J. Turnbull" wrote:
>Scott Kitterman writes:
>
> > How many solutions do you think operators will be willing to
> > implement?
>
>As many as have an expected benefit/cost ratio greater than 1, of
>course.
>
>If you want numbers, my expectation is about 0.5 (
The reliability aspect is realistic to set a high bar. The decision to allow
unregulated users to publish to the zones of
Hotmail.com/outlook.com/msn.com/live.com/Hotmail.ca/outlook.ca/live.ca... etc.
is one that comes with its own security challenges. This now no longer a way to
allow indirect
Murray S. Kucherawy writes:
> I'm having trouble coming up with a heuristic that is even certain
> to grab "most" of them.
Without definitions of "certain", "'most'", and "them", how is anybody
supposed to meet such a requirement?
Pending receipt of such definitions, I'll go see if I can get s
On Sun, 10 May 2015 02:31:43 +0900,
"Stephen J. Turnbull" wrote:
> Ah, but mailing lists are *already* doing it, at least GNU Mailman
> implements an optional check for DMARC policy at the Author Domain,
> and munges if and only it's reject or quarantine. It's a popular
> feature. I'm just say
Murray S. Kucherawy writes:
> On Wed, Apr 29, 2015 at 5:04 AM, Stephen J. Turnbull
> wrote:
> > The *outgoing MTA* can do this check [for a modified and relayed
> > message that fails From alignment]; it has the same information
> > (the "From" field, the DKIM signature, and the DNS) that th
Your bar is too unrealistically high for typical IETF project work that is
still in the experimental stages. You should be thankful, we didn't apply
this bar to the SPF experiment.
--
Hector Santos
http://www.santronics.com
> On May 9, 2015, at 10:09 AM, Scott Kitterman wrote:
>
>> On May 9
Heuristics for this are quite simple to generate. But it needs verification,
confirmation, authorization before it can be automated. That is what makes it
a heuristic and doesn't belong in the SMTP transport where this protocol can be
implemented if only from a delayed learning concept, i.e. s
Scott Kitterman writes:
> How many solutions do you think operators will be willing to
> implement?
As many as have an expected benefit/cost ratio greater than 1, of
course.
If you want numbers, my expectation is about 0.5 (the odds are
perceptibly better than even that *nothing* will be done)
On Sat, May 9, 2015 at 2:00 AM, Stephen J. Turnbull
wrote:
> > Agreed again. And as Terry has said and I think we can infer about
> > other large operators, it's incorrect to assume (and plain wrong to
> > assert) that this is an easy problem for them to solve in a
> > reliable way.
>
> Plea
On May 9, 2015 5:00:24 AM EDT, "Stephen J. Turnbull" wrote:
>Murray S. Kucherawy writes:
>
> > Agreed again. And as Terry has said and I think we can infer about
> > other large operators, it's incorrect to assume (and plain wrong to
> > assert) that this is an easy problem for them to solve in a
Murray S. Kucherawy writes:
> Agreed again. And as Terry has said and I think we can infer about
> other large operators, it's incorrect to assume (and plain wrong to
> assert) that this is an easy problem for them to solve in a
> reliable way.
Please define "reliable." I gather you all thi
22 matches
Mail list logo
