You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Robert Schetterer <rs...@sys4.de> on 2014/08/15 08:30:35 UTC

dnssec / dane

Question: Would it make sense to have rules based on dnssec / dane
records exist for a maildomain ?

Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

DKIM statistics and spam (was Re: dnssec / dane)

Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Fri, 15 Aug 2014 19:34:04 +0200
Robert Schetterer <rs...@sys4.de> wrote:

> Am 15.08.2014 um 19:28 schrieb David F. Skoll:
> > Looks like about 66% of our spam samples had SPF "pass".

> yes this is what i awaited, any idea about DKIM ?

Less spam has DKIM 'pass'; our stats show about 22%.  I suspect the
overwhelming majority of DKIM-passing spam is sent via large freemail
providers.

Regards,

David.

Re: dnssec / dane

Posted by Dave Warren <da...@hireahit.com>.
On 2014-08-15 10:34, Robert Schetterer wrote:
> yes this is what i awaited, any idea about DKIM ?

While spammers aren't doing it yet, DKIM can be done trivially easily as 
well for spammers that already register throwaway domains.

The private key can be shared the same way the list of throwaway domains 
is shared, or if you wanted to get creative, it could stored in DNS in a 
way that the botnet knows how to look up the current DKIM private key to 
sign mail.

However, the DKIM world is a different place than when SPF was released, 
and I'm not sure that there's any push to whitelist DKIM signed messages 
(without further indicators, such as a domain-level reputation system) 
whereas there was a bit of a push from SPF-proponents to whitelist SPF 
approved messages.

DKIM seems to be much more closely aligned with reputation systems, 
which spammers are not currently able to game.

-- 
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

Re: dnssec / dane

Posted by Robert Schetterer <rs...@sys4.de>.
Am 15.08.2014 um 19:28 schrieb David F. Skoll:
> On Fri, 15 Aug 2014 18:45:39 +0200
> Robert Schetterer <rs...@sys4.de> wrote:
> 
>> are there any stats how much spam is send with right/exist
>> SPF/DMARC/DKIM (TLS)
> 
> I have some statistics for SPF:
> 
> spam=> select count(*) from incidents where status = 'spam' and incident_report like '%SPF query returned ''pass%';
>  count
> --------
>  661769
> 
> spam=> select count(*) from incidents where status = 'spam';
>   count
> ---------
>  1003495
> 
> Looks like about 66% of our spam samples had SPF "pass".  So
> yes... spammers are setting up SPF records and/or using hacked
> accounts.  SPF is so easy ("v=spf1 +all") that it would be foolish
> for spammers not to use it.
> 
> Regards,
> 
> David.
> 

yes this is what i awaited, any idea about DKIM ?


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Bogus SPF +all (was Re: dnssec / dane)

Posted by Paul Stead <pa...@zeninternet.co.uk>.
Would something along the lines of this work as a quick rule until a fully fledged plugin comes around?

askdns __LOC_SPF_ALL _SENDERDOMAIN_ TXT /v=spf1.+\+all/
askdns __LOC_SPF_NONE _SENDERDOMAIN_ TXT /v=spf1.+\-all/
askdns __LOC_SPF_LARGESUB _SENDERDOMAIN_ TXT /^v=spf(.+\/[1-6]\s)/

I can't seem to get these rules to fire on test emails?

Example domain of merchantaccount-quotes.co.uk

Paul

On 15/08/14 18:50, David F. Skoll wrote:

On Fri, 15 Aug 2014 10:39:03 -0700 (PDT)
John Hardin <jh...@impsec.org> wrote:



On Fri, 15 Aug 2014, David F. Skoll wrote:


SPF is so easy ("v=spf1 +all")





Doing *that* should be worth a point or two by itself.



Yes.  I even through about implementing it, but there are so many ways
to achieve this:

v=spf1 +all
v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1
v=spf1 exists:openspf.org

... etc...

that we really need an SPF normalizing library that tells you what
percentage of IPv4 space would pass, and then add points for anyone claiming
(say) that more than 1% of total IPv4 space is OK.  (Though the exists:
mechanism is nasty; not sure you even can predict what percentage of
IPv4 is covered in complex cases.)

