Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[Roland Turner via dmarc-discuss]

Ben Greenfield wrote:

> I believe the IP and hostname match exactly the ip address and hostname of 
> the working DKIM, SPF. I was assuming that these were the emails that went to 
> list-serves, but on further consideration if they were list-servs that would 
> show the ip and hostname of the list-serv.

DKIM and IP addresses are almost orthogonal, so the sorts of matches that 
you're talking about are not that important. Relevant questions would appear to 
be:

- Which IP addresses are sending messages that are failing DKIM but passing 
SPF[1]?
- Are these IP addresses under your control?
- If so, why is DKIM failing?
- If not, why are they listed in your SPF record?

- Roland

1: I assume that we're talking about SPF for your own domains, rather than for 
a forwarder's?
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[Roland Turner via dmarc-discuss]

(merging two sub-threads)

Scott Kitterman wrote:

> Along with the good things you (quite reasonably) describe, there will also be
> an increased tendency towards concentration of power in a few hands. 
> Personally, I think that's a bad thing.  Your previous message in this thread
> captured my concern very nicely.

I'd suggest that the tendency towards concentration once uncertainty about the 
best way to do a thing subsides is perfectly ordinary and not something to be 
any more upset about than the tides, even if you were the kind of person who 
enjoyed building ornate sandcastles. The important concern would not be 
consolidation per se, but consolidation to the point where independent actors 
in related spheres lose their independence as a result. I don't believe that 
this result has arisen in the case of SMTP reputation data and see no reason to 
assume that it will arise with ARC reputation data (indeed, as described below, 
I believe it to be less likely in the ARC case).

> Roland Turner wrote:
>
>> I meant to ask earlier: would you level the same criticism at SMTP, given
>> that running a useful mail-receiving-server without a solid DNSBL is now
>> more-or-less infeasible? Does the fact that Spamhaus is already available
>> free of charge to all of the small guys change this analysis?
>
> The fact that there are high quality services available free/reasonable for a
> little guy to pay does alter my perspective.  At the time  DNSBLs were
> becoming popular/necessary there wasn't the same level of concentration in the
> market and even going back to open relay lists there's ~always been something
> anyone on a modest budget could use.

