Re: any reason not to block every Softlayer allocation?

[Philip Prindeville]

On Oct 5, 2015, at 10:57 PM, Noel Butler  wrote:

> On 06/10/2015 12:39, Jo Rhett wrote:
> 
>> Sorry, let me restate: I know consequences of blocking large
>> providers. I’m asking if others have found the same to be true, or if
>> there is any reason to give SoftLayer benefit of the doubt?
>> Once in a great while this kind of query generates clueful contact
>> with said provider to get off their tail...
> 
> 
> softlayer is turning into the U.S.'s version of Europe's OVH - many ranges of 
> both are blocked, though the report rate has dropped significantly in months 
> gone by for both, so if you block, leave yourself a note to unblock in 30 
> days or so and see how it pans out.
> 
> Alternatively, if you have a lot of users you provide for that gets legit 
> softlayer mail, just score them high so they always end up in spam folder.


We’ve had issues with softlayer/the planet.  I don’t remember ever seeing a 
response to a single complaint.  Not one.

And some of them are really blatant, like impersonating the FBI.

On thing I’ve noticed is that long-term, legitimate softlayer customers end up 
changing their rDNS (PTR) records, since they don’t have to jump from lily pad 
to lily pad.

The spammers, on the other hand, often don’t go through the trouble because 
they’re not going to be there long enough.

In that case, blocking something like:

X-Spam-Relays-Untrusted =~ /^[^\]]+ 
rdns=\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}-static.reverse.softlayer.com /
X-Spam-Relays-Untrusted =~ /^[^\]]+ 
rdns=\[0-9a-f]{2}\.[0-9a-f]{2}\.[0-9a-f]{4}\.static\.theplanet\.com /


might be the solution.

We found that most of the spam we got from softlayer either included a URL that 
resolved to 104.148.103.2 — which was easy to block with check_url_local_bl() — 
or else contained a message-id which had an email address in it followed by:

[a-z0-9\-\.]{1,6}>$

for instance.

-Philip

Re: Investigating facebook spam

[Joe Quinn]

On 10/6/2015 1:38 PM, Alex wrote:

Hi,

I've received a handful of messages that appear to be facebook
notifications, but fail SPF. They otherwise look completely legit -
links to profiles, only URLs to facebook.com and CDN caching sites,
and even appears to have been routed through facebook's outgoing mail.

All of that could be faked, but it would mean the payload is in the
actual facebook profiles themselves. Has anyone else found this to be
the case?

http://pastebin.com/jE8G5LXJ

Thanks,
Alex
I would say that because it passes DKIM with a signature from 
facebookmail.com, it's likely legitimate and they just suck at SPF 
(wouldn't be the first time a multi-billion dollar company can't get 
anti-forgery right). The rDNS of cox.net seems odd for a CDN, but 
there's not really any standard and I don't know offhand if that's the 
hostname format they use or not.

Re: Investigating facebook spam

[Alex]

HI,

>> I've received a handful of messages that appear to be facebook
>> notifications, but fail SPF. They otherwise look completely legit -
>> links to profiles, only URLs to facebook.com and CDN caching sites,
>> and even appears to have been routed through facebook's outgoing mail.
>>
>> All of that could be faked, but it would mean the payload is in the
>> actual facebook profiles themselves. Has anyone else found this to be
>> the case?
>>
>> http://pastebin.com/jE8G5LXJ
>>
>> Thanks,
>> Alex
>
> I would say that because it passes DKIM with a signature from
> facebookmail.com, it's likely legitimate and they just suck at SPF (wouldn't
> be the first time a multi-billion dollar company can't get anti-forgery
> right). The rDNS of cox.net seems odd for a CDN, but there's not really any
> standard and I don't know offhand if that's the hostname format they use or
> not.

Perhaps then it's worth evaluating KAM_FACEBOOKMAIL for stricter
control on facebook alerts?

Thanks,
Alex

Re: Investigating facebook spam

[Jered Floyd]

Are you operating a backup MX at the cox.net address?  If messages are delayed 
and retried to your backup MX, this would explain the SPF failures.

--Jered