Regards,

David.



--
Paul Stead
Systems Engineer
Zen Internet

Re: Bogus SPF +all (was Re: dnssec / dane)

Posted by Steve Freegard <st...@fsl.com>.
On 15/08/14 18:54, Joe Quinn wrote:
> On 8/15/2014 1:50 PM, David F. Skoll wrote:
>> On Fri, 15 Aug 2014 10:39:03 -0700 (PDT)
>> John Hardin <jh...@impsec.org> wrote:
>>
>>> On Fri, 15 Aug 2014, David F. Skoll wrote:
>>>> SPF is so easy ("v=spf1 +all")
>>> Doing *that* should be worth a point or two by itself.
>> Yes.  I even through about implementing it, but there are so many ways
>> to achieve this:
>>
>> v=spf1 +all
>> v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1
>> v=spf1 exists:openspf.org
>>
>> ... etc...
>>
>> that we really need an SPF normalizing library that tells you what
>> percentage of IPv4 space would pass, and then add points for anyone
>> claiming
>> (say) that more than 1% of total IPv4 space is OK.  (Though the exists:
>> mechanism is nasty; not sure you even can predict what percentage of
>> IPv4 is covered in complex cases.)
>>
>> Regards,
>>
>> David.

> I guess the logical next question would be what proportion of spam uses
> universal SPF to eke out negative points. Has anyone seen this sort of
> thing in the wild?

I've been dealing with this outside of SA for quite a while now.  Here's 
the last month on my low volume dev box:

[root@mail1-ec2 Haraka]# grep -h 'ignoring SPF' /var/log/maillog* | tr 
-s " " | cut -d" " -f8- | sort | uniq -c | sort -rn
     590 [sender_auth] ignoring SPF Pass result: v=spf1 a +all
     363 [sender_auth] ignoring SPF Pass result: v=spf1 mx ptr +all
      86 [sender_auth] ignoring SPF Pass result: v=spf1 +all
      62 [sender_auth] ignoring SPF Pass result: v=spf1 a mx +all
      23 [sender_auth] ignoring SPF Pass result: v=spf1 ip4:17.0.0.0/8 ~all
       4 [sender_auth] ignoring SPF Pass result: v=spf1 ip4:162.0.0.0/8 
ip4:107.161.144.0/8 ~all
       3 [sender_auth] ignoring SPF Pass result: v=spf1 ip4:0.0.0.0/1 
ip4:130.0.0.0/1 ~all
       3 [sender_auth] ignoring SPF Pass result: v=spf1 a mx ptr 
mx:mail.windmedya.net ip4:46.235.13.163 +all
       2 [sender_auth] ignoring SPF Pass result: v=spf1 a mx 
ip4:69.16.157.128/25 +all
       1 [sender_auth] ignoring SPF Pass result: v=spf1 mx 
ip4:77.232.64.0/19 +all
       1 [sender_auth] ignoring SPF Pass result: v=spf1 mx 
ip4:183.91.18.234 +all
       1 [sender_auth] ignoring SPF Pass result: v=spf1 
include:_spf.uni5.net a mx ptr ip4:177.74.160.0/20 ip4:177.91.0.0/22 
ip4:74.50.96.0/19 ip4:201.28.44.232/30 ip4:177.223.221.0/24 
ip4:199.193.112.0/21 ip4:177.47.96.0/19 ip4:177.36.16.0/20 
ip4:68.233.224.0/19 +all
       1 [sender_auth] ignoring SPF Pass result: v=spf1 
include:_spf.uni5.net a mx ptr ip4:177.74.160.0/20 ip4:177.91.0.0/22 
ip4:177.47.96.0/19 ip4:177.36.16.0/20 +all
       1 [sender_auth] ignoring SPF Pass result: v=spf1 
include:spf-a.roh.org.uk include:spf-b.roh.org.uk +all
       1 [sender_auth] ignoring SPF Pass result: v=spf1 a ptr 
ip4:85.95.239.112 mx:mail.yunusemregroup.net +all
       1 [sender_auth] ignoring SPF Pass result: v=spf1 a mx ptr 
