Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC

From: Vlatko Salaj <[email-masked]>
Date: Mon, 17 Feb 2014 23:45:59 -0800 (PST)

On Monday, February 17, 2014 5:22 PM, "[email-masked]" <[email-masked]> wrote:

>> [Proposes SRS as an alternate authentication mechanism]
>> as far as i can tell, the only viable abuse comes from hosts
>> that spoof email. however, nothing forbids them from spoofing DKIM also
> Spoofing of email is exactly the problem. Using SRS as you propose
> actually would give abusers a clear path to spoof any domain that they
> would like to emulate.

that's why i'm suggesting switching to AND, instead of OR. until now, u couldn't
do that, since SPF evaluation was broken in so many cases. however, we introduce
SRS and those cases are accounted for too.

DMARC = ( SPF AND SRS AND DKIM ) and now u can actually say DMARC tightens abuse
path, with low amount of false positives.

what stays broken is already handled by override policy. and even some of those
cases could be fixed if developers accounted for this kind of DMARC, hoping
for its benefits.

> I don't understand your contention that anyone can spoof DKIM for a
> domain not within their control.
> In precise technical terms, what do you mean by "spoofing DKIM"?

http://tools.ietf.org/html/draft-otis-dkim-harmful-04
http://www.zdnet.com/7000019351

and let's not go there further.

>> they should. all of major ESPs provide forwarding as a service, thus breaking
>> more than one protocol. and i am not sure if any of them tries to accommodate
>> for such issues, while doing so.
> Perhaps, but again, it has not created enough of a problem to warrant action.
> Action is expensive. If more people complained about it, the answer might be
> different. But, apparently, they don't.

they may start, once DMARC kicks in. alignment is a problem, and will break
many things.

>> considering SPF was changed recently, in 4408bis draft, to prefer EHLO/HELO
>> identity over MAIL FROM
> I was a participant in the SPFBIS working group, and I don't remember anything
> about changing to prefer HELO/EHLO over MAIL FROM. Can you point me to that
> change?

sure. section 2.3 of 4408bis.

> I think you need to implement DMARC, apply some of these techniques,
> and come back to us with some data, experience.

i did deploy DMARC, manually, on my personal systems and some clients, around
2 years ago, when 1st draft was published. i also reviewed every change made
to it since then, and currently running on last version on my systems. all done
for the sake of local evaluations, i don't send any reports. its a dirty hack
and there's no point beyond my evaluation.

all because i love to experiment with promising new standards.

what i can tell u - forwarding breaks things.

13 of 15 of my clients, all small to middle sized businesses, use forwarding.
and they don't tend to stop using it, actually the opposite - they will use it
even more as BYOD and similar tendencies get more popular etc etc.

i also gave it a great deal of thought over the time. many things bothered me,
but i didn't push myself to contribute until Tim nudged me to "chime in" here,
while thanking me for feedback about an issue with dmarcian.org DMARC verifier.

btw, i tried my experiments with SRS. and actually, solved the forwarding
problem. where i had DMARC errors, now i have clean passes. obviously, i see
no abuse accounting for this change, but i do not really advertise this
difference in DMARC processing to public.

now i'm running on last version which tries AND in DMARC evaluation. so far,
where i had false positives, now i have clear messages. i actually believe this
change in DMARC spec could be useful, but sure, it's too soon to say.

also, i can't pretend to be a big receiver. ppl need to experiment with this
on their side too.

that is, if anybody actually gives a f*ck about DMARC.
i apologize for the language.

> We can provide links to reading materials if he needs such.

tnx.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 18 Feb 2014 21:24:13 +0100

On Tuesday, February 18, 2014 8:45 AM [GMT+1=CET], Vlatko Salaj wrote:

> > > considering SPF was changed recently, in 4408bis draft, to prefer
> > > EHLO/HELO identity over MAIL FROM
> > I was a participant in the SPFBIS working group, and I don't
> > remember anything about changing to prefer HELO/EHLO over MAIL
> > FROM. Can you point me to that change?
> 

Hmm, according to that, checking HELO/EHLO is optional (RECOMMENDED), and checking MAIL-FROM is obligatory (MUST). What 4408bis says is that both SHOULD be checked, but checking HELO/EHLO is still optional.

And I prefer it that way: checking that the return-path (or at least the domain in the return path) is not spoofed I think is more important that checking for a non-spoofed HELO/EHLO. After all, a working return-path has a non-zero cost to maintain, whereas SPF-validating HELO/EHLO with a disposable sub.sub.domain would be almost free. The point of SPF is that spoofing MAIL-FROM becomes expensive, therefore less spam.

And that MAIL-FROM/SPF issue brings me to the SRS issue: my opinion is that email forwarding is WRONG, OBSOLETE, and should be abandoned altogether. Therefore SRS serves no real purpose, and DMARC should not deal with it at all.

Email forwarding is akin to doing FTP-through-email: a relic of times long gone, when you received your email at [email-masked] and you logged in there via telnet to check it with PINE, and you preferred (obviously) to forward that email somewhere else to check it with Eudora and to keep it locally once received in Eudora. It was then that forwarding had a reason to be. Nowadays, not so much.

Regards,

J.Gomez

---

From: Franck Martin <[email-masked]>
Date: Tue, 18 Feb 2014 15:26:14 -0600 (CST)

----- Original Message -----
> From: "J. Gomez" <[email-masked]>
> To: "Vlatko Salaj" <[email-masked]>
> Cc: [email-masked]
> Sent: Tuesday, February 18, 2014 12:24:13 PM
> Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC
> 
> Hmm, according to that, checking HELO/EHLO is optional (RECOMMENDED), and
> checking MAIL-FROM is obligatory (MUST). What 4408bis says is that both
> SHOULD be checked, but checking HELO/EHLO is still optional.
> 
> And I prefer it that way: checking that the return-path (or at least the
> domain in the return path) is not spoofed I think is more important that
> checking for a non-spoofed HELO/EHLO. After all, a working return-path has a
> non-zero cost to maintain, whereas SPF-validating HELO/EHLO with a
> disposable sub.sub.domain would be almost free. The point of SPF is that
> spoofing MAIL-FROM becomes expensive, therefore less spam.

Read: http://trac.tools.ietf.org/html/draft-ietf-spfbis-4408bis-21#section-10.1.3

For a more detailed explanation.

---

From: Vlatko Salaj <[email-masked]>
Date: Tue, 18 Feb 2014 15:32:09 -0800 (PST)

> SHOULD be checked, but checking HELO/EHLO is still optional.

a fully 4408bis compliant SPF algorithm would check HELO identity and skip
MAIL FROM. what spec allows is sticking to plain old rfc4408's way, but
that's not what 4408bis recommends.

> And that MAIL-FROM/SPF issue brings me to the SRS issue: my opinion is that
> email forwarding is WRONG, OBSOLETE, and should be abandoned altogether.

forwarding is here, and it will stay. it's not going anywhere. and to think
otherwise is essentially a thing that should be abandoned altogether.

finally, what's WRONG is creating a protocol which says it serves a purpose
and then make it so frigid to only work in a parallel universe, or for
immortal entities like facebook, google and alike. it has no other purpose,
no matter what some ppl here would like to believe.

if u don't account for everyone, don't bother creating anything. that
concept works well for human rights as well as IT.

time will tell if DMARC fate is sealed, as some FOSS developers see it.

-- 
Vlatko Salaj aka goodone
http://goodone.tk