So, looking forward a couple of steps: when/if ARC proves to be useful (bear in 
mind that it's currently untested) it would seem to me to be a near certainty 
that the first and probably both of the following will occur:

- open-source MTAs/tools will gain the capability to make sensible use of ARC 
in DMARC decision-making, and
- reputation data providers will provide the "batteries" (assuming that there 
are important pieces that are too fast moving to be embedded in source code) 
just as they already do for DNSBLs.

You've not advanced any argument to suggest that this is not true, yet much of 
your concern appears to assume that it's not true. Do you believe that there's 
something special about ARC reputation data (mapping the observed behaviour of 
a few thousand well-intentioned forwarders who are not trying to hide) that is 
somehow more difficult, or less likely to appear than DNSBLs were and are 
(mapping the observed behaviour of hundreds of millions of IP addresses in the 
control of criminals who are working hard to hide what they're doing)? So far 
as I can tell, ARC reputation data will be a far simpler nut to crack than 
blocklists ever were, and may even be slow enough moving that it can be 
embedded in source code.

Stated another way, you appear to be making an extraordinary claim not merely 
in the absence of extraordinary evidence, but in the face of contradictory 
evidence.

>> Perhaps the fact that SMTP was developed at a time that abuse was not
>> widespread gives it a free pass on this front? Presumably you don't argue
>> that, *because* we're already in a high-abuse environment we should
>> therefore cease collaboration on any class of solution which happens to
>> require more data than is either: (a) feasible for small guys to process
>> usefully, or
>> (b) available to small guys at all?
>
> SMTP has always been, with a little study, been something any competent admin
> could do.  It takes a lot more study and more resources than a decade or two
> ago, but we haven't, in my opinion, crossed a tipping point where that's not
> longer possible.  So SMTP gets a pass because it's ~always been accessible (I
> know in the dim reaches of history that wasn't quite always so).

OK, but that wasn't quite the question that I meant to ask. I was getting at 
the dependence that we all have upon DNSBL providers. Generating that data is 
already out of range for all but about a dozen organisations in the world 
(there are multiple publicly-available products, but there's also a lot of 
licensing going on behind the scenes). ARC reputation data is likely to be 
easier produce (a smaller number of assessed entities, that are slower-moving, 
and aren't hiding themselves). How is it OK for SMTP use to be dependent upon 
DNSBLs but not for ARC use to be dependent upon reputation data?

If the issue is only that cheap/free ARC reputation data is not yet available - 
and noting the likelihood of its being easier to produce - surely this should 
currently be viewed as a transition state rather than a serious problem?

> I think solutions feasible for one segment of the market (large, small,
> purple, blue, don't care) are fine to collaborate on as long as people are
> clear it's a partial solution.

The authors (and most implementers) of both DMARC and ARC 

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[Ben Greenfield via dmarc-discuss]

> On Feb 16, 2016, at 12:43 AM, Roland Turner via dmarc-discuss 
>  wrote:
> 
> Franck Martin wrote:
> 
>> Yes it is a "you have to be this tall to ride with us". For instance, many
>> Wordpress sites are on URL blocking lists, because the managers
>> cannot keep with basic security updates. So if you want to host a website,
>> you have to be that tall to  ride with us (or find a hosting company, that 
>> will
>> give you a child seat)
> 
> This is not quite the concern that Scott is raising. He's not concerned so 
> much about absentee administrators being unable to keep their services from 
> being compromised and therefore becoming unusable/blocked, but about actively 
> engaged administrators for any email receiving service other than those 
> operated by the big 3 being, eventually, unable to operate effectively. We're 
> not there yet, and I'm more optimistic then Scott is in that I don't think 
> it's anywhere near a foregone conclusion, but the concern is a real one and 
> worth keeping an eye on.

It was that concern that brought my 1 horse email server to DMARC & SPF. I 
think eventually ARC.

I was little surprised in watching the ARC conversation because it was my 
thinking that ARC was going to provide a way mid-email delivery for the 
receiving mail server to check the validity of the email with the sending 
server.

I though the sending server would keep track of what it sent and any receiver 
could check the validity. I thought that we have finally reached the point 
where tracking every legitimate email was easier then weeding through all the 
crap.

Ben









> 
> - Roland
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
> 
> NOTE: Participating in this list means you agree to the DMARC Note Well terms 
> (http://www.dmarc.org/note_well.html)


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

[Franck Martin via dmarc-discuss]

On Mon, Feb 15, 2016 at 10:53 PM, Scott Kitterman via dmarc-discuss
 wrote:
> On Tuesday, February 16, 2016 06:17:27 AM Roland Turner via dmarc-discuss
> wrote:
>> Scott Kitterman wrote:

>>
>> 1: I *don't* believe that this would take the form of a whitelist. It's more
>> like the ability to recognise changes in baseline behaviour by forwarders
>> who may or may not be ARC signing. I suspect that John Levine's concerns
>> about whitelists have some strength.
>
> It would as that data is the barrier to entry I'm worried about.  I think it's
> actually two lists:
>
> 1.  Domains good enough you ought to trust to believe what they say in ARC.
> 2.  Domains bad enough you ought to reject their mail if they show up in ARC.
>
> I do wonder though if I have the data to toss the message why they didn't in
> the first place (and if they didn't why I should trust them).  So generically,
> yes, but I'm not certain what the characteristics of such a data source would
> be.
>

I looked at spamassassin and they don't do this work: take all the
domains in From, Reply-to, Sender, Dkim,... and evaluate them against
Domain Blocking lists and rejecting or scoring the email... they would
argue it is not a clear indicator of spam. Indeed, it has plenty false
positives but it obliges the domain owners to clean their domain or
practices... If I had the time to code some new spamassassin rules.

On the barrier to entry, I'm not sure an enterprise/organization can
run a mail system without some form of paid appliance/services to
filter out spam/phish/malware.

Yes I'm mindful that any clued admin should be able to run a mail
system. I don't think so far I have seen anyone making it impossible.
If you do the right things, your email can be sent and will be
accepted. The difficulty is how much spam you will be able to filter
for your incoming mail into your system. Paid services seems to
provide less risk.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Email storage

[Steven M Jones via dmarc-discuss]

On 02/16/2016 08:31, jim c via dmarc-discuss wrote:
>
>
> The issue that we've noticed is that the forensic data is the entirety
> of the email.  It isn't just header info, but contains the entire
> message text, along with attachments.

Not every Receiver generates failure reports (what "ruf=" triggers), and
Receivers that do generate failure reports may each include different
items from the original message. You will observe a range of content,
from the bare minimum of message headers to, as you observed, the entire
intact message. It all depends on the Receivers internal policies.

No doubt you have to address the latter case, and I'll let others speak
to that. But I did want to point out that Senders won't automatically
get entire messages in every failure report, from every Receiver.

--Steve.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] Email storage

[John Wilson via dmarc-discuss]

Jim,

Please contact me off list. I'd be happy to share our SOC3 and answer any
additional questions you may have. I can also put you in touch with other
Agari customers who had similar concerns but overcame them.

John Wilson

On Tue, Feb 16, 2016 at 8:31 AM, jim c via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> I work for an organization that has fairly stringent security requirements
> regarding where our data is stored.  We recently moved towards DMARC, and
> are working with Agari.
>
> One of the things that Agari does - essentially the most important - is
> receive and analyze any forensic data returned.  The issue that we've
> noticed is that the forensic data is the entirety of the email.  It isn't
> just header info, but contains the entire message text, along with
> attachments.  This means that any externally-bound valid email that is
> mistakenly marked as a failure will have forensic data - ie the entire
> email - sent to Agari.  They will house the emails on their internal
> servers, wherever their data center is.  These emails are available for
> only 14 dayshowever, they cannot tell me how long their system backups
> are stored.  It wouldn't matter if they could, as we have no way of
> auditing their security measures, enforcing requirements, validating
> encryption, backup storage security, etc.
>
> Agari advertises as a cloud service, yet they are not Fedramp'd, which I
> believe should put them out of consideration for most federal agencies,
> considering accidental disclosure of classified data via email, if flagged
> as a failure via DMARC, would cause the email and hence the sensitive data
> to be house outside of any government system.  If Agari's systems were be
> to hacked, all of this data would be available - and again, they are not
> Fedramp'd, which ostensibly certifies their compliance with federal
> security requirements.
>
> Does anyone know if this issue has been discussed before (I couldn't find
> it), and how any of you out there that may work at organizations with
> similar security concerns, have dealt with this issue?
>
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>
> NOTE: Participating in this list means you agree to the DMARC Note Well
> terms (http://www.dmarc.org/note_well.html)
>



-- 
*John Wilson, Field CTO*
jwil...@agari.com l M: 650.996.5848 l www.agari.com

*Changing Email Security For Good.*

 *l*




___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

[dmarc-discuss] Email storage

[jim c via dmarc-discuss]

I work for an organization that has fairly stringent security requirements
regarding where our data is stored.  We recently moved towards DMARC, and
are working with Agari.

One of the things that Agari does - essentially the most important - is
receive and analyze any forensic data returned.  The issue that we've
noticed is that the forensic data is the entirety of the email.  It isn't
just header info, but contains the entire message text, along with
attachments.  This means that any externally-bound valid email that is
mistakenly marked as a failure will have forensic data - ie the entire
email - sent to Agari.  They will house the emails on their internal
servers, wherever their data center is.  These emails are available for
only 14 dayshowever, they cannot tell me how long their system backups
are stored.  It wouldn't matter if they could, as we have no way of
auditing their security measures, enforcing requirements, validating
encryption, backup storage security, etc.

Agari advertises as a cloud service, yet they are not Fedramp'd, which I
believe should put them out of consideration for most federal agencies,
considering accidental disclosure of classified data via email, if flagged
as a failure via DMARC, would cause the email and hence the sensitive data
to be house outside of any government system.  If Agari's systems were be
to hacked, all of this data would be available - and again, they are not
Fedramp'd, which ostensibly certifies their compliance with federal
security requirements.

Does anyone know if this issue has been discussed before (I couldn't find
it), and how any of you out there that may work at organizations with
similar security concerns, have dealt with this issue?
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)