mx:mail.sakaryadental.com ip4:91.191.171.161 +all
       1 [sender_auth] ignoring SPF Pass result: v=spf1 a 
ip4:194.225.184.4 include:iums.ac.ir +all

I ignore and flag SPF Pass results where +all is set or if the netmask 
on ip4: is /[0-8] - that obviously isn't perfect as it doesn't handle 
the exists: case (which I admittedly hadn't thought of).

I'm doing this at the SMTP level; a quick look through the logs shows 
that the top hitting pattern (v=spf1 a +all) is matching a lot of 
invalid recipients or DNSBL blacklisted connections indicating that it's 
a definite spam indicator.

Kind Regards,
Steve.

Re: Bogus SPF +all (was Re: dnssec / dane)

Posted by Robert Schetterer <rs...@sys4.de>.
Am 15.08.2014 um 19:54 schrieb Joe Quinn:
> On 8/15/2014 1:50 PM, David F. Skoll wrote:
>> On Fri, 15 Aug 2014 10:39:03 -0700 (PDT)
>> John Hardin <jh...@impsec.org> wrote:
>>
>>> On Fri, 15 Aug 2014, David F. Skoll wrote:
>>>> SPF is so easy ("v=spf1 +all")
>>> Doing *that* should be worth a point or two by itself.
>> Yes.  I even through about implementing it, but there are so many ways
>> to achieve this:
>>
>> v=spf1 +all
>> v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1
>> v=spf1 exists:openspf.org
>>
>> ... etc...
>>
>> that we really need an SPF normalizing library that tells you what
>> percentage of IPv4 space would pass, and then add points for anyone
>> claiming
>> (say) that more than 1% of total IPv4 space is OK.  (Though the exists:
>> mechanism is nasty; not sure you even can predict what percentage of
>> IPv4 is covered in complex cases.)
>>
>> Regards,
>>
>> David.
> I guess the logical next question would be what proportion of spam uses
> universal SPF to eke out negative points. Has anyone seen this sort of
> thing in the wild?

However it seems SPF is not a good trigger, but perhaps combi of valid
DKIM and DANE is it "recently". I agree this may no last forever but
on the other hand spamassassin rules are not static and can be changed
if needed.

Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Bogus SPF +all (was Re: dnssec / dane)

Posted by Joe Quinn <jq...@pccc.com>.
On 8/15/2014 1:50 PM, David F. Skoll wrote:
> On Fri, 15 Aug 2014 10:39:03 -0700 (PDT)
> John Hardin <jh...@impsec.org> wrote:
>
>> On Fri, 15 Aug 2014, David F. Skoll wrote:
>>> SPF is so easy ("v=spf1 +all")
>> Doing *that* should be worth a point or two by itself.
> Yes.  I even through about implementing it, but there are so many ways
> to achieve this:
>
> v=spf1 +all
> v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1
> v=spf1 exists:openspf.org
>
> ... etc...
>
> that we really need an SPF normalizing library that tells you what
> percentage of IPv4 space would pass, and then add points for anyone claiming
> (say) that more than 1% of total IPv4 space is OK.  (Though the exists:
> mechanism is nasty; not sure you even can predict what percentage of
> IPv4 is covered in complex cases.)
>
> Regards,
>
> David.
I guess the logical next question would be what proportion of spam uses 
universal SPF to eke out negative points. Has anyone seen this sort of 
thing in the wild?

Re: Bogus SPF +all (was Re: dnssec / dane)

Posted by John Hardin <jh...@impsec.org>.
On Fri, 15 Aug 2014, Dave Warren wrote:

> On 2014-08-15 12:05, John Hardin wrote:
>>  "exists:"? (looks up SPF syntax) (boggle) WTF is the sane use case for
>>  "exists:"??
>
> With other types of macro expansion, you could query a DNS backend that 
> returns responses from database or algorithmically rather than based on 
> static SPF rules written in DNS as text.
>
> Arguably most of it is needlessly complex in practice, but it's still a neat 
> idea, or would be, if SPF FAIL were universally enforced.

Ah, ok, I didn't think to combine it with macros and such. That makes more 
sense.

-- 
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  jhardin@impsec.org    FALaholic #11174     pgpk -a jhardin@impsec.org
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
   From the Liberty perspective, it doesn't matter if it's a
   jackboot or a Birkenstock smashing your face.         -- Robb Allen
-----------------------------------------------------------------------
  Today: the 69th anniversary of the end of World War II

Re: Bogus SPF +all (was Re: dnssec / dane)

Posted by Dave Warren <da...@hireahit.com>.
On 2014-08-15 12:05, John Hardin wrote:
> "exists:"? (looks up SPF syntax) (boggle) WTF is the sane use case for 
> "exists:"??

Imagine something like:

exists:%{l}.%{o}.%{i}._spf.webhost.example

This might allow me to PASS only messages coming from addresses that 
actually exist, and are from the correct server. (Sure, the sending 
server really should enforce this itself, but not all do)

Or I could get more complicated, PASS message from addresses that exist 
from the correct server, NEUTRAL from addresses that exist when the 
message is from an incorrect server, and fail everything from invalid 
addresses no matter what:

exists:%{l}.%{o}.%{i}._spf.webhost.example 
?exists:%{l}.%{o}._any._spf.webhost.example -all

With other types of macro expansion, you could query a DNS backend that 
returns responses from database or algorithmically rather than based on 
static SPF rules written in DNS as text.

Arguably most of it is needlessly complex in practice, but it's still a 
neat idea, or would be, if SPF FAIL were universally enforced.

Even without FAIL enforcement though, exists: can be used as a logging 
mechanism to track forgeries, similar to DMARC's feedback mechanism.

-- 
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

Re: Bogus SPF +all (was Re: dnssec / dane)

Posted by John Hardin <jh...@impsec.org>.
On Fri, 15 Aug 2014, David F. Skoll wrote:

> On Fri, 15 Aug 2014 10:39:03 -0700 (PDT)
> John Hardin <jh...@impsec.org> wrote:
>
>> On Fri, 15 Aug 2014, David F. Skoll wrote:
>>> SPF is so easy ("v=spf1 +all")
>
>> Doing *that* should be worth a point or two by itself.
>
> Yes.  I even through about implementing it, but there are so many ways
> to achieve this:
>
> v=spf1 +all
> v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1
> v=spf1 exists:openspf.org
>
> ... etc...
>
> that we really need an SPF normalizing library that tells you what
> percentage of IPv4 space would pass, and then add points for anyone claiming
> (say) that more than 1% of total IPv4 space is OK.

Sure.

> (Though the exists: mechanism is nasty; not sure you even can predict 
> what percentage of IPv4 is covered in complex cases.)

"exists:"? (looks up SPF syntax) (boggle) WTF is the sane use case for 
"exists:"??

That also could be worth a point or two if it's used. There's no reason to 
try to be *too* smart about edge cases. Do the coverage analysis where 
possible, and add a point for unusual stuff like that. I assume this all 
would have to be plugin-based; add an exclusion list for domains where 
"exists:" is expected and should not be scored, similar to the URIBL 
lookup domain exclusion list.

-- 
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  jhardin@impsec.org    FALaholic #11174     pgpk -a jhardin@impsec.org
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
   Therapeutic Phrenologist - send email for affordable rate schedule.
-----------------------------------------------------------------------
  Today: the 69th anniversary of the end of World War II

Re: Bogus SPF +all (was Re: dnssec / dane)

Posted by Paul Stead <pa...@zeninternet.co.uk>.
Hmm, serves me right for not reading correctly, doesn't look like SENDERDOMAIN is a tag that is set - is there another tag I could use? DKIMDOMAIN exists, but no use


On 31/10/14 16:05, Paul Stead wrote:
have noticed I get the following from a debug:

dbg: check: tagrun - tag SENDERDOMAIN is still blocking action 1

 -- Am I using the right tag?

--
Paul Stead
Systems Engineer
Zen Internet

Re: Bogus SPF +all (was Re: dnssec / dane)

Posted by Paul Stead <pa...@zeninternet.co.uk>.
I have noticed I get the following from a debug:

dbg: check: tagrun - tag SENDERDOMAIN is still blocking action 1

 -- Am I using the right tag?

On 31/10/14 13:51, Paul Stead wrote:
Tried to send this before, seemed to not go through, apologies if two copies get through eventually...


Would something along the lines of this work as a quick rule until a fully fledged plugin comes around?

askdns __LOC_SPF_ALL _SENDERDOMAIN_ TXT /^v=spf1.+\+all$/
askdns __LOC_SPF_NONE _SENDERDOMAIN_ TXT /^v=spf1 -all$/
askdns __LOC_SPF_LARGESUB _SENDERDOMAIN_ TXT /^v=spf(.+\/[1-6]\s)/

I can't seem to get these rules to fire on test emails?

Paul

On 15/08/14 18:50, David F. Skoll wrote:

On Fri, 15 Aug 2014 10:39:03 -0700 (PDT)
John Hardin <jh...@impsec.org> wrote:



On Fri, 15 Aug 2014, David F. Skoll wrote:


SPF is so easy ("v=spf1 +all")


Doing *that* should be worth a point or two by itself.


Yes.  I even through about implementing it, but there are so many ways
to achieve this:

v=spf1 +all
v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1
v=spf1 exists:openspf.org

... etc...

that we really need an SPF normalizing library that tells you what
percentage of IPv4 space would pass, and then add points for anyone claiming
(say) that more than 1% of total IPv4 space is OK.  (Though the exists:
mechanism is nasty; not sure you even can predict what percentage of
IPv4 is covered in complex cases.)

Regards,

David.



--
Paul Stead
Systems Engineer
Zen Internet

--
Paul Stead
Systems Engineer
Zen Internet

Re: Bogus SPF +all (was Re: dnssec / dane)

Posted by Paul Stead <pa...@zeninternet.co.uk>.
Tried to send this before, seemed to not go through, apologies if two copies get through eventually...


Would something along the lines of this work as a quick rule until a fully fledged plugin comes around?

askdns __LOC_SPF_ALL _SENDERDOMAIN_ TXT /^v=spf1.+\+all$/
askdns __LOC_SPF_NONE _SENDERDOMAIN_ TXT /^v=spf1 -all$/
askdns __LOC_SPF_LARGESUB _SENDERDOMAIN_ TXT /^v=spf(.+\/[1-6]\s)/

I can't seem to get these rules to fire on test emails?

Paul

On 15/08/14 18:50, David F. Skoll wrote:

On Fri, 15 Aug 2014 10:39:03 -0700 (PDT)
John Hardin <jh...@impsec.org> wrote:



On Fri, 15 Aug 2014, David F. Skoll wrote:


SPF is so easy ("v=spf1 +all")





Doing *that* should be worth a point or two by itself.



Yes.  I even through about implementing it, but there are so many ways
to achieve this:

v=spf1 +all
v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1
v=spf1 exists:openspf.org

... etc...

that we really need an SPF normalizing library that tells you what
percentage of IPv4 space would pass, and then add points for anyone claiming
(say) that more than 1% of total IPv4 space is OK.  (Though the exists:
mechanism is nasty; not sure you even can predict what percentage of
IPv4 is covered in complex cases.)

Regards,

David.



--
Paul Stead
Systems Engineer
Zen Internet

Bogus SPF +all (was Re: dnssec / dane)

Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Fri, 15 Aug 2014 10:39:03 -0700 (PDT)
John Hardin <jh...@impsec.org> wrote:

> On Fri, 15 Aug 2014, David F. Skoll wrote:
> > SPF is so easy ("v=spf1 +all")

> Doing *that* should be worth a point or two by itself.

Yes.  I even through about implementing it, but there are so many ways
to achieve this:

v=spf1 +all
v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1
v=spf1 exists:openspf.org

... etc...

that we really need an SPF normalizing library that tells you what
percentage of IPv4 space would pass, and then add points for anyone claiming
(say) that more than 1% of total IPv4 space is OK.  (Though the exists:
mechanism is nasty; not sure you even can predict what percentage of
IPv4 is covered in complex cases.)

Regards,

David.

Re: dnssec / dane

Posted by John Hardin <jh...@impsec.org>.
On Fri, 15 Aug 2014, David F. Skoll wrote:

> SPF is so easy ("v=spf1 +all")

Doing *that* should be worth a point or two by itself.

-- 
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  jhardin@impsec.org    FALaholic #11174     pgpk -a jhardin@impsec.org
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
   Liberals love sex ed because it teaches kids to be safe around their
   sex organs. Conservatives love gun education because it teaches kids
   to be safe around guns. However, both believe that the other's
   education goals lead to dangers too terrible to contemplate.
-----------------------------------------------------------------------
  Today: the 69th anniversary of the end of World War II

Re: dnssec / dane

Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Fri, 15 Aug 2014 18:45:39 +0200
Robert Schetterer <rs...@sys4.de> wrote:

> are there any stats how much spam is send with right/exist
> SPF/DMARC/DKIM (TLS)

I have some statistics for SPF:

spam=> select count(*) from incidents where status = 'spam' and incident_report like '%SPF query returned ''pass%';
 count
--------
 661769

spam=> select count(*) from incidents where status = 'spam';
  count
---------
 1003495

Looks like about 66% of our spam samples had SPF "pass".  So
yes... spammers are setting up SPF records and/or using hacked
accounts.  SPF is so easy ("v=spf1 +all") that it would be foolish
for spammers not to use it.

Regards,

David.

Re: dnssec / dane

Posted by Noel <no...@gmail.com>.
On 8/15/2014 11:45 AM, Robert Schetterer wrote:
> Am 15.08.2014 um 18:33 schrieb Noel:
>> On 8/15/2014 10:27 AM, Robert Schetterer wrote:
>>> Am 15.08.2014 um 16:26 schrieb Kevin A. McGrail:
>>>> On 8/15/2014 2:30 AM, Robert Schetterer wrote:
>>>>> Question: Would it make sense to have rules based on dnssec / dane
>>>>> records exist for a maildomain ?
>>>>>
>>>> A) rules have to be used for things that indicate ham or spaminess
>>>> B) you can only automate something you have done manually
>>>>
>>>> So have you looked at this anecdotally and believe there is an
>>>> indication of ham/spaminess from checking these records?
>>>>
>>>> Regards,
>>>> KAM
>>> It was just question, i have no preference to this yet,
>>>
>>> perhaps thinkable:
>>>
>>> tag domains with dane smtp record for hamness, cause its not wide
>>> provided yet and  identify it as advanced tec skill which results in
>>> rare send spam too
>>>
>> I think detecting dane smtp is a good thing as it gives another
>> metric to test on.
>>
>> I don't think it says anything directly about ham/spam, but may be
>> useful in macros.
>>
>> DKIM/SPF was widely adopted by spammers fairly early after portions
>> of the tech community talked about whitelisting authenticated mail. 
>> You might remember one early point when a significant portion of the
>> early-adopters were spammers and legit sites hadn't caught up yet.
>>
>> The same will happen with dane as usage expands -- some clever
>> spam-support tech will develop a tool to easily mass-configure dane
>> for throwaway domains.  
> Good point , seems comparable
>
> are there any stats how much spam is send with right/exist
> SPF/DMARC/DKIM (TLS)
>
> guess its mostly from hacked accounts at big mail providers, are there
> any other big sources for such spam mails ?


I was mostly thinking about the sophisticated "snowshoe" spammers
that create large numbers of throwaway domains, all fully RFC
compliant.  They were early adopters of DKIM/SPF.  I'm sure they'll
adopt dane as soon as it looks worth their time.

And yes, hacked accounts will continue to be a problem too.



  -- Noel Jones

Re: dnssec / dane

Posted by Robert Schetterer <rs...@sys4.de>.
Am 15.08.2014 um 18:33 schrieb Noel:
> On 8/15/2014 10:27 AM, Robert Schetterer wrote:
>> Am 15.08.2014 um 16:26 schrieb Kevin A. McGrail:
>>> On 8/15/2014 2:30 AM, Robert Schetterer wrote:
>>>> Question: Would it make sense to have rules based on dnssec / dane
>>>> records exist for a maildomain ?
>>>>
>>> A) rules have to be used for things that indicate ham or spaminess
>>> B) you can only automate something you have done manually
>>>
>>> So have you looked at this anecdotally and believe there is an
>>> indication of ham/spaminess from checking these records?
>>>
>>> Regards,
>>> KAM
>> It was just question, i have no preference to this yet,
>>
>> perhaps thinkable:
>>
>> tag domains with dane smtp record for hamness, cause its not wide
>> provided yet and  identify it as advanced tec skill which results in
>> rare send spam too
>>
> 
> I think detecting dane smtp is a good thing as it gives another
> metric to test on.
> 
> I don't think it says anything directly about ham/spam, but may be
> useful in macros.
> 
> DKIM/SPF was widely adopted by spammers fairly early after portions
> of the tech community talked about whitelisting authenticated mail. 
> You might remember one early point when a significant portion of the
> early-adopters were spammers and legit sites hadn't caught up yet.
> 
> The same will happen with dane as usage expands -- some clever
> spam-support tech will develop a tool to easily mass-configure dane
> for throwaway domains.  