- On Oct 6, 2015, at 1:38 PM, Alex mysqlstud...@gmail.com wrote:

> Hi,
> 
> I've received a handful of messages that appear to be facebook
> notifications, but fail SPF. They otherwise look completely legit -
> links to profiles, only URLs to facebook.com and CDN caching sites,
> and even appears to have been routed through facebook's outgoing mail.
> 
> All of that could be faked, but it would mean the payload is in the
> actual facebook profiles themselves. Has anyone else found this to be
> the case?
> 
> http://pastebin.com/jE8G5LXJ
> 
> Thanks,
> Alex

Re: Investigating facebook spam

[Reindl Harald]

Am 06.10.2015 um 19:38 schrieb Alex:

I've received a handful of messages that appear to be facebook
notifications, but fail SPF. They otherwise look completely legit -
links to profiles, only URLs to facebook.com and CDN caching sites,
and even appears to have been routed through facebook's outgoing mail.

All of that could be faked, but it would mean the payload is in the
actual facebook profiles themselves. Has anyone else found this to be
the case?

http://pastebin.com/jE8G5LXJ


whitelist_auth *@facebookmail.com *@pages.facebookmail.com

and then safely train the junk as spam



signature.asc
Description: OpenPGP digital signature

Re: Investigating facebook spam

[Reindl Harald]

Am 06.10.2015 um 19:44 schrieb Reindl Harald:

Am 06.10.2015 um 19:38 schrieb Alex:

I've received a handful of messages that appear to be facebook
notifications, but fail SPF. They otherwise look completely legit -
links to profiles, only URLs to facebook.com and CDN caching sites,
and even appears to have been routed through facebook's outgoing mail.

All of that could be faked, but it would mean the payload is in the
actual facebook profiles themselves. Has anyone else found this to be
the case?

http://pastebin.com/jE8G5LXJ


whitelist_auth *@facebookmail.com *@pages.facebookmail.com

and then safely train the junk as spam


BTW: i trained your sample with 5 copies (generic date/message-id) as 
spam reaching BAYES_95 and none of the 70 facebook ham-smaples in our 
corpus lost it's BAYES_00




signature.asc
Description: OpenPGP digital signature

Re: Investigating facebook spam

[David B Funk]

On Tue, 6 Oct 2015, Alex wrote:


Hi,

I've received a handful of messages that appear to be facebook
notifications, but fail SPF. They otherwise look completely legit -
links to profiles, only URLs to facebook.com and CDN caching sites,
and even appears to have been routed through facebook's outgoing mail.

All of that could be faked, but it would mean the payload is in the
actual facebook profiles themselves. Has anyone else found this to be
the case?

http://pastebin.com/jE8G5LXJ

Thanks,
Alex


That's because it's a forwarded message. That message was originally sent from
FB to "" and it looks like he's got his '@cox.net' account
forwarded to "" (for what ever '@example.com' should 
really be).


So that explicit forward breaks the SPF chain, thus triggering that SPF fail.
The valid DKIM signature indicates that the message is legit.


--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: Investigating facebook spam

[Kevin A. McGrail]

On 10/6/2015 5:01 PM, Jered Floyd wrote:

Ah; good eyes!

That KAM_FACEBOOK rule is dangerous.
The behavior of forwarding content which effectively is the same as a 
forgery is where the danger lies... If this is behavior that users are 
performing, of course then there needs to be appropriate reaction but 
overall, forwarding emails is going to cause issues with a ton of 
domains and should be discouraged entirely.


Regards,
KAM



--Jered

- On Oct 6, 2015, at 4:33 PM, David B Funk dbf...@engineering.uiowa.edu 
wrote:


On Tue, 6 Oct 2015, Alex wrote:


Hi,

I've received a handful of messages that appear to be facebook
notifications, but fail SPF. They otherwise look completely legit -
links to profiles, only URLs to facebook.com and CDN caching sites,
and even appears to have been routed through facebook's outgoing mail.

All of that could be faked, but it would mean the payload is in the
actual facebook profiles themselves. Has anyone else found this to be
the case?

