You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Alex <my...@gmail.com> on 2015/10/06 19:38:40 UTC
Investigating facebook spam
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
Posted by Alex <my...@gmail.com>.
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 "<to...@cox.net>" and it looks like he's got his '@cox.net'
> account
> forwarded to "<to...@example.com>" (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
Posted by David B Funk <db...@engineering.uiowa.edu>.
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
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Investigating facebook spam
Posted by Benny Pedersen <me...@junc.eu>.
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: Investigating facebook spam
Posted by David B Funk <db...@engineering.uiowa.edu>.
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
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Investigating facebook spam
Posted by Benny Pedersen <me...@junc.eu>.
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
Posted by Jered Floyd <je...@convivian.com>.
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 me@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
Posted by Benny Pedersen <me...@junc.eu>.
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
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Tue, 6 Oct 2015, Alex wrote:
> Hi,
>
> On Tue, Oct 6, 2015 at 5:05 PM, Kevin A. McGrail <KM...@pccc.com> 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
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Investigating facebook spam
Posted by Benny Pedersen <me...@junc.eu>.
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
Posted by Benny Pedersen <me...@junc.eu>.
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
Posted by David B Funk <db...@engineering.uiowa.edu>.
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
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Investigating facebook spam
Posted by Benny Pedersen <me...@junc.eu>.
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
Posted by Jered Floyd <je...@convivian.com>.
>> 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:
meta KAM_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
Posted by Benny Pedersen <me...@junc.eu>.
On October 7, 2015 11:40:07 PM Alex <my...@gmail.com> wrote:
>> "Received: from mx-out.facebook.com...." header, why not add the trust
>> path entry?
>
> Great points. Thanks everyone for your comments.
so if i add this to my postfix you will soon see the error ?
Re: Investigating facebook spam
Posted by Alex <my...@gmail.com>.
Hi,
On Wed, Oct 7, 2015 at 10:16 AM, Kris Deugau <kd...@vianet.ca> wrote:
> Alex wrote:
>> On Tue, Oct 6, 2015 at 5:05 PM, Kevin A. McGrail <KMcGrail@pccc.com
>> <ma...@pccc.com>> wrote:
>> 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?
>
> Simpler to update trusted_networks, so then *all* mail forwarded from
> this source will have its "origin" correctly interpreted. I do that
> here for customers whose domain email is hosted elsewhere, but forwarded
> to their ISP account with us.
>
> The question then becomes, how far do you trust the relay host? If you
> don't trust them, you *can't* rely on any Received: header other than
> the one your server added, everything else is suspect and possibly
> spoofed by definition. If you *do* trust them enough to consider the
> "Received: from mx-out.facebook.com...." header, why not add the trust
> path entry?
Great points. Thanks everyone for your comments.
Thanks,
Alex
Re: Investigating facebook spam
Posted by Kris Deugau <kd...@vianet.ca>.
Alex wrote:
> On Tue, Oct 6, 2015 at 5:05 PM, Kevin A. McGrail <KMcGrail@pccc.com
> <ma...@pccc.com>> wrote:
> 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?
Simpler to update trusted_networks, so then *all* mail forwarded from
this source will have its "origin" correctly interpreted. I do that
here for customers whose domain email is hosted elsewhere, but forwarded
to their ISP account with us.
The question then becomes, how far do you trust the relay host? If you
don't trust them, you *can't* rely on any Received: header other than
the one your server added, everything else is suspect and possibly
spoofed by definition. If you *do* trust them enough to consider the
"Received: from mx-out.facebook.com...." header, why not add the trust
path entry?
-kgd
Re: Investigating facebook spam
Posted by Alex <my...@gmail.com>.
Hi,
On Tue, Oct 6, 2015 at 5:05 PM, Kevin A. McGrail <KM...@pccc.com> 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
Posted by RW <rw...@googlemail.com>.
On Thu, 8 Oct 2015 13:59:31 +0100
RW wrote:
> On Thu, 8 Oct 2015 13:13:57 +0100
> RW wrote:
>
> > On Tue, 6 Oct 2015 17:05:48 -0400
> > 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.
> >
> >
> > Assuming that Facebook applies DKIM consistently, I think it would
> > be better to replace:
> >
> > (SPF_FAIL + DKIM_ADSP_ALL >=1)
> >
> > with
> >
> > DKIM_ADSP_ALL && ! (SPF_PASS && __ENV_AND_HDR_FROM_MATCH)
>
> I didn't think that through, there's no scenario where SPF helps, so
> all that's needed is:
Actually, come to think of it, there is a scenario where the internal
network incorporates a third-party forwarding server that doesn't
rewrite the envelope-from, but does break DKIM, but that is pretty rare.
Either version is an improvement over the current rule.
Re: Investigating facebook spam
Posted by RW <rw...@googlemail.com>.
On Thu, 8 Oct 2015 13:13:57 +0100
RW wrote:
> On Tue, 6 Oct 2015 17:05:48 -0400
> 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.
>
>
> Assuming that Facebook applies DKIM consistently, I think it would be
> better to replace:
>
> (SPF_FAIL + DKIM_ADSP_ALL >=1)
>
> with
>
> DKIM_ADSP_ALL && ! (SPF_PASS && __ENV_AND_HDR_FROM_MATCH)
I didn't think that through, there's no scenario where SPF helps, so all
that's needed is:
meta KAM_FACEBOOKMAIL __KAM_FACEBOOKMAIL2 || __KAM_FACEBOOKMAIL1 && DKIM_ADSP_ALL
Re: Investigating facebook spam
Posted by RW <rw...@googlemail.com>.
On Tue, 6 Oct 2015 17:05:48 -0400
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.
Assuming that Facebook applies DKIM consistently, I think it would be
better to replace:
(SPF_FAIL + DKIM_ADSP_ALL >=1)
with
DKIM_ADSP_ALL && ! (SPF_PASS && __ENV_AND_HDR_FROM_MATCH)
This eliminates most of the FPs caused by broken SPF without creating
any extra scope for forgery.
The full rule is then:
meta KAM_FACEBOOKMAIL __KAM_FACEBOOKMAIL2 || __KAM_FACEBOOKMAIL1 && DKIM_ADSP_ALL && !(SPF_PASS && __ENV_AND_HDR_FROM_MATCH)
(The use of __ENV_AND_HDR_FROM_MATCH is really a bit too strict - it
might be useful to have an extra eval rule that only checks the
domains.)
Re: Investigating facebook spam
Posted by Jered Floyd <je...@convivian.com>.
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 <KM...@PCCC.com> 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 dbfunk@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 " <to...@cox.net> " and it looks like he's got his '@cox.net' account
>>> forwarded to " <to...@example.com> " (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
>>> <dbfunk (at) engineering.uiowa.edu> College of Engineering
>>> 319/335-5751 FAX: 319/384-0549 1256 Seamans Center
>>> Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
>>> #include <std_disclaimer.h>
>>> 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)
> KMcGrail@PCCC.com
Re: Investigating facebook spam
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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 dbfunk@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 "<to...@cox.net>" and it looks like he's got his '@cox.net' account
>> forwarded to "<to...@example.com>" (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
>> <dbfunk (at) engineering.uiowa.edu> College of Engineering
>> 319/335-5751 FAX: 319/384-0549 1256 Seamans Center
>> Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
>> #include <std_disclaimer.h>
>> 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)
KMcGrail@PCCC.com <ma...@pccc.com>
Re: Investigating facebook spam
Posted by Jered Floyd <je...@convivian.com>.
Ah; good eyes!
That KAM_FACEBOOK rule is dangerous.
--Jered
----- On Oct 6, 2015, at 4:33 PM, David B Funk dbfunk@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 "<to...@cox.net>" and it looks like he's got his '@cox.net' account
> forwarded to "<to...@example.com>" (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
> <dbfunk (at) engineering.uiowa.edu> College of Engineering
> 319/335-5751 FAX: 319/384-0549 1256 Seamans Center
> Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
> #include <std_disclaimer.h>
> Better is not better, 'standard' is better. B{
Re: Investigating facebook spam
Posted by David B Funk <db...@engineering.uiowa.edu>.
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 "<to...@cox.net>" and it looks like he's got his '@cox.net' account
forwarded to "<to...@example.com>" (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
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Investigating facebook spam
Posted by Jered Floyd <je...@convivian.com>.
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 mysqlstudent@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
Posted by Reindl Harald <h....@thelounge.net>.
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
Re: Investigating facebook spam
Posted by Reindl Harald <h....@thelounge.net>.
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
Re: Investigating facebook spam
Posted by Alex <my...@gmail.com>.
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
Posted by Reindl Harald <h....@thelounge.net>.
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 47370 SPAM
0 20071 HAM
0 2207022 TOKEN
Oct 6 19:55:53 mail-gw postfix/qmgr[10786]: 3nVmgF15WNz29:
from=<no...@facebookmail.com>, size=10644, nrcpt=1
(queue active)
Oct 6 19:55:53 mail-gw spamd[10351]: spamd: processing message
<ca...@www.facebook.com> 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
Re: Investigating facebook spam
Posted by Joe Quinn <jq...@pccc.com>.
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.