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

From: Vlatko Salaj <[email-masked]>
Date: Thu, 13 Feb 2014 01:04:35 -0800 (PST)

i'm not sure if this has been discussed before or not,
however, imo, it should be noticed in some way or another,
in dmarc draft.

basically, it's a problem with dmarc and forwarders,
mailing lists, and how they break spf, and thus, dmarc.

now, i'm quite aware that forwarders and mailing lists have
been discussed here to the point of punching corpses. however,
i didn't see anyone mention SRS [Sender Rewriting Scheme]
at all, even with advanced search from likes of google and bing.

having researched the topic for some time, imo, SRS rly does
help SPF combat issues regarding forwarders. in turn, this also
helps DMARC.

so, what i'm trying to propose here is some kind of mention
in dmarc draft on behalf of SRS. having even a small mention
should really help ppl deploying dmarc on forwarding hosts.

and yes, i'm aware SRS hasn't been standardized, but
mentioning it in dmarc specs may also help add some traction to
that, almost completely stable and functional, technique
of fixing some grief introduced by forwarders.

more info on SRS:
http://www.libsrs2.org

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

---

From: Roland Turner <[email-masked]>
Date: Thu, 13 Feb 2014 17:25:17 +0800

For better or worse, SRS doesn't help DMARC at all.

DMARC uses authentication results from DKIM and SPF purely to 
authenticate use of the domain in the 5322.From, SPF/DKIM passes for 
different/unaligned domains are ignored. An SRS rewrite can cause an SPF 
fail to become an SPF pass, but it will also change the domain that SPF 
passes to no longer be that appearing in 5322.From.

The general strategies for receivers to deal with forwarders appear to 
break down into:

  * You don't care about forwarder damage (e.g. have a captive
    audience): ignore forwarders, let stuff break. This seems absurd,
    but some people - typically not receivers - think about the problem
    this way.
  * You do care about forwarder damage: identify reliable forwarders and
    exempt them from DMARC processing. This is generally most usefully
    done by IP address rather than by domain-name-plus-SPF (SPF would
    usually widen the exemption needlessly).

SRS doesn't come up in either case which, given how rarely it's used, 
shouldn't be a large surprise.

- Roland

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 14 Feb 2014 07:32:22 -0800

> of fixing some grief introduced by forwarders.
Has anyone in the SRS community expressed interest in seeking
standardization?  If it's in substantial, protracted use, then it probably
should be published at least with Informational status.

-MSK

---

From: Vlatko Salaj <[email-masked]>
Date: Fri, 14 Feb 2014 09:56:45 -0800 (PST)

> Has anyone in the SRS community expressed interest in seeking 
standardization?
> it's in substantial, protracted use, then it 
probably should be published at
> least with Informational status.

there has been many calls for that over the years, but nobody bothered enough,
mostly cause SRS was left out of SPF, asaik. it was, mainly, developed as a pair
of SPF/SRS combo, at least until microsoft came in. some bad blood during SPF
development, microsoft sender id crap and eventually it was all left separated,
having ppl who run forwarders maintain SRS on their own. however, since sender
id never came to life, at least not as imagined, SPF spec was left broken for
forwarders.

i guess having someone heavily involved in ietf nudge them about it could prove
useful into pushing towards standardization.

SRS is quite useful for shared hosting with forwarding capabilities enabled,
which is, almost, every single cpanel deployment out there. so, standardization
would be quite nice; at least, i wouldn't have to spend time explaining hosting
providers from my client's isps how and why to enable SRS in their cpanel
deployments to solve issues with lost email, instead pointing them to rfc doc.

however, waking those SRS ppl up may rly require some authority figure. they are,
kind of, happy with their protocol, and its stability and usage. do try, if u
wish. at least i will be grateful. :)

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 14 Feb 2014 10:56:40 -0800

On Fri, Feb 14, 2014 at 9:56 AM, Vlatko Salaj <[email-masked]>wrote:

> wish. at least i will be grateful. :)=
>

It's kind of telling, to me at least, when a community doesn't feel like
putting the energy into pushing their own work toward standardization.

It would be far better for DMARC to be able to point at a stable reference
for SRS, assuming the DMARC community wants to include such a reference.
But that's about the extent of the motivation I can really provide, since
I've never encountered SRS in production.

-MSK

---

From: Franck Martin <[email-masked]>
Date: Fri, 14 Feb 2014 13:05:46 -0600 (CST)

----- Original Message -----

> From: "Murray S. Kucherawy" <[email-masked]>
> To: "Vlatko Salaj" <[email-masked]>
> Cc: [email-masked]
> Sent: Friday, February 14, 2014 10:56:40 AM
> Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC

> On Fri, Feb 14, 2014 at 9:56 AM, Vlatko Salaj < [email-masked] >
> wrote:

> > however, waking those SRS ppl up may rly require some authority figure.
> > they
> > are,
> 

> for SRS, assuming the DMARC community wants to include such a reference. But
> that's about the extent of the motivation I can really provide, since I've
> never encountered SRS in production.

Vlatko, 

If I'm not mistaken, even if you did not create SRS, if the Intellectual property does not restrict you, you can submit an Internet-Draft and then additional IETF work can reference this Internet Draft. This is the first bar that needs to be passed now.

---

From: Vlatko Salaj <[email-masked]>
Date: Fri, 14 Feb 2014 11:54:17 -0800 (PST)

On Friday, February 14, 2014 8:06 PM, Franck Martin <[email-masked]> wrote:

>> It would be far better for DMARC to be able to point at a stable reference for
>> SRS, assuming the DMARC community wants to include such a reference.
> If I'm not mistaken, even if you did not create SRS, if the Intellectual
> property does not restrict you, you can submit an Internet-Draft and the
> additional IETF work can reference this Internet Draft. This is the first bar
> that needs to be passed now.

yeah, lovely, more work for me. huraaaay. :D
actually, how crazy i am, i may actually do it. given enough time, ofc.

however, i may consider it worthwhile quest only if at least some of major DMARC
contributors actually agree this info could be beneficial to DMARC draft txt.
i do not want to step on any toes here, being a newbie and stuff. it's not my
place to defy all collective wisdom that pushed DMARC where it is now. at least,
not yet.

so, will we agree we should make a section explaining about some DMARC shortcomings
and how to alleviate them - including SRS among others?

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

---

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

----- Original Message -----
> From: "Vlatko Salaj" <[email-masked]>
> To: [email-masked]
> Sent: Friday, February 14, 2014 11:54:17 AM
> >> for

I believe, the collective wisdom is to make the SPEC as short as possible, to just describe the protocol and that's about it.

However there is a BCP type being developed to explain the SPEC, deployment, shortcomings, etc.. I guess this would be a better fit there.

http://tools.ietf.org/html/draft-crocker-dmarc-bcp-03