Good point , seems comparable

are there any stats how much spam is send with right/exist
SPF/DMARC/DKIM (TLS)

guess its mostly from hacked accounts at big mail providers, are there
any other big sources for such spam mails ?

This isn't necessarily a bad thing in
> itself, but it means that the mere presence of dane can't determine
> ham/spam.
> 
> 
>   -- Noel Jones
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: dnssec / dane

Posted by Noel <no...@gmail.com>.
On 8/15/2014 10:27 AM, Robert Schetterer wrote:
> Am 15.08.2014 um 16:26 schrieb Kevin A. McGrail:
>> On 8/15/2014 2:30 AM, Robert Schetterer wrote:
>>> Question: Would it make sense to have rules based on dnssec / dane
>>> records exist for a maildomain ?
>>>
>> A) rules have to be used for things that indicate ham or spaminess
>> B) you can only automate something you have done manually
>>
>> So have you looked at this anecdotally and believe there is an
>> indication of ham/spaminess from checking these records?
>>
>> Regards,
>> KAM
> It was just question, i have no preference to this yet,
>
> perhaps thinkable:
>
> tag domains with dane smtp record for hamness, cause its not wide
> provided yet and  identify it as advanced tec skill which results in
> rare send spam too
>

I think detecting dane smtp is a good thing as it gives another
metric to test on.