http://pastebin.com/jE8G5LXJ

Thanks,
Alex

That's because it's a forwarded message. That message was originally sent from
FB to "" and it looks like he's got his '@cox.net' account
forwarded to "" (for what ever '@example.com' should
really be).

So that explicit forward breaks the SPF chain, thus triggering that SPF fail.
The valid DKIM signature indicates that the message is legit.


--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{



--
*Kevin A. McGrail*
CEO

Peregrine Computer Consultants Corporation
3927 Old Lee Highway, Suite 102-C
Fairfax, VA 22030-2422

http://www.pccc.com/

703-359-9700 x50 / 800-823-8402 (Toll-Free)
703-798-0171 (wireless)
kmcgr...@pccc.com 

Re: Investigating facebook spam

[Jered Floyd]

Forwarding email loses a great deal of sender information and thus harms spam 
mitigation, but getting users to never do it will be difficult. There are too 
many things that require you to have (for example) a Google account with 
automatic GMail address that seems to leak out despite attempts to prevent it. 

DKIM and SPF are both valuable tools in our arsenal, and SPF fail isn't enough 
to reject mail. 

--Jered 

- On Oct 6, 2015, at 5:05 PM, Kevin A. McGrail  wrote: 

> On 10/6/2015 5:01 PM, Jered Floyd wrote:

>> Ah; good eyes!

>> That KAM_FACEBOOK rule is dangerous.

> The behavior of forwarding content which effectively is the same as a forgery 
> is
> where the danger lies... If this is behavior that users are performing, of
> course then there needs to be appropriate reaction but overall, forwarding
> emails is going to cause issues with a ton of domains and should be 
> discouraged
> entirely.

> Regards,
> KAM

>> --Jered

>> - On Oct 6, 2015, at 4:33 PM, David B Funk dbf...@engineering.uiowa.edu
>> wrote:

>>> On Tue, 6 Oct 2015, Alex wrote:

 Hi,

 I've received a handful of messages that appear to be facebook
 notifications, but fail SPF. They otherwise look completely legit -
 links to profiles, only URLs to facebook.com and CDN caching sites,
 and even appears to have been routed through facebook's outgoing mail.

 All of that could be faked, but it would mean the payload is in the
 actual facebook profiles themselves. Has anyone else found this to be
 the case? http://pastebin.com/jE8G5LXJ Thanks,
 Alex

>>> That's because it's a forwarded message. That message was originally sent 
>>> from
>>> FB to "  " and it looks like he's got his '@cox.net' 
>>> account
>>> forwarded to "  " (for what ever '@example.com' 
>>> should
>>> really be).

>>> So that explicit forward breaks the SPF chain, thus triggering that SPF 
>>> fail.
>>> The valid DKIM signature indicates that the message is legit.

>>> --
>>> Dave Funk  University of Iowa
>>> College of Engineering
>>> 319/335-5751   FAX: 319/384-0549   1256 Seamans Center
>>> Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
>>> #include 
>>> Better is not better, 'standard' is better. B{

> --
> Kevin A. McGrail
> CEO

> Peregrine Computer Consultants Corporation
> 3927 Old Lee Highway, Suite 102-C
> Fairfax, VA 22030-2422

> http://www.pccc.com/

> 703-359-9700 x50 / 800-823-8402 (Toll-Free)
> 703-798-0171 (wireless)
> kmcgr...@pccc.com

Re: Investigating facebook spam

[Jered Floyd]

Ah; good eyes!

That KAM_FACEBOOK rule is dangerous.

--Jered

- On Oct 6, 2015, at 4:33 PM, David B Funk dbf...@engineering.uiowa.edu 
wrote:

> On Tue, 6 Oct 2015, Alex wrote:
> 
>> Hi,
>>
>> I've received a handful of messages that appear to be facebook
>> notifications, but fail SPF. They otherwise look completely legit -
>> links to profiles, only URLs to facebook.com and CDN caching sites,
>> and even appears to have been routed through facebook's outgoing mail.
>>
>> All of that could be faked, but it would mean the payload is in the
>> actual facebook profiles themselves. Has anyone else found this to be
>> the case?
>>
>> http://pastebin.com/jE8G5LXJ
>>
>> Thanks,
>> Alex
> 
> That's because it's a forwarded message. That message was originally sent from
> FB to "" and it looks like he's got his '@cox.net' account
> forwarded to "" (for what ever '@example.com' should
> really be).
> 
> So that explicit forward breaks the SPF chain, thus triggering that SPF fail.
> The valid DKIM signature indicates that the message is legit.
> 
> 
> --
> Dave Funk  University of Iowa
> College of Engineering
> 319/335-5751   FAX: 319/384-0549   1256 Seamans Center
> Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
> #include 
> Better is not better, 'standard' is better. B{

Re: Investigating facebook spam

[Alex]

Hi,

>> I've received a handful of messages that appear to be facebook
>> notifications, but fail SPF. They otherwise look completely legit -
>> links to profiles, only URLs to facebook.com and CDN caching sites,
>> and even appears to have been routed through facebook's outgoing mail.
>>
>> All of that could be faked, but it would mean the payload is in the
>> actual facebook profiles themselves. Has anyone else found this to be
>> the case?
>>
>> http://pastebin.com/jE8G5LXJ
>>
>> Thanks,
>> Alex
>
>
> That's because it's a forwarded message. That message was originally sent
> from
> FB to "" and it looks like he's got his '@cox.net'
> account
> forwarded to "" (for what ever '@example.com' should
> really be).
>
> So that explicit forward breaks the SPF chain, thus triggering that SPF
> fail.
> The valid DKIM signature indicates that the message is legit.

That's it, thanks so much. I was thinking SPF was broken because of
some kind of routing problem, but didn't realize it was forwarded.

Is it just the routing from mx-out.facebook.com to the cox.net server
then to the example.com server that explains this forwarding, instead
of directly from facebook to example.com that shows this?

I'll work with KAM to have the rule addressed.

Thanks everyone for your ideas.
Alex

Re: Investigating facebook spam

[Reindl Harald]

Am 06.10.2015 um 19:45 schrieb Joe Quinn:

On 10/6/2015 1:38 PM, Alex wrote:

Hi,

I've received a handful of messages that appear to be facebook
notifications, but fail SPF. They otherwise look completely legit -
links to profiles, only URLs to facebook.com and CDN caching sites,
and even appears to have been routed through facebook's outgoing mail.

All of that could be faked, but it would mean the payload is in the
actual facebook profiles themselves. Has anyone else found this to be
the case?

http://pastebin.com/jE8G5LXJ

Thanks,
Alex

I would say that because it passes DKIM with a signature from
facebookmail.com, it's likely legitimate and they just suck at SPF
(wouldn't be the first time a multi-billion dollar company can't get
anti-forgery right). The rDNS of cox.net seems odd for a CDN, but
there's not really any standard and I don't know offhand if that's the
hostname format they use or not


facebook is using a strict SPF policy!

[root@mail-gw:~/training]$ cat spam/*.eml | grep "cox\.net" | wc -l
106
[root@mail-gw:~/training]$ cat ham/*.eml | grep "cox\.net" | wc -l
3

0  47370SPAM
0  20071HAM
02207022TOKEN

Oct  6 19:55:53 mail-gw postfix/qmgr[10786]: 3nVmgF15WNz29: 
from=, size=10644, nrcpt=1 
(queue active)
Oct  6 19:55:53 mail-gw spamd[10351]: spamd: processing message 
 for sa-milt:189
Oct  6 19:55:53 mail-gw spamd[10351]: spamd: result: . -198 - 
CUST_DNSBL_15,CUST_DNSBL_27,CUST_DNSWL_2,CUST_DNSWL_3,CUST_DNSWL_6,SHORTCIRCUIT,SHORTCIRCUIT_NET_HAM,USER_IN_DKIM_WHITELIST,USER_IN_SPF_WHITELIST




signature.asc
Description: OpenPGP digital signature

Re: Investigating facebook spam

[David B Funk]

On Wed, 7 Oct 2015, Benny Pedersen wrote:


David B Funk skrev den 2015-10-07 01:25:

Why do you say "forwarding hosts must use there own domain as envelope 
sender"?


so you like me to use junc.eu domain to send maillists mail to you so spf 
does pass ?


wishfull thinking


I was explicitly talking about "forwarding hosts" NOT mail-list servers.
Yes, mail-list systems SHOULD change the envelope sender, total agreement 
there.




i am not responsible for what damage apache.org does to emails, as long i get 
dmarc pass back from my maillist postings apache.org does a very good 
homework on there server setups



Unless forwarders correctly implement SRS they should NOT change the
envelope sender.


SRS in its own is fail, since it will break dkim signed mails, no ?


SRS should -not- break a properly created DKIM sig anymore than the change of 
the envelope sender by mail-list servers. SRS should only change the envelope 
from address. The whole point of SRS is to fix SPF breakage by forwarding.

https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme


Otherwise in the case of a transport failure the DSN will not make it
back to the originator.


irrelevant


Most people would consider getting delivery failure status reports "relevant".
Why do you consider changing mail transport in a way that breaks DSNs 
"irrelevant"?



--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: Investigating facebook spam

[Benny Pedersen]

David B Funk skrev den 2015-10-07 01:48:

On Wed, 7 Oct 2015, Benny Pedersen wrote:



meta FORGED_DOMAIN ((DKIM_VALID_AU + SPF_PASS) < 2)
meta SPF_FORGED (!SPF_PASS && DKIM_VALID_AU)
meta DKIM_FORGED (!DKIM_VALID_AU && SPF_PASS)

dont know if it works or not, so just shareing it


So you are going to add 3 points to all messages which have neither
SPF listings nor DKIM signatures.


sorry i did forget to score each of them with 100 :=)

Re: Investigating facebook spam

[Alex]

Hi,

On Tue, Oct 6, 2015 at 5:05 PM, Kevin A. McGrail  wrote:

> On 10/6/2015 5:01 PM, Jered Floyd wrote:
>
> Ah; good eyes!
>
> That KAM_FACEBOOK rule is dangerous.
>
> The behavior of forwarding content which effectively is the same as a
> forgery is where the danger lies... If this is behavior that users are
> performing, of course then there needs to be appropriate reaction but
> overall, forwarding emails is going to cause issues with a ton of domains
> and should be discouraged entirely.
>

Can we temper this rule with a check to see if the mail indeed did pass
through a fb server? You're checking the From: header, which can obviously
be easily spoofed, but perhaps if it originated from a facebook server?

Re: Investigating facebook spam

[Jered Floyd]

>> Can we temper this rule with a check to see if the mail indeed did pass 
>> through
>> a fb server? You're checking the From: header, which can obviously be easily
>> spoofed, but perhaps if it originated from a facebook server?

This would be of limited value. As an MTA, you can only believe the present 
knowledge of who has connected to you which you add as a "Received" header. 
Anything earlier than that can be spoofed by the originator. So, it would only 
catch a naive spam. The DKIM signature being valid does what you ask -- DKIM 
means that the message originated from a server with access to the private key 
advertised in the public DNS for the facebookmail.com domain. 

I would argue that DKIM_VALID should trump the other parts of KAM_FACEBOOKMAIL, 
since I can't think of a case where you could have a valid signature on a 
spoofed message. Right now, that rules triggers if either of SPF or DKIM fails: 
metaKAM_FACEBOOKMAIL((__KAM_FACEBOOKMAIL2 >= 1) || 
(__KAM_FACEBOOKMAIL1 >=1 && (SPF_FAIL + DKIM_ADSP_ALL >=1))) 
I would suggest that final "1" in the rule be increased to a "2". Then both SPF 
and DKIM would have to fail for this rule to trigger. 

I'm also really wary of rules that have scores as high as 8.0, but that's a 
separate (and debatable) matter. 

--Jered 

Re: Investigating facebook spam

[Jered Floyd]

It's a brain dead forwarder that does that, but most forwarders are brain dead. 
 "aliases" and ".forward" are the most common things out there.

--Jered

- On Oct 6, 2015, at 7:06 PM, Benny Pedersen m...@junc.eu wrote:

> David B Funk skrev den 2015-10-06 22:33:
> 
>> So that explicit forward breaks the SPF chain, thus triggering that SPF
>> fail.
>> The valid DKIM signature indicates that the message is legit.
> 
> its a brain dead forwarder that use the From: header so, if it used the
> envelope sender it would not break spf, forwarding hosts must use there
> own domain as envelope sender, if thay think we just use From: header it
> breaks spf
> 
> possible that same reason Sender-ID is dropped, and DKIM is now invented
> to replace it

Re: Investigating facebook spam

[Benny Pedersen]

Jered Floyd skrev den 2015-10-07 01:17:

It's a brain dead forwarder that does that, but most forwarders are
brain dead.  "aliases" and ".forward" are the most common things out
there.


+1

Re: Investigating facebook spam

[David B Funk]

On Wed, 7 Oct 2015, Benny Pedersen wrote:


Jered Floyd skrev den 2015-10-07 01:16:


I'm also really wary of rules that have scores as high as 8.0, but
that's a separate (and debatable) matter.



untested:

meta FORGED_DOMAIN ((DKIM_VALID_AU + SPF_PASS) < 2)
meta SPF_FORGED (!SPF_PASS && DKIM_VALID_AU)
meta DKIM_FORGED (!DKIM_VALID_AU && SPF_PASS)

dont know if it works or not, so just shareing it


So you are going to add 3 points to all messages which have neither SPF listings 
nor DKIM signatures.


-AND-

You are going to add 3 points to any message which happens to have an originally 
valid DKIM signature which passed thru a transport MTA which corrupts DKIM 
signature and which has a network glitch that causes its senders SPF records to 
not be available.


I had to disable our DKIM signing system because of a central IT campus exchange 
server that corrupts DKIM sigs, passes the messages on to Office-365 which then 
declares any message with a non-validating DKIM sig as a prima-facea spammy 
message. (Inspite of what the DKIM RFC says, but when has Microsoft cared about 
what RFCs say?)




--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: Investigating facebook spam

[Benny Pedersen]

David B Funk skrev den 2015-10-06 22:33:

So that explicit forward breaks the SPF chain, thus triggering that SPF 
fail.

The valid DKIM signature indicates that the message is legit.


its a brain dead forwarder that use the From: header so, if it used the 
envelope sender it would not break spf, forwarding hosts must use there 
own domain as envelope sender, if thay think we just use From: header it 
breaks spf


possible that same reason Sender-ID is dropped, and DKIM is now invented 
to replace it

Re: Investigating facebook spam

[Benny Pedersen]

Alex skrev den 2015-10-07 00:42:


Can we temper this rule with a check to see if the mail indeed did
pass through a fb server? You're checking the From: header, which can
obviously be easily spoofed, but perhaps if it originated from a
facebook server?


if DKIM pass, its not tempared

Re: Investigating facebook spam

[David B Funk]

On Tue, 6 Oct 2015, Alex wrote:


Hi,

On Tue, Oct 6, 2015 at 5:05 PM, Kevin A. McGrail  wrote:
  On 10/6/2015 5:01 PM, Jered Floyd wrote:

Ah; good eyes!

That KAM_FACEBOOK rule is dangerous.

The behavior of forwarding content which effectively is the same as a forgery 
is where the danger
lies... If this is behavior that users are performing, of course then there 
needs to be appropriate
reaction but overall, forwarding emails is going to cause issues with a ton of 
domains and should
be discouraged entirely.


Can we temper this rule with a check to see if the mail indeed did pass through 
a fb server? You're
checking the From: header, which can obviously be easily spoofed, but perhaps 
if it originated from a
facebook server?


How are you going to determine "if it originated from a facebook server"?
If the message passes thru an untrusted server then almost all stuff is 
potentially suspect.


The only exception to this is if the message has a valid DKIM signature created 
by the originator of the message. So if the message has a verified DKIM 
signature from FB the message should be trustworthy.


It is still the case that that may not work. A message forwarder can modify the 
message enough to break even an originally valid DKIM sig.


So even SPF + DKIM failures shouldn't be enough to automagically declare a 
message as spam.


--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: Investigating facebook spam

[David B Funk]

On Wed, 7 Oct 2015, Benny Pedersen wrote:


David B Funk skrev den 2015-10-06 22:33:

So that explicit forward breaks the SPF chain, thus triggering that SPF 
fail.

The valid DKIM signature indicates that the message is legit.


its a brain dead forwarder that use the From: header so, if it used the 
envelope sender it would not break spf, forwarding hosts must use there own 
domain as envelope sender, if thay think we just use From: header it breaks 
spf


Why do you say "forwarding hosts must use there own domain as envelope sender"?

Unless forwarders correctly implement SRS they should NOT change the envelope 
sender.
Otherwise in the case of a transport failure the DSN will not make it back to 
the originator.


--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: Investigating facebook spam

[Benny Pedersen]

Jered Floyd skrev den 2015-10-07 01:16:


I'm also really wary of rules that have scores as high as 8.0, but
that's a separate (and debatable) matter.



untested:

meta FORGED_DOMAIN ((DKIM_VALID_AU + SPF_PASS) < 2)
meta SPF_FORGED (!SPF_PASS && DKIM_VALID_AU)
meta DKIM_FORGED (!DKIM_VALID_AU && SPF_PASS)

dont know if it works or not, so just shareing it

Re: Investigating facebook spam

[Benny Pedersen]

David B Funk skrev den 2015-10-07 01:25:

Why do you say "forwarding hosts must use there own domain as envelope 
sender"?


so you like me to use junc.eu domain to send maillists mail to you so 
spf does pass ?


wishfull thinking

i am not responsible for what damage apache.org does to emails, as long 
i get dmarc pass back from my maillist postings apache.org does a very 
good homework on there server setups



Unless forwarders correctly implement SRS they should NOT change the
envelope sender.


SRS in its own is fail, since it will break dkim signed mails, no ?


Otherwise in the case of a transport failure the DSN will not make it
back to the originator.


irrelevant

Re: any reason not to block every Softlayer allocation?

[Matthias Leisi]

> Am 06.10.2015 um 04:33 schrieb Jo Rhett :
> 
> Looking at my spam block statistics, not a single IP I’ve reported to 
> SoftLayer over the last two years has been shut down. Is there any reason I 
> shouldn’t just block all their allocations and save myself some effort?

If there are any not yet listed at Spamhaus…

https://www.spamhaus.org/sbl/listings/softlayer.com 


And:

https://www.spamhaus.org/news/article/727/brazilian-internet-users-suffer-softlayers-security-fail
 


— Matthias




smime.p7s
Description: S/MIME cryptographic signature

Re: any reason not to block every Softlayer allocation?

[Gibbs, David]

On 10/5/2015 9:33 PM, Jo Rhett wrote:

Looking at my spam block statistics, not a single IP I’ve reported to
SoftLayer over the last two years has been shut down. Is there any
reason I shouldn’t just block all their allocations and save myself
some effort?


Maybe just add a rule to increase the score for mail from their IP blocks?




--
IBM i on Power Systems: For when you can't afford to be out of business!

I'm riding 100 miles (a full century) in the American Diabetes Association's 
Tour de Cure to raise money for diabetes research, education, advocacy, and 
awareness.  You can make a tax deductible donation to my ride by visiting 
http://gmanesig.diabetessucks.net.  My goal is $6000 but any amount is 
appreciated.

See where I get my donations from ... visit 
http://gmanesig.diabetessucks.net/map for an interactive map (it's a geeky 
thing).

Investigating facebook spam

[Alex]

Hi,

I've received a handful of messages that appear to be facebook
notifications, but fail SPF. They otherwise look completely legit -
links to profiles, only URLs to facebook.com and CDN caching sites,
and even appears to have been routed through facebook's outgoing mail.

All of that could be faked, but it would mean the payload is in the
actual facebook profiles themselves. Has anyone else found this to be
the case?

http://pastebin.com/jE8G5LXJ

Thanks,
Alex