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

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

> 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.

forwarders running SRS would be more easily identifiable by receivers as reliable forwarders. that should have been my main point.

SPF pass, provided by SRS on a forwarder, is useful data in that regard, together with other algorithms and policies a receiver may use when identifying reliable forwarders.

more so, if a given forwarder doesn't mess with DKIM signature - such email would pass DMARC. and it would generate only a single error - SPF alignment.

only a single fail in 4 step check could be useful data for DMARC-enabled receivers when dealing with forwarders.

given that main purpose of DMARC is to help major mailbox receivers identify reliable email from major email senders, having a spec that suggests recommended behavior for forwarders could help identify such entities in email transaction, and help those receivers evaluate forwarded email more easily.

doc change i'm proposing isn't big. in relevant sections, when speaking about forwarders, a simple mention of SRS as helpful technique, should suffice.

imo, SPF spec did fail to do that, for whatever reason, and maybe we should try not to miss such opportunity again.

current draft does talk about ADSP quite a bit, all while ADSP seems even less relevant to DMARC than SRS. it's not like we would be adding junk data to spec by mentioning SRS.

in any case, that's what has been bugging me about DMARC since it's inception.

-- 

Vlatko Salaj aka goodone
http://goodone.tk

---

From: Franck Martin <[email-masked]>
Date: Thu, 13 Feb 2014 17:41:46 -0600 (CST)

----- Original Message -----
> From: "Vlatko Salaj" <[email-masked]>
> To: [email-masked]
> Sent: Thursday, February 13, 2014 2:02:13 PM
> Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC
> 
> forwarders running SRS would be more easily identifiable by receivers as
> reliable forwarders. that should have been my main point.
> 
> SPF pass, provided by SRS on a forwarder, is useful data in that regard,
> together with other algorithms and policies a receiver may use when
> identifying reliable forwarders.
> 

Transitive trust is hard to implement and DKIM cannot sign this field. The receiver does not have any way to trust that the forwarder, just forwarded the email without altering the content or creating new content.

---

From: Roland Turner <[email-masked]>
Date: Fri, 14 Feb 2014 14:07:31 +0800

>> forwarders running SRS would be more easily identifiable by receivers as reliable forwarders. that should have been my main point.

Parts of your post definitely move into territory that really has been 
done to death already, but for the sake of putting the SRS argument into 
context, I'll [briefly!] outline a few fairly well understood items.

SRS is not relevant to identifying reliable forwarders. The relevant 
information is:

  * That a given IP address has a substantial, sustained message volume;
    large and persistent enough to perform meaningful statistical
    analysis on.
  * That the complaint rate for messages from that IP address is
    consistently negligible.
  * That messages from that address routinely fail authentication from a
    wide range of domains that otherwise pass when they deliver directly.

SRS doesn't help measure any of these things.

If you mean that the mere use of SRS by a sender could usefully be 
treated by a receiver as a signal that the sender is reliable then 
you've overlooked the ability of spoofers to do the same. Indeed, this 
came up in the early days of SPF: the fact/perception that overly 
enthusiastic receivers were granting senders the benefit of the doubt 
merely because SPF passed meant that for quite some time an SPF pass 
became a predictor of abuse (criminals usually adapt faster than the 
median honest participant).

Someone else pointed this out earlier: if you trust someone to do SRS 
honestly and competently then you can probably exempt them from DMARC 
processing anyway, meaning that SRS adds nothing. Worse, you have to 
determine whether someone's SRS implementation is trustworthy before 
using it as an input into anything else, however once you've made that 
determination about a particular source, you can already exempt DMARC 
processing.

SRS adds nothing here.

>> SPF pass, provided by SRS on a forwarder, is useful data in that regard, together with other algorithms and policies a receiver may use when identifying reliable forwarders.

Per the above, SRS provides no useful input for this purpose

>> more so, if a given forwarder doesn't mess with DKIM signature - such email would pass DMARC. and it would generate only a single error - SPF alignment. only a single fail in 4 step check could be useful data for DMARC-enabled receivers when dealing with forwarders.

Forwarders that don't break DKIM don't need to be exempted from DMARC 
processing. SRS adds nothing here.

>> given that main purpose of DMARC is to help major mailbox receivers identify reliable email from major email senders,

Not quite; it's to help Domain Owners of any size - not just major ones 
- and receivers co-operate on keeping spoofed mail out of inboxes.