I don't think it says anything directly about ham/spam, but may be
useful in macros.

DKIM/SPF was widely adopted by spammers fairly early after portions
of the tech community talked about whitelisting authenticated mail. 
You might remember one early point when a significant portion of the
early-adopters were spammers and legit sites hadn't caught up yet.

The same will happen with dane as usage expands -- some clever
spam-support tech will develop a tool to easily mass-configure dane
for throwaway domains.  This isn't necessarily a bad thing in
itself, but it means that the mere presence of dane can't determine
ham/spam.


  -- Noel Jones

Re: dnssec / dane

Posted by Robert Schetterer <rs...@sys4.de>.
Am 15.08.2014 um 16:26 schrieb Kevin A. McGrail:
> On 8/15/2014 2:30 AM, Robert Schetterer wrote:
>> Question: Would it make sense to have rules based on dnssec / dane
>> records exist for a maildomain ?
>>
> A) rules have to be used for things that indicate ham or spaminess
> B) you can only automate something you have done manually
> 
> So have you looked at this anecdotally and believe there is an
> indication of ham/spaminess from checking these records?
> 
> Regards,
> KAM

It was just question, i have no preference to this yet,

perhaps thinkable:

tag domains with dane smtp record for hamness, cause its not wide
provided yet and  identify it as advanced tec skill which results in
rare send spam too


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: dnssec / dane

Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 8/15/2014 2:30 AM, Robert Schetterer wrote:
> Question: Would it make sense to have rules based on dnssec / dane
> records exist for a maildomain ?
>
A) rules have to be used for things that indicate ham or spaminess
B) you can only automate something you have done manually

So have you looked at this anecdotally and believe there is an 
indication of ham/spaminess from checking these records?

Regards,
KAM