(Ideally receivers of any size too, but it's not yet plug-and-play for 
receivers, because of exactly the kind of problem that we're discussing.)

>> having a spec that suggests recommended behavior for forwarders could help identify such entities in email transaction, and help those receivers evaluate forwarded email more easily.

This is the same erroneous thinking that was behind specifying SRS in 
the first place. DMARC is about helping Domain Owners and receivers 
co-operate on reducing a problem. As John Levine frequently points out, 
forwarders tend to have $0 budgeted to solve Domain Owners' and 
receivers' problems for them.

That said, there are several things that willing forwarders can do:

  * Certain kinds of forwarder [can] behave in ways which preserve DKIM.
    These applies to things like forwarding message copies from a user's
    inbox to another account held by the same user elsewhere. Mailing
    lists generally can't work this way because they tag Subject:
    headers, add footers, strip attachments, etc.
  * Some mailing lists can and do take authorship, meaning that they
    replace the 5322.From with the list's submission address. They can
    then readily cause both SPF and DKIM to pass. Most mailing lists
    don't work this way.
  * Given that p=reject is a clear indication from the Domain Owner that
    modified messages should not be delivered, a mailing list (or other
    forwarder) that is set up to make [DKIM-breaking] changes can
    reasonably reject submissions outright from such domains.
  * For forwarders who are determined to attempt to get the mail through
    even in a p=reject situation (not the Domain Owners wish, but the
    forwarder doesn't work for the Domain Owner), a useful adaptation is
    to not treat 5xx failures for mail forwarded from p=reject domains
    as reasons to stop sending (e.g. to unsubscribe the recipient from a
    mailing list). This is probably quite unwise, but is mentioned for
    completeness.

I thought most of this was in the FAQ, but can't locate it at present.

>> doc change i'm proposing isn't big. in relevant sections, when speaking about forwarders, a simple mention of SRS as helpful technique, should suffice.

The relevant place for this would be the FAQ, it has no part in the 
DMARC protocol. That said, as SRS doesn't provide any help at all, the 
likely addition would read the opposite of what you have in mind.

>> imo, SPF spec did fail to do that, for whatever reason, and maybe we should try not to miss such opportunity again.

If you are implying that the absence of SRS from the SPF spec is any 
part of the reason for the non-adoption of SRS by forwarders then you 
are mistaken. The reasons are those described above.

>> current draft does talk about ADSP quite a bit, all while ADSP seems even less relevant to DMARC than SRS.

DMARC is very close to ADSP; DMARC is essentially sender-policy version 
4, ADSP was version 3. (SPF -all and DomainKeys o=- were the previous 
serious attempts at this). ADSP's major innovation (separation of policy 
from authentication) is retained by DMARC. DMARC's major innovation was 
providing a decoupled feedback mechanism. SPF has a feedback mechanism, 
but it is too closely coupled to message handling to be usable by some 
large receivers.

- Roland

---

From: Vlatko Salaj <[email-masked]>
Date: Fri, 14 Feb 2014 00:23:29 -0800 (PST)

On Friday, February 14, 2014 12:42 AM, Franck Martin <[email-masked]> wrote:

> Transitive trust is hard to implement and DKIM cannot sign this field.

undeniable. however, that's no different from any other situation, and it's not
DMARC's goal to achieve email's authenticity verification. we would still rely
on the same premises DKIM offers us, just have a bit more useful data for
evaluation, over what DMARC tells us.

an SRS-enabled forwarder could still help receivers with high volume more easily
distinguish a particular forwarder for a trusted one, especially if that's a low
volume forwarder, knife's edge scenario, in which receiver doesn't know how to
proceed exactly, cause of lack of sufficient data.

case scenario:
1. DMARC-fully-enabled sender, SPF/SRS-enabled forwarder, doesn't break DKIM.
2. DMARC passes, based on DKIM.
3. SPF passes, its alignment doesn't.
4. low lvl forwarder, no sufficient xp data to make a reliable guess at receiver
   about email authenticity.
5. lack of data from public block lists, no reputation for the forwarder.

this is obviously a trusted forwarder, possibly one that forwards corporate
email to a private account residing on a major mailbox provider, using filters;
or a similar scenario. i'm sure almost everybody here used something like that.

my case scenario is even more useful for receivers' email heuristics if DKIM
doesn't survive forwarding, meaning DMARC failed, yet sender's DMARC policy is
"none". in this case, since forwarder used SRS, we can easily discover it as
such, and help analyze its reliability.

surely, additional data SRS provides is more useful for receivers evaluating
a domain than having only an SPF fail info, on that lvl. and DMARC spec could
help deploying forwarding hosts realize that.

ofc, the value of even a small side-mention in a spec document is undeniable.

ps. no, i'm not lobbying for SRS devs. my connections to all this are limited
to user area. having used SRS to fix many such issues for clients on hosting
services i admin, i came to realize we need more support for SRS in developing
specs. hopefully some will agree and we can have a productable discussion.

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

---

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

----- Original Message -----
> Sent: Friday, February 14, 2014 12:23:29 AM

I kind of see your point, and yes it could be used to detect good forwarders and therefore provide a mechanism for the DMARC overwrite "forwarder".

However, like for the other policy overrides in DMARC, I don't think we want to standardize any of this, and this is more a capability for the receiver to alleviate certain peculiar situations.

I think DMARC aim is to be as binary as possible for the receiver, with no exception, removing the guess work that weakened SPF policy part.

So we are looking at the hard work here which is: if a forwarder breaks DKIM, then it should fix their infrastructure to not break DKIM (changing charset, encoding, converting the email to an internal format and then back to an Internet format,...)

Saying that, mailing list is different because of the end user visible modifications in the message.