Re: SPF rules and my domain

[Matus UHLAR - fantomas]

On 10.12.15 22:54, Alex wrote:

I don't understand why a message from tripadvisor.com would have
SPF_FAIL, and as part of trying to understand how SPF works, I'd like
to figure out what's happening.

Would someone be able to take a look at this message and figure out
why mail from tripadvisor.com fails SPF?

http://pastebin.com/36hzGcTs


On 11.12.15 08:56, Matus UHLAR - fantomas wrote:

the envelope sender seems to be
bounce-15_html-74319930-51788793-10834732...@bounce.e.tripadvisor.com

bounce.e.tripadvisor.com seems to have no SPF record, so I also don't
understand why SPF tests should hit at all, maybe SPF HELO tests...


disregard, please. I made an mistype when checking the SPF records.


The main reason why the mail hits SPF_FAIL is that you don't trust even servers
you receive mail from - first three hops:

h02p01.smtp.routit.net (h02p01.smtp.routit.net [89.146.30.9])
pop3.routit.net ([213.144.235.7])
h03p02.smtp.routit.net (h03p02.smtp.routit.net [89.146.30.18])

that are in X-Spam-RelaysUntrusted header.

the next server in path is:
mta3.e.tripadvisor.com ([66.231.81.9])

that passes the SPF test.

That simply indicates error in yout trust path
http://wiki.apache.org/spamassassin/TrustPath




--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
There's a long-standing bug relating to the x86 architecture that
allows you to install Windows.   -- Matthew D. Fuller

Re: SPF rules and my domain

[Reindl Harald]

Am 11.12.2015 um 17:11 schrieb Alex:

On Fri, Dec 11, 2015 at 10:33 AM, Matus UHLAR - fantomas
 wrote:

On 10.12.15 22:54, Alex wrote:


I don't understand why a message from tripadvisor.com would have
SPF_FAIL, and as part of trying to understand how SPF works, I'd like
to figure out what's happening.

Would someone be able to take a look at this message and figure out
why mail from tripadvisor.com fails SPF?

http://pastebin.com/36hzGcTs


On 11.12.15 08:56, Matus UHLAR - fantomas wrote:


the envelope sender seems to be
bounce-15_html-74319930-51788793-10834732...@bounce.e.tripadvisor.com

bounce.e.tripadvisor.com seems to have no SPF record, so I also don't
understand why SPF tests should hit at all, maybe SPF HELO tests...


disregard, please. I made an mistype when checking the SPF records.

The main reason why the mail hits SPF_FAIL is that you don't trust even
servers
you receive mail from - first three hops:

h02p01.smtp.routit.net (h02p01.smtp.routit.net [89.146.30.9])
pop3.routit.net ([213.144.235.7])
h03p02.smtp.routit.net (h03p02.smtp.routit.net [89.146.30.18])


Is it possible this message was forwarded, breaking the trust path?


when you try to understand a little bit what SPF does the answer is 
clearly yes, any Received header not litest in your trusted_networks or 
internal_networks after the origin server delivered the mail will not 
break SPF but also *every* DNSBL/DNSWL and so fire all sort of 
false-postives as well as false negatives



Reindl wrote:

who is that?
Received: from h03p02.smtp.routit.net (h03p02.smtp.routit.net [89.146.30.18]) 
by pop3.routit.net (Postfix)
with ESMTP id D0A1B42463
for ; Fri, 11 Dec 2015 02:18:21 +0100 (CET)

who is that?
Received: from pop3.routit.net ([213.144.235.7]) by h02p01.smtp.routit.net with 
ESMTP; 11
Dec 2015 02:18:26 +0100

who is that?
Received: from h02p01.smtp.routit.net (h02p01.smtp.routit.net [89.146.30.9]) by 
bwimail02.example.com
(Postfix) with ESMTP id 0F8CA345F25 for ; Thu, 10 
Dec
2015 20:18:38 -0500 (EST)


We're not responsible for the example.nl domain


man that message has *five* Received headers after the tripadvsior 
server - and it smells like a combination of forwarding and fetchmail


Received: from pop3.routit.net ([213.144.235.7]) by 
h02p01.smtp.routit.net with ESMTP; 11 Dec 2015 02:18:26 +0100


Received: from h03p02.smtp.routit.net (h03p02.smtp.routit.net 
[89.146.30.18]) by pop3.routit.net (Postfix) with ESMTP id D0A1B42463 
for ; Fri, 11 Dec 2015 02:18:21 +0100 (CET)



so I don't understand
where that came from. Perhaps that account forwarded it to the
wytze.vandenb...@example.com (our domain) without any other
indications of that having occurred, breaking the trust path?


surely


that are in X-Spam-RelaysUntrusted header.

the next server in path is:
mta3.e.tripadvisor.com ([66.231.81.9])

that passes the SPF test.


What did you need to do to test this?


what do you need to test when "mta3.e.tripadvisor.com" is clearly 
"tripadvisor.com" and that received header is burried in the middle of 
other received headers?




signature.asc
Description: OpenPGP digital signature

Re: SPF rules and my domain

[Alex]

Hi,

On Fri, Dec 11, 2015 at 10:33 AM, Matus UHLAR - fantomas
 wrote:
>> On 10.12.15 22:54, Alex wrote:
>>>
>>> I don't understand why a message from tripadvisor.com would have
>>> SPF_FAIL, and as part of trying to understand how SPF works, I'd like
>>> to figure out what's happening.
>>>
>>> Would someone be able to take a look at this message and figure out
>>> why mail from tripadvisor.com fails SPF?
>>>
>>> http://pastebin.com/36hzGcTs
>
>
> On 11.12.15 08:56, Matus UHLAR - fantomas wrote:
>>
>> the envelope sender seems to be
>> bounce-15_html-74319930-51788793-10834732...@bounce.e.tripadvisor.com
>>
>> bounce.e.tripadvisor.com seems to have no SPF record, so I also don't
>> understand why SPF tests should hit at all, maybe SPF HELO tests...
>
> disregard, please. I made an mistype when checking the SPF records.
>
> The main reason why the mail hits SPF_FAIL is that you don't trust even
> servers
> you receive mail from - first three hops:
>
> h02p01.smtp.routit.net (h02p01.smtp.routit.net [89.146.30.9])
> pop3.routit.net ([213.144.235.7])
> h03p02.smtp.routit.net (h03p02.smtp.routit.net [89.146.30.18])

Is it possible this message was forwarded, breaking the trust path?

Reindal wrote:
> who is that?
> Received: from h03p02.smtp.routit.net (h03p02.smtp.routit.net [89.146.30.18]) 
> by pop3.routit.net (Postfix)
> with ESMTP id D0A1B42463
>for ; Fri, 11 Dec 2015 02:18:21 +0100 (CET)
>
> who is that?
> Received: from pop3.routit.net ([213.144.235.7]) by h02p01.smtp.routit.net 
> with ESMTP; 11
> Dec 2015 02:18:26 +0100
>
> who is that?
> Received: from h02p01.smtp.routit.net (h02p01.smtp.routit.net [89.146.30.9]) 
> by bwimail02.example.com
> (Postfix) with ESMTP id 0F8CA345F25 for ; Thu, 
> 10 Dec
> 2015 20:18:38 -0500 (EST)

We're not responsible for the example.nl domain, so I don't understand
where that came from. Perhaps that account forwarded it to the
wytze.vandenb...@example.com (our domain) without any other
indications of that having occurred, breaking the trust path?

> that are in X-Spam-RelaysUntrusted header.
>
> the next server in path is:
> mta3.e.tripadvisor.com ([66.231.81.9])
>
> that passes the SPF test.

What did you need to do to test this?

Thanks again,
Alex

Re: SPF rules and my domain

[Reindl Harald]

Am 11.12.2015 um 08:56 schrieb Matus UHLAR - fantomas:

I don't understand why a message from tripadvisor.com would have
SPF_FAIL, and as part of trying to understand how SPF works, I'd like
to figure out what's happening.

Would someone be able to take a look at this message and figure out
why mail from tripadvisor.com fails SPF?

http://pastebin.com/36hzGcTs


the envelope sender seems to be
bounce-15_html-74319930-51788793-10834732...@bounce.e.tripadvisor.com

bounce.e.tripadvisor.com seems to have no SPF record, so I also don't
understand why SPF tests should hit at all, maybe SPF HELO tests...


how dou you come to that conclusion and what means "seems" in that 
context - there is a TXT record or there is none - it's has one


;; ANSWER SECTION:
bounce.e.tripadvisor.com. 3600  IN  TXT "v=spf1 
include:cust-spf.exacttarget.com -all"


there is a ton of recievd headres and pretty sure spamassassin is *not* 
running on the MTA and internal_netwroks / trusted_networks is not 
configured properly at all and in that case DNSBL/DNSWL are also not 
wokring properly


that is the last external hop
Received: from mta3.e.tripadvisor.com ([66.231.81.9])
by h03p02.smtp.routit.net with ESMTP; 11 Dec 2015 02:18:24 +0100
_

who is that?
Received: from h03p02.smtp.routit.net (h03p02.smtp.routit.net 
[89.146.30.18]) by pop3.routit.net (Postfix) with ESMTP id D0A1B42463

for ; Fri, 11 Dec 2015 02:18:21 +0100 (CET)

who is that?
Received: from pop3.routit.net ([213.144.235.7]) by 
h02p01.smtp.routit.net with ESMTP; 11 Dec 2015 02:18:26 +0100


who is that?
Received: from h02p01.smtp.routit.net (h02p01.smtp.routit.net 
[89.146.30.9]) by bwimail02.example.com (Postfix) with ESMTP id 
0F8CA345F25 for ; Thu, 10 Dec 2015 
20:18:38 -0500 (EST)




signature.asc
Description: OpenPGP digital signature

Re: SPF rules and my domain

[Reindl Harald]

Am 10.12.2015 um 03:42 schrieb Alex:

If I wanted to use SPF in spamassassin to block spoofing attempts
against my domain, how would I do that?

Can I create a meta that combines SPF_FAIL with the From header for my
domain to do this?


SPF *is not* about the From-Header



signature.asc
Description: OpenPGP digital signature

Re: SPF rules and my domain

[Matus UHLAR - fantomas]

Yes, understood. This was always about my own MTA receiving a message
appearing to be "FROM" my own domain, and my own SPF record would be
used to check the IP of the remote system to determine if it was
permitted. I may have made that especially clear at one point.

Does this make sense now? I'm trying to use my SPF record to verify
mail FROM our domain being received by our MX is not spoofed.


Right, that was understood.

My response was based on how you worded your question, which has been
removed from the thread now:


> > Please help me understand why SPF_FAIL would not be triggered when > >
> > an incoming email using my domain is received by a server that is > > not in
> > my SPF record.


The SPF fail SHOULD be triggered in that case. But in your first mail you
have mentioned T_SPF_PERMERROR hits instead and later you have denied it...

it's hard to explain why it does not work if you don't provide proper info.


I was addressing the apparent assumption within that question that the
recipient MTA matters to SPF validation.


On 09.12.15 21:42, Alex wrote:

I'm not sure if there's a question there, or I'm still confused. It
matters because the recipient MTA is my own.

Spamassassin is just going to record a generic SPF_FAIL, regardless of
whether it's my SPF record or an email from some other domain.

If I wanted to use SPF in spamassassin to block spoofing attempts
against my domain, how would I do that?


If anyone tried to send mail _to_ your MTA spoofing _your_ domain from
_remote_ (not your) IP that is apparently _not_ part of your domain's SPF
recors, your MTA will refuse the mail as SPF_FAIL.

That's exactly what you want, isn't it?

The problem you may encounter is just the opposite: legitimate clients using
your MTA should not be refused.  However they should use SMTP Authentication
and that should be prevented from SPF checks.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Quantum mechanics: The dreams stuff is made of. 

Re: SPF rules and my domain

[Benny Pedersen]

On December 10, 2015 3:49:56 PM Alex  wrote:


whitelist_from_spf: *@example.tld (your domain)
header Return-Path =~ example.tld


That's great. I'll investigate.



or blacklist_from *@* with whitelist_auth *@* to hate all equal :)

Re: SPF rules and my domain

[Kris Deugau]

Benny Pedersen wrote:
> Alex skrev den 2015-12-10 03:42:
> 
>> If I wanted to use SPF in spamassassin to block spoofing attempts
>> against my domain, how would I do that?
>> Can I create a meta that combines SPF_FAIL with the From header for my
>> domain to do this?
> 
> setup pypolicyd-spf is not that hard is it ?
> 
> when done, you just configure the spamassassin plugin to reuse the
> recieved-spf header
> 
> data in spf must be with all mynetworks in postfix except all non
> routeble ips such as rfc1918 in the spf for mydestination and virtual
> domains

No, that's not correct.

Postfix $mynetworks, and the equivalent setting in other MTA software,
lists IP ranges that can use your server as an outgoing relay, for any
sender/recipient pair, without further authentication (let's leave aside
any further policy limits you might want that go in other settings;
this is the basic minimum).

An ISP like the one I work for lists "many" IP ranges in $mynetworks
(we're up to ~15 ranges totalling something like an aggregate /15;
essentially all IP address space we've been assigned from ARIN), because
we want to allow our customers to send out their email through our server.

Most of these IP ranges should NOT be emitting any SMTP traffic to the
Internet at large, at all, period;  they should be using the ISP relay
host or some other authenticated third party mail relay server.  So most
of these IPs are irrelevant for SPF except as failure cases.

SPF lists IPs or IP ranges that may use a particular domain as their
envelope sender.

Our SPF record lists a much MUCH smaller list of IPs and ranges;
essentially, the IP ranges our core mail servers live in.  Those are,
formally speaking, the only IP addresses in the world authorized to use
vianet.ca as their SMTP envelope sender.  Third parties should never see
traffic with a vianet.ca envelope sender directly from any other IP.

Note that our customers are authorized by using our outbound relayhost;
 the third party should not "see" the original sender's connection IP
when doing the SPF check.

There is no requirement that there be any overlap between the two,
although in most cases the SPF list is likely a small subset of $mynetworks.

-kgd

Re: SPF rules and my domain

[Alex]

Hi,

On Thu, Dec 10, 2015 at 10:28 AM, John Hardin <jhar...@impsec.org> wrote:
> On Thu, 10 Dec 2015, Matus UHLAR - fantomas wrote:
>
>>> >  My response was based on how you worded your question, which has been
>>> >  removed from the thread now:
>>> > > > > >  Please help me understand why SPF_FAIL would not be triggered
>>> > > > > > > > > >  when an incoming email using my domain is received by a 
>>> > > > > > > > > > server > >
>>> > > > > > > >  that is not in my SPF record.
>>
>> The SPF fail SHOULD be triggered in that case.
>
> Matus, I think you misread the question. Again: whether or not the
> *receiving* MTA is mentioned in the SPF record is immaterial.
>
> I don't know whether Alex (at the time) misunderstood SPF and asked a
> question based on that misunderstanding, which I tried to clarify, or he
> simply mistyped "by" when he should have typed "from".

Yes, I have no idea why I would have written "by". I meant "from". Too
many hours of SPF at once, I suppose.

Is it possible to test spamassassin SPF rules after a message is
received? I've been unsuccessful:

Dec 10 21:15:02.318 [2402] dbg: spf: relayed through one or more
trusted relays, cannot use header-based Envelope-From, skipping

I don't understand why a message from tripadvisor.com would have
SPF_FAIL, and as part of trying to understand how SPF works, I'd like
to figure out what's happening.

Would someone be able to take a look at this message and figure out
why mail from tripadvisor.com fails SPF?

http://pastebin.com/36hzGcTs

Thanks,
Alex

Re: SPF rules and my domain

[Matus UHLAR - fantomas]

>  My response was based on how you worded your question, which has been
>  removed from the thread now:
> > > > >  Please help me understand why SPF_FAIL would not be triggered
> > > > > > > > >  when an incoming email using my domain is received by a server 
> >
> > > > > > >  that is not in my SPF record.



On Thu, 10 Dec 2015, Matus UHLAR - fantomas wrote:

The SPF fail SHOULD be triggered in that case.



On Thu, Dec 10, 2015 at 10:28 AM, John Hardin <jhar...@impsec.org> wrote:

Matus, I think you misread the question. Again: whether or not the
*receiving* MTA is mentioned in the SPF record is immaterial.

I don't know whether Alex (at the time) misunderstood SPF and asked a
question based on that misunderstanding, which I tried to clarify, or he
simply mistyped "by" when he should have typed "from".


On 10.12.15 22:54, Alex wrote:

Yes, I have no idea why I would have written "by". I meant "from". Too
many hours of SPF at once, I suppose.


I think I've misread the message in the correct way it was meant :-)


Is it possible to test spamassassin SPF rules after a message is
received? I've been unsuccessful:

Dec 10 21:15:02.318 [2402] dbg: spf: relayed through one or more
trusted relays, cannot use header-based Envelope-From, skipping


I think you need to fake header added by your last trusted relay to include
envelope from. Then, SA could accept that. But you need to use correct
format


I don't understand why a message from tripadvisor.com would have
SPF_FAIL, and as part of trying to understand how SPF works, I'd like
to figure out what's happening.

Would someone be able to take a look at this message and figure out
why mail from tripadvisor.com fails SPF?

http://pastebin.com/36hzGcTs


the envelope sender seems to be
bounce-15_html-74319930-51788793-10834732...@bounce.e.tripadvisor.com

bounce.e.tripadvisor.com seems to have no SPF record, so I also don't
understand why SPF tests should hit at all, maybe SPF HELO tests...

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Emacs is a complicated operating system without good text editor.

Re: SPF rules and my domain

[Alex]

Hi,

> > Please help me understand why SPF_FAIL would not be triggered when >
> > >
 > > an incoming email using my domain is received by a server that is >
 > > not in
 > > my SPF record.
>
> The SPF fail SHOULD be triggered in that case. But in your first mail you
> have mentioned T_SPF_PERMERROR hits instead and later you have denied it...

I thought it was related to the sending domain, which it was, but I
later learned one of the includes in our domain was also apparently
expanded, and caused our SPF record to temporarily exceed the 10 DNS
query limit, confusing the entire situation.

> it's hard to explain why it does not work if you don't provide proper info.

I understand. Thank you for being patient.

Thanks,
Alex

Re: SPF rules and my domain

[Alex]

Hi,

>>If I wanted to use SPF in spamassassin to block spoofing attempts
>>against my domain, how would I do that?
>
> Simply put all approved mail servers that you allow to send email with an
> envelope-from domain of your domain in your SPF record and it won't
> matter what the receiving server is.  It can be your server, my server, or
> any SA will hit SPF_PASS.  Then if any other server tries to send with an
> envelope-from of your domain, your SA and others will hit SPF_FAIL.

The problem is that SPF_FAIL has a very low score. I need to make sure
spoofing attempts using my domain are always blocked.

>>Can I create a meta that combines SPF_FAIL with the From header for my
>>domain to do this?
>
> Yes you can but you don't have to.  You should setup scoring and train
> your bayes database so all SPF_FAIL will be blocked equally.  You don't
> have to do any thing special for your own domain spoofing.  Focus on
> getting all domain spoofing detected properly and yours will automatically
> be included.

More specifically, we're being hit by spear-phishing attacks, where
there really are no other rules that hit.

I realize this is only going to get the lazy spammer that actually
tries to spoof the envelope-sender, but that seems to be quite a few
of them.

Thanks so much.
Alex

Re: SPF rules and my domain

[Alex]

Hi,

>> If I wanted to use SPF in spamassassin to block spoofing attempts
>> against my domain, how would I do that?
>> Can I create a meta that combines SPF_FAIL with the From header for my
>> domain to do this?
>
> setup pypolicyd-spf is not that hard is it ?

I mentioned previously that there were some problems with doing that
on fedora. I don't recall what it was, but I'd like to try to use
tools that are already implemented anyway.

> when done, you just configure the spamassassin plugin to reuse the
> recieved-spf header
>
> data in spf must be with all mynetworks in postfix except all non routeble
> ips such as rfc1918 in the spf for mydestination and virtual domains

Doesn't that introduce a trust issue with include: for example? We're
including constant-contact, salesforce, etc. How are these included in
$mynetworks, and wouldn't that mean inherently trusting all of
constant-contact?

> before going live with it, check spf in kittermanns and or dmarchian is
> valid, not after as many do in the past, i have seen ip4:192.168.00/23 in an
> example fail in my logs, no rfc 1918 dont need to be added to spf :=)

Yes, thank you so much. We've already done this.

Thanks,
Alex

Re: SPF rules and my domain

[Alex]

Hi,

>> If I wanted to use SPF in spamassassin to block spoofing attempts
>> against my domain, how would I do that?
>>
>> Can I create a meta that combines SPF_FAIL with the From header for my
>> domain to do this?
>
> This all sounds like:
>
> I (Alex) want to use SPF for incoming email, and score mail that fails
> SPF policy. But I (Alex) know for sure that my own SPF record is
> correct, so for messages that fail my own SPF record, I want a stricter
> policy (i.e. a higher score, or a plain reject).
>
> If this is what you mean, then a meta rule that combines your envelope
> sender domain with SPF_FAIL would be a correct solution.

Yes, that's exactly what I'm trying to do. Phishing attempts go to the
core of trust issues with upper-management.

> Or you could add something like below, which adds a penalty for *all*
> messages using your domain, and SPF saves the real ones.
>
> whitelist_from_spf: *@example.tld (your domain)
> header Return-Path =~ example.tld

That's great. I'll investigate.

Thanks again,
Alex

Re: SPF rules and my domain

[Reindl Harald]

Am 10.12.2015 um 15:43 schrieb Alex:

Hi,


If I wanted to use SPF in spamassassin to block spoofing attempts
against my domain, how would I do that?


Simply put all approved mail servers that you allow to send email with an
envelope-from domain of your domain in your SPF record and it won't
matter what the receiving server is.  It can be your server, my server, or
any SA will hit SPF_PASS.  Then if any other server tries to send with an
envelope-from of your domain, your SA and others will hit SPF_FAIL.


The problem is that SPF_FAIL has a very low score. I need to make sure
spoofing attempts using my domain are always blocked


then set it higher in "local.cf" or simpy accept that it makes no sense 
in SA when you can do that within 5 minutes in your postfix without any SPF



Can I create a meta that combines SPF_FAIL with the From header for my
domain to do this?


Yes you can but you don't have to.  You should setup scoring and train
your bayes database so all SPF_FAIL will be blocked equally.  You don't
have to do any thing special for your own domain spoofing.  Focus on
getting all domain spoofing detected properly and yours will automatically
be included.


More specifically, we're being hit by spear-phishing attacks, where
there really are no other rules that hit.

I realize this is only going to get the lazy spammer that actually
tries to spoof the envelope-sender, but that seems to be quite a few
of them.


most of them are using a From-Header which is not part of SPF but 
visible in the client with a different Envelope, you can't stop them 
anyways, for the lazy ones: do it in the MTA


combined SA metarules don't scale in the configuration



signature.asc
Description: OpenPGP digital signature

Re: SPF rules and my domain

[Reindl Harald]

Am 10.12.2015 um 15:47 schrieb Alex:

data in spf must be with all mynetworks in postfix except all non routeble
ips such as rfc1918 in the spf for mydestination and virtual domains


Doesn't that introduce a trust issue with include: for example? We're
including constant-contact, salesforce, etc. How are these included in
$mynetworks, and wouldn't that mean inherently trusting all of
constant-contact?


just forget SPF and you are done

smtpd_recipient_restrictions =
 .. all your other restictions
 permit_dnswl_client your-won-rbndsnd instance
 check_sender_access hash:/etc/postfix/spoofing_protection.cf

so you can easily skip constant-contact, salesforc and what not and a 
local rbldnsd wird to the anyways needed unbound-instance is configured 
within 5 minutes and *really* protects *your* envelope from get spoofed








signature.asc
Description: OpenPGP digital signature

Re: SPF rules and my domain

[John Hardin]

On Thu, 10 Dec 2015, Matus UHLAR - fantomas wrote:


>  My response was based on how you worded your question, which has been
>  removed from the thread now:
> 
> > > >  Please help me understand why SPF_FAIL would not be triggered 
> > > >  when an incoming email using my domain is received by a server 
> > > >  that is not in my SPF record.


The SPF fail SHOULD be triggered in that case.


Matus, I think you misread the question. Again: whether or not the 
*receiving* MTA is mentioned in the SPF record is immaterial.


I don't know whether Alex (at the time) misunderstood SPF and asked a 
question based on that misunderstanding, which I tried to clarify, or he 
simply mistyped "by" when he should have typed "from".


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  There is no better measure of the unthinking contempt of the
  environmentalist movement for civilization than their call to
  turn off the lights and sit in the dark.-- Sultan Knish
---
 5 days until Bill of Rights day

Re: SPF rules and my domain

[Reindl Harald]

Am 10.12.2015 um 15:56 schrieb Alex:

Please help me understand why SPF_FAIL would not be triggered when >



  > > an incoming email using my domain is received by a server that is >
  > > not in
  > > my SPF record.


The SPF fail SHOULD be triggered in that case. But in your first mail you
have mentioned T_SPF_PERMERROR hits instead and later you have denied it...


I thought it was related to the sending domain, which it was, but I
later learned one of the includes in our domain was also apparently
expanded, and caused our SPF record to temporarily exceed the 10 DNS
query limit, confusing the entire situation.


well, thats the price you have to pay when you spread "your" services 
all over the world, hence the testing-tool i linked :-)




signature.asc
Description: OpenPGP digital signature

Re: SPF rules and my domain

[Martin Gregorie]

On Wed, 2015-12-09 at 08:11 +0100, Reindl Harald wrote:
> 
> T_SPF_PERMERROR says pretty clear that you made something wrong
> why do people not *verify* DNS changes? seen the same from a
> lot of large companies
> 
> http://www.kitterman.com/spf/validate.html
> 
+1 for the Kitterman checking tool - still my first stop for SPF
checking.

I recently found out about another: https://dmarcian.com/spf-survey/
which is also worth using.


Martin

Re: SPF rules and my domain

[Alex]

Hi,

>> T_SPF_PERMERROR says pretty clear that you made something wrong
>> why do people not *verify* DNS changes? seen the same from a
>> lot of large companies
>>
>> http://www.kitterman.com/spf/validate.html
>>
> +1 for the Kitterman checking tool - still my first stop for SPF
> checking.
>
> I recently found out about another: https://dmarcian.com/spf-survey/
> which is also worth using.

Yes, I'm aware of this site. Perhaps I shouldn't have introduced the
T_SPF_PERMERROR issue because it's not really my main problem, and
doesn't even occur on my own domain. I wish I could post my domain,
but I can't.

My main problem is understanding how to build a rule to block spoofing
attempts against my own domain? Do I need to build a meta that
combines envelope FROM with SPF_FAIL?

Thanks,
Alex

Re: SPF rules and my domain

[Reindl Harald]

Am 09.12.2015 um 15:44 schrieb Alex:

T_SPF_PERMERROR says pretty clear that you made something wrong
why do people not *verify* DNS changes? seen the same from a
lot of large companies

http://www.kitterman.com/spf/validate.html


+1 for the Kitterman checking tool - still my first stop for SPF
checking.

I recently found out about another: https://dmarcian.com/spf-survey/
which is also worth using.


Yes, I'm aware of this site. Perhaps I shouldn't have introduced the
T_SPF_PERMERROR issue because it's not really my main problem, and
doesn't even occur on my own domain. I wish I could post my domain,
but I can't.

My main problem is understanding how to build a rule to block spoofing
attempts against my own domain? Do I need to build a meta that
combines envelope FROM with SPF_FAIL?


first: spoofing protection is *only* about envelope and not about the 
visible From-header (spoofing protection based on the header kills 
mailing-lists and even big players like Barracuda networks where dumb 
enugh because customers complained 'but i still get spoofed mails, look 
at my client' insteda explain them it's not possible)


second:
spoofing protection belongs in the MTA long before spamassassin

why?

* you have already on the MTA a list of domains for accept mails
* spoofing protection has *nothing* to do with SPF

smtpd_recipient_restrictions =
 reject_unlisted_recipient
 reject_unauth_destination
 reject_non_fqdn_recipient
 reject_non_fqdn_sender
 reject_non_fqdn_helo_hostname
 reject_invalid_helo_hostname
 check_sender_access hash:/etc/postfix/spoofing_protection.cf

/etc/postfix/spoofing_protection.cf:
domain1 REJECT Sender Spoofed
domain2 REJECT Sender Spoofed
domain3 REJECT Sender Spoofed
___

in short: you take the script which generates "mydestination.cf" and let 
it spit out the other file while write instead "OK" "REJECT"


mydestination = hash:/etc/postfix/mydestination.cf
/etc/postfix/mydestination.cf:
domain1 OK
domain2 OK
domain3 OK
___

before some dumbass now says "the world is not postfix alone": the 
principle is the same for every MTA and some things belong to the mTA 
layer and not in the contentfilter




signature.asc
Description: OpenPGP digital signature

Re: SPF rules and my domain

[Martin Gregorie]

On Wed, 2015-12-09 at 09:44 -0500, Alex wrote:
> My main problem is understanding how to build a rule to block
> spoofing attempts against my own domain? Do I need to build a meta 
> that combines envelope FROM with SPF_FAIL?
> 
Don't forget that SPF fails and errors will always be related to the
*senders* SPF record. 

If you use either SPF checker against your own SPF record all you're
doing is making sure that your SPF record is validly constructed and
correctly describes your domain, its MX records and IP range so that
third parties can avoid hitting you with backscatter when your address
has been forged as the sender of undeliverable spam.

To do what you're currently trying to do:

1) use 'dig' to manually inspect the sender's SPF record using either
the envelope sender domain or the sender domain from the earliest
Received: header on the delivery chain. As Reindl says, ignore the
From: header - if the message is spam its probably forged. 

or 

2) use either of those SPF tools to inspect the sending domain's SPF
record where 'sender domain' is as described in (1). The tools will say
whether the SPF record is junk or not and, if valid, comparing it with
the output from 'host' or 'dig example.com ANY' will tell you if its
content correctly describes the sender.


Martin

Re: SPF rules and my domain

[Alex]

Hi,

>> My main problem is understanding how to build a rule to block spoofing
>> attempts against my own domain? Do I need to build a meta that
>> combines envelope FROM with SPF_FAIL?
>
> first: spoofing protection is *only* about envelope and not about the
> visible From-header (spoofing protection based on the header kills

Yes, I understand that as well, and mentioned that earlier.

> second:
> spoofing protection belongs in the MTA long before spamassassin
>
> why?

Yes, I agree, and also mentioned that, but I wanted to understand the
SPF rules from within spamassassin.

> * spoofing protection has *nothing* to do with SPF

What? That's exactly what SPF was designed to prevent - spoofing of
the envelope sender.

https://en.wikipedia.org/wiki/Sender_Policy_Framework
"SPF is a simple email-validation system designed to detect email
spoofing by providing a mechanism to allow receiving mail exchangers
to check that incoming mail from a domain comes from a host authorized
by that domain's administrators."

> smtpd_recipient_restrictions =
>  reject_unlisted_recipient
>  reject_unauth_destination
>  reject_non_fqdn_recipient
>  reject_non_fqdn_sender
>  reject_non_fqdn_helo_hostname
>  reject_invalid_helo_hostname
>  check_sender_access hash:/etc/postfix/spoofing_protection.cf
>
> /etc/postfix/spoofing_protection.cf:
> domain1 REJECT Sender Spoofed
> domain2 REJECT Sender Spoofed
> domain3 REJECT Sender Spoofed

I'm using postfix, as I mentioned, and understand I can do this, and know how.

Please help me understand why SPF_FAIL would not be triggered when an
incoming email using my domain is received by a server that is not in
my SPF record.

Thanks,
Alex


> ___
>
> in short: you take the script which generates "mydestination.cf" and let it
> spit out the other file while write instead "OK" "REJECT"
>
> mydestination = hash:/etc/postfix/mydestination.cf
> /etc/postfix/mydestination.cf:
> domain1 OK
> domain2 OK
> domain3 OK
> ___
>
> before some dumbass now says "the world is not postfix alone": the principle
> is the same for every MTA and some things belong to the mTA layer and not in
> the contentfilter
>

Re: SPF rules and my domain

[Reindl Harald]

Am 09.12.2015 um 17:30 schrieb Alex:

Hi,


My main problem is understanding how to build a rule to block spoofing
attempts against my own domain? Do I need to build a meta that
combines envelope FROM with SPF_FAIL?


first: spoofing protection is *only* about envelope and not about the
visible From-header (spoofing protection based on the header kills


Yes, I understand that as well, and mentioned that earlier.


second:
spoofing protection belongs in the MTA long before spamassassin

why?


Yes, I agree, and also mentioned that, but I wanted to understand the
SPF rules from within spamassassin.


* spoofing protection has *nothing* to do with SPF


What? That's exactly what SPF was designed to prevent - spoofing of
the envelope sender.


bla - i don't need SPF on a MX to know if my own envelope comes from 
outside - nobody is doing this via SPF just because it's a different 
world when someone spoofs my own domain comapred to a random message 
where the admin probably forgot a machine in his SPF



smtpd_recipient_restrictions =
  reject_unlisted_recipient
  reject_unauth_destination
  reject_non_fqdn_recipient
  reject_non_fqdn_sender
  reject_non_fqdn_helo_hostname
  reject_invalid_helo_hostname
  check_sender_access hash:/etc/postfix/spoofing_protection.cf

/etc/postfix/spoofing_protection.cf:
domain1 REJECT Sender Spoofed
domain2 REJECT Sender Spoofed
domain3 REJECT Sender Spoofed


I'm using postfix, as I mentioned, and understand I can do this, and know how.

Please help me understand why SPF_FAIL would not be triggered when an
incoming email using my domain is received by a server that is not in
my SPF record


it would be triggered but since SA is a scoring system there is no point 
let messages spoofing your own envelopes come so far that they touch the 
contentfilter


since you say "I wish I could post my domain, but I can't" you are 
*really* at your own because very few to no people have the motivation 
working with crystal balls when someone don't provide his own domain and 
the *real* SA headers of a example message




signature.asc
Description: OpenPGP digital signature

Re: SPF rules and my domain

[John Hardin]

On Wed, 9 Dec 2015, Alex wrote:


Please help me understand why SPF_FAIL would not be triggered when an
incoming email using my domain is received by a server that is not in
my SPF record.


I think you mean, *FROM* a server that is not in your SPF record.

SPF says nothing about the *recipient* MTA.

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Perfect Security and Absolute Safety are unattainable; beware
  those who would try to sell them to you, regardless of the cost,
  for they are trying to sell you your own slavery.
---
 6 days until Bill of Rights day

Re: SPF rules and my domain

[Alex]

>> Please help me understand why SPF_FAIL would not be triggered when an
>> incoming email using my domain is received by a server that is not in
>> my SPF record.
>
> I think you mean, *FROM* a server that is not in your SPF record.
>
> SPF says nothing about the *recipient* MTA.

Unless that recipient MTA is my own, correct?

The SPF record contains a list of servers that are allowed to send
mail using my domain, including to my own MX. This can't be used for
spoof protection for my own domain as easily as for remote systems to
ascertain whether an email received by a remote system was sent
legitimately from one of our systems?

Thanks,
Alex

Re: SPF rules and my domain

[John Hardin]

On Wed, 9 Dec 2015, Alex wrote:


Please help me understand why SPF_FAIL would not be triggered when an
incoming email using my domain is received by a server that is not in
my SPF record.


I think you mean, *FROM* a server that is not in your SPF record.

SPF says nothing about the *recipient* MTA.


Unless that recipient MTA is my own, correct?


No. The recipient *does not matter*. SPF is vetting the *sending* MTA.


The SPF record contains a list of servers that are allowed to send
mail using my domain, including to my own MX.


Correct.

This can't be used for spoof protection for my own domain as easily as 
for remote systems to ascertain whether an email received by a remote 
system was sent legitimately from one of our systems?


Yes, it can be used for that purpose. That does not mean the recipient 
matters. Your MTA is just another MTA using SPF to validate the sending 
MTA.


However, that MTA also has the added burden of correctly classifying email 
received from internal sources that do not appear in your public SPF 
record.


SPF_FAIL should not be triggered when somebody else's MTA (which will not 
be in your SPF record) receives a message using your domain *from* your 
MTA (which will be in your SPF record).


If SPF_FAIL triggers in that situation, then SPF is pointless.

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  When I say "I don't want the government to do X", do not
  automatically assume that means I don't want X to happen.
---
 6 days until Bill of Rights day

Re: SPF rules and my domain

[Alex]

Hi,

>>> I think you mean, *FROM* a server that is not in your SPF record.
>>>
>>> SPF says nothing about the *recipient* MTA.
>>
>>
>> Unless that recipient MTA is my own, correct?
>
> No. The recipient *does not matter*. SPF is vetting the *sending* MTA.
>
>> The SPF record contains a list of servers that are allowed to send
>> mail using my domain, including to my own MX.
>
> Correct.
>
>> This can't be used for spoof protection for my own domain as easily as for
>> remote systems to ascertain whether an email received by a remote system was
>> sent legitimately from one of our systems?
>
> Yes, it can be used for that purpose. That does not mean the recipient
> matters. Your MTA is just another MTA using SPF to validate the sending MTA.

That's perhaps the part I didn't make clear. If there is a host
sending mail to me using my domain, my MTA would validate the email
using my own SPF record. This is what I'm trying to do.

> However, that MTA also has the added burden of correctly classifying email
> received from internal sources that do not appear in your public SPF record.

Yes, and I would think that's what $mynetworks in postfix is for.

> SPF_FAIL should not be triggered when somebody else's MTA (which will not be
> in your SPF record) receives a message using your domain *from* your MTA
> (which will be in your SPF record).
>
> If SPF_FAIL triggers in that situation, then SPF is pointless.

Yes, understood. This was always about my own MTA receiving a message
appearing to be "FROM" my own domain, and my own SPF record would be
used to check the IP of the remote system to determine if it was
permitted. I may have made that especially clear at one point.

Does this make sense now? I'm trying to use my SPF record to verify
mail FROM our domain being received by our MX is not spoofed.

I have some sender access restrictions in place with postfix, but I'm
concerned about adding networks to $mynetworks that we don't control
but are authorized to send mail as my domain according to our SPF
record. Hope that makes sense.

Thanks,
Alex

Re: SPF rules and my domain

[Reindl Harald]

Am 09.12.2015 um 18:25 schrieb Alex:

Please help me understand why SPF_FAIL would not be triggered when an
incoming email using my domain is received by a server that is not in
my SPF record.


I think you mean, *FROM* a server that is not in your SPF record.

SPF says nothing about the *recipient* MTA.


Unless that recipient MTA is my own, correct?


SPF don't care about the recipient at all

P.S: get rid auf reply-all on maling-lists



signature.asc
Description: OpenPGP digital signature

Re: SPF rules and my domain

[John Hardin]

On Wed, 9 Dec 2015, Alex wrote:


I think you mean, *FROM* a server that is not in your SPF record.

SPF says nothing about the *recipient* MTA.


Unless that recipient MTA is my own, correct?


No. The recipient *does not matter*. SPF is vetting the *sending* MTA.


The SPF record contains a list of servers that are allowed to send
mail using my domain, including to my own MX.


Correct.


This can't be used for spoof protection for my own domain as easily as for
remote systems to ascertain whether an email received by a remote system was
sent legitimately from one of our systems?


Yes, it can be used for that purpose. That does not mean the recipient
matters. Your MTA is just another MTA using SPF to validate the sending MTA.


That's perhaps the part I didn't make clear. If there is a host
sending mail to me using my domain, my MTA would validate the email
using my own SPF record. This is what I'm trying to do.


Right. That's just "my MTA does SPF checks".


However, that MTA also has the added burden of correctly classifying email
received from internal sources that do not appear in your public SPF record.


Yes, and I would think that's what $mynetworks in postfix is for.


Perhaps. I'm not familiar with postfix, sorry.


SPF_FAIL should not be triggered when somebody else's MTA (which will not be
in your SPF record) receives a message using your domain *from* your MTA
(which will be in your SPF record).

If SPF_FAIL triggers in that situation, then SPF is pointless.


Yes, understood. This was always about my own MTA receiving a message
appearing to be "FROM" my own domain, and my own SPF record would be
used to check the IP of the remote system to determine if it was
permitted. I may have made that especially clear at one point.

Does this make sense now? I'm trying to use my SPF record to verify
mail FROM our domain being received by our MX is not spoofed.


Right, that was understood.

My response was based on how you worded your question, which has been 
removed from the thread now:


> > Please help me understand why SPF_FAIL would not be triggered when 
> > an incoming email using my domain is received by a server that is 
> > not in my SPF record.


I was addressing the apparent assumption within that question that the 
recipient MTA matters to SPF validation.


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@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
---
 6 days until Bill of Rights day

Re: SPF rules and my domain

[Alex]

Hi,

>> Yes, understood. This was always about my own MTA receiving a message
>> appearing to be "FROM" my own domain, and my own SPF record would be
>> used to check the IP of the remote system to determine if it was
>> permitted. I may have made that especially clear at one point.
>>
>> Does this make sense now? I'm trying to use my SPF record to verify
>> mail FROM our domain being received by our MX is not spoofed.
>
> Right, that was understood.
>
> My response was based on how you worded your question, which has been
> removed from the thread now:
>
>> > > Please help me understand why SPF_FAIL would not be triggered when > >
>> > > an incoming email using my domain is received by a server that is > > 
>> > > not in
>> > > my SPF record.
>
> I was addressing the apparent assumption within that question that the
> recipient MTA matters to SPF validation.

I'm not sure if there's a question there, or I'm still confused. It
matters because the recipient MTA is my own.

Spamassassin is just going to record a generic SPF_FAIL, regardless of
whether it's my SPF record or an email from some other domain.

If I wanted to use SPF in spamassassin to block spoofing attempts
against my domain, how would I do that?

Can I create a meta that combines SPF_FAIL with the From header for my
domain to do this?

Thanks again,
Alex

Re: SPF rules and my domain

[Benny Pedersen]

Alex skrev den 2015-12-10 03:42:


If I wanted to use SPF in spamassassin to block spoofing attempts
against my domain, how would I do that?
Can I create a meta that combines SPF_FAIL with the From header for my
domain to do this?


setup pypolicyd-spf is not that hard is it ?

when done, you just configure the spamassassin plugin to reuse the 
recieved-spf header


data in spf must be with all mynetworks in postfix except all non 
routeble ips such as rfc1918 in the spf for mydestination and virtual 
domains


before going live with it, check spf in kittermanns and or dmarchian is 
valid, not after as many do in the past, i have seen ip4:192.168.00/23 
in an example fail in my logs, no rfc 1918 dont need to be added to spf 
:=)

Re: SPF rules and my domain

[David Jones]

>Spamassassin is just going to record a generic SPF_FAIL, regardless of
>whether it's my SPF record or an email from some other domain.

>If I wanted to use SPF in spamassassin to block spoofing attempts
>against my domain, how would I do that?

Simply put all approved mail servers that you allow to send email with an
envelope-from domain of your domain in your SPF record and it won't
matter what the receiving server is.  It can be your server, my server, or
any SA will hit SPF_PASS.  Then if any other server tries to send with an
envelope-from of your domain, your SA and others will hit SPF_FAIL.

>Can I create a meta that combines SPF_FAIL with the From header for my
>domain to do this?

Yes you can but you don't have to.  You should setup scoring and train
your bayes database so all SPF_FAIL will be blocked equally.  You don't
have to do any thing special for your own domain spoofing.  Focus on
getting all domain spoofing detected properly and yours will automatically
be included.

Dave

>Thanks again,
>Alex

Re: SPF rules and my domain

[Tom Hendrikx]

On 10-12-15 03:42, Alex wrote:
> Hi,
> 
>>> Yes, understood. This was always about my own MTA receiving a message
>>> appearing to be "FROM" my own domain, and my own SPF record would be
>>> used to check the IP of the remote system to determine if it was
>>> permitted. I may have made that especially clear at one point.
>>>
>>> Does this make sense now? I'm trying to use my SPF record to verify
>>> mail FROM our domain being received by our MX is not spoofed.
>>
>> Right, that was understood.
>>
>> My response was based on how you worded your question, which has been
>> removed from the thread now:
>>
> Please help me understand why SPF_FAIL would not be triggered when > >
> an incoming email using my domain is received by a server that is > > not 
> in
> my SPF record.
>>
>> I was addressing the apparent assumption within that question that the
>> recipient MTA matters to SPF validation.
> 
> I'm not sure if there's a question there, or I'm still confused. It
> matters because the recipient MTA is my own.
> 
> Spamassassin is just going to record a generic SPF_FAIL, regardless of
> whether it's my SPF record or an email from some other domain.
> 
> If I wanted to use SPF in spamassassin to block spoofing attempts
> against my domain, how would I do that?
> 
> Can I create a meta that combines SPF_FAIL with the From header for my
> domain to do this?
> 

This all sounds like:

I (Alex) want to use SPF for incoming email, and score mail that fails
SPF policy. But I (Alex) know for sure that my own SPF record is
correct, so for messages that fail my own SPF record, I want a stricter
policy (i.e. a higher score, or a plain reject).

If this is what you mean, then a meta rule that combines your envelope
sender domain with SPF_FAIL would be a correct solution.

Or you could add something like below, which adds a penalty for *all*
messages using your domain, and SPF saves the real ones.

whitelist_from_spf: *@example.tld (your domain)
header Return-Path =~ example.tld


Regards,
Tom

Re: SPF rules and my domain

[Reindl Harald]

Am 09.12.2015 um 05:03 schrieb Alex:

I'm having some problems with SPF and hoped someone could help me to
understand. I've just set up SPF for a domain and now trying to make
sure that spamassassin for that domain is properly blocking/scoring
mail attempting to spoof the envelope sender.

I'm seeing a number of emails hit T_SPF_PERMERROR, but not SPF_FAIL


what about tell us the domain?

T_SPF_PERMERROR says pretty clear that you made something wrong
why do people not *verify* DNS changes? seen the same from a
lot of large companies

http://www.kitterman.com/spf/validate.html



signature.asc
Description: OpenPGP digital signature

SPF rules and my domain

[Alex]

Hi,

I'm having some problems with SPF and hoped someone could help me to
understand. I've just set up SPF for a domain and now trying to make
sure that spamassassin for that domain is properly blocking/scoring
mail attempting to spoof the envelope sender.

I'm seeing a number of emails hit T_SPF_PERMERROR, but not SPF_FAIL. I
know SPF_FAIL is a broad rule that doesn't specifically mean SPF
failed for my domain.

I'm seeking a rule that will hit when someone attempts to send mail as
my domain without going through one of my mail servers.

I've investigated a number of the SPF records for which the
T_SPF_PERMERROR hits, and it looks to be malformed SPF records.
However, it's also hit occasionally on my domain. What are the
conditions under which this rule would hit?

Do I need to write a meta that somehow combines SPF_FAIL with my
domain to generate a rule that can be used to score spoof/phishing
emails for my domain?

Should I be able to run an email through "spamassassin -t -D" and have
it evaluate SPF? It seems that once it's received, it's no longer
possible:

Dec  8 22:46:30.700 [19165] dbg: spf: already checked for Received-SPF
headers, proceeding with DNS based checks
Dec  8 22:46:30.700 [19165] dbg: spf: relayed through one or more
trusted relays, cannot use header-based Envelope-From, skipping

I'm using postfix, and will probably eventually reject mail that fails
SPF there, but was having some problems with the current pyspf code,
and would just like to use spamassassin for now.

Thanks,
Alex

Re: SPF rules do not look at spoofed From: address

[francis picabia]

My question has been misunderstood as commentary on SPF, etc.
It is not about SPF, I'm just trying to steer the question towards a
spamassassin tag that can be triggered.

I found a solution with my own rule.
I wasn't sure whether the SA rules referring to 'from' header were
actually meaning sender or exactly what.
I've confirmed they work on the From:
header in the email headers.

This is on MX gateway systems which do not handle outbound email.

In local.cf I added:

# Spoofed email from example.com
header  MYDOMAIN_FROM From =~ /\@example\.com\$/i
score   MYDOMAIN_FROM 0.1

I can see that some emails from things like mailchimp.com or gmail addresses
configured with a from address of my domain are being tagged by this.
It is unlikely we could incorporate the rule with any real weighted
score without getting very restrictive on what people do with outside services.

Re: SPF rules do not look at spoofed From: address

[Martin Gregorie]

On Thu, 2015-02-12 at 15:07 -0400, francis picabia wrote:
 SPF works as designed.  Forget SPF.

Quite: the only real use for SPF is to prevent you inadvertently
spraying innocent people with backscatter. If the sender has been forged
by a spammer and your MTA can't deliver it (usually because the spammer
used an unrecognised recipient name) then an SPF check will show that
the sending IP is wrong and your MTA can drop the message in the bit
bucket rather than sending a reject message to the owner of the forged
sender address. 

 Let's say you want to introduce a spamassassin tag on any
 email where the From: line contains exactly @example.com
 
 I've read the page spamassassinConf.html and it is isn't clear
 to me what envelope_sender_header does.  What would happen
 if it was set to From?
 
Its not what it does so much as who created it. Since its added by the
sending MTA its a bit harder to forge, especially by kiddies trying to
send spam via some social website. The From: header set up by the MUA
means nothing since anybody or anything could have put what they like in
it or even omitted it entirely.

If you run a mail archive, you can consider using that as a whitelist:
only whitelist addresses which your archive says you've previously sent
mail to.


Martin

Re: SPF rules do not look at spoofed From: address

[Dave Warren]

On 2015-02-12 08:17, francis picabia wrote:

Our spamassassin 3.3.1 is marking email with tags like and
SPF_SOFTFAIL and SPF_FAIL, as long as the sender info
is failing the SPF test.  But if the sender passes the test
and the From: address is from our domain, then there
are no SPF tags appearing.

The risk is that users don't look at the sender, only the From:
field of their email, and this can potentially allow phishing.

Has anyone encountered this issue and resolved it?


As others have said, this is by design. Sender-ID attempted to extend 
SPF records to the RFC5322.From header, and was not widely deployed 
because of the massive breakage. It's legacy at this point.


DMARC is a more modern solution, allowing senders to specify that mail 
from their domain must be identified and authenticated, including an 
alignment requirement between the RFC5321.Mail and RFC5322.From domains.


However, using a DMARC quarantine or reject policy causes breakage 
when users attempt to participate in discussion based mailing lists, or 
other systems which modify messages (adding subject tags, adding 
footers, removing existing signatures), so DMARC quarantine or reject 
policies are only really useful for domains which send mail in 
predictable and largely automated ways, which are frequently forged, 
with live users living at another domain for their own mailboxes.


With that being said, there could be some room for ham-detection 
(negative scoring, from a SA perspective) when RFC5322.From headers pass 
parsing of SPF records, but you should not attempt to use any 
spam-detection when there is a mismatch as a mismatch is normal and 
expected behaviour.


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

Re: SPF rules do not look at spoofed From: address

[Dave Warren]

On 2015-02-12 11:27, Martin Gregorie wrote:

On Thu, 2015-02-12 at 15:07 -0400, francis picabia wrote:

SPF works as designed.  Forget SPF.


Quite: the only real use for SPF is to prevent you inadvertently
spraying innocent people with backscatter. If the sender has been forged
by a spammer and your MTA can't deliver it (usually because the spammer
used an unrecognised recipient name) then an SPF check will show that
the sending IP is wrong and your MTA can drop the message in the bit
bucket rather than sending a reject message to the owner of the forged
sender address.


Not at all. SPF is very useful for whitelisting by domain, without 
having to guess at what IPs a sender uses today, might use tomorrow, and 
without having to trust every single thing coming from that IP space.


SPF based whitelisting trivially allows you to whitelist all mail from 
@example.com even if they use Google Apps and you don't want to blanket 
whitelist Google Apps. And it will still work when they transition to 
another provider and don't think to tell you.


It's not effective as a blacklist, nor a spam filter. Nor should it, 
that's not it's design goal; SPF does a /great/ job at telling you when 
a message is directly from a legitimate sender, allowing you to act 
accordingly.


DKIM is similar, it excels at identifying legitimate messages, using 
cryptography that survives forwarders rather than using IPs. More 
complicated to implement, but ultimately, technically, a better solution.


In both cases, it helps you pick out legitimate mail from wanted senders 
which can benefit spam filtering by allowing to you be just a little bit 
more aggressive against unknown senders without raising false positives 
too much in the process.


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

Re: SPF rules do not look at spoofed From: address

[francis picabia]

On Thu, Feb 12, 2015 at 1:46 PM, Benny Pedersen m...@junc.eu wrote:
 On 12. feb. 2015 17.40.13 Kevin A. McGrail kmcgr...@pccc.com wrote:

 Spf deals with the envelope sender not the from address.


 envelope_sender_header From

 bad example to follow, it not really a spf question, sender-id is the
 untrusted version of dkim

 current dmarc rfc have design faults :(

OK, let's phrase it differently.

SPF works as designed.  Forget SPF.
DKIM works as designed.  Forget that.

Let's say you want to introduce a spamassassin tag on any
email where the From: line contains exactly @example.com

I've read the page spamassassinConf.html and it is isn't clear
to me what envelope_sender_header does.  What would happen
if it was set to From?

Would that impact the meaning of from for all SA rules doing header checks?

Re: SPF rules do not look at spoofed From: address

[Benny Pedersen]

On 12. feb. 2015 20.17.44 Dave Warren da...@hireahit.com wrote:


However, using a DMARC quarantine or reject policy causes breakage
when users attempt to participate in discussion based mailing lists, or
other systems which modify messages (adding subject tags, adding
footers, removing existing signatures), so DMARC quarantine or reject
policies are only really useful for domains which send mail in
predictable and largely automated ways, which are frequently forged,
with live users living at another domain for their own mailboxes.


if the maillist preserve dkim signed mails, then dmarc will pass, but yes 
sadly there is maillists that breaks dkim, this is not a design fault, but 
only a admin miss understanding that its not maillist server admins faults, 
but it is


spf is transperent to maillist, and since dkim have no ip at all it will be 
aswell if not breaked


mailman have support for take over ownerships of users dkim signed mails, 
but it will create more problems then it solves, since not many mua clients 
then know how to reply to maillist or to the origin sender to make a 
private mail


thanks to this maillist here its not a problem here, i get dmarc pass, super

note dmarc can break on spf if maillist is not spf protected, but the 
origin sender was

SPF rules do not look at spoofed From: address

[francis picabia]

Our spamassassin 3.3.1 is marking email with tags like and
SPF_SOFTFAIL and SPF_FAIL, as long as the sender info
is failing the SPF test.  But if the sender passes the test
and the From: address is from our domain, then there
are no SPF tags appearing.

The risk is that users don't look at the sender, only the From:
field of their email, and this can potentially allow phishing.

Has anyone encountered this issue and resolved it?

Re: SPF rules do not look at spoofed From: address

[Kevin A. McGrail]

Spf deals with the envelope sender not the from address.  

Beyond that it, you might find dkim to be a better solution to prevent others 
spoofing your domain.
Regards,
KAM

On February 12, 2015 11:17:38 AM EST, francis picabia fpica...@gmail.com 
wrote:
Our spamassassin 3.3.1 is marking email with tags like and
SPF_SOFTFAIL and SPF_FAIL, as long as the sender info
is failing the SPF test.  But if the sender passes the test
and the From: address is from our domain, then there
are no SPF tags appearing.

The risk is that users don't look at the sender, only the From:
field of their email, and this can potentially allow phishing.

Has anyone encountered this issue and resolved it?

Re: SPF rules do not look at spoofed From: address

[Reindl Harald]

Am 12.02.2015 um 17:17 schrieb francis picabia:

Our spamassassin 3.3.1 is marking email with tags like and
SPF_SOFTFAIL and SPF_FAIL, as long as the sender info
is failing the SPF test.  But if the sender passes the test
and the From: address is from our domain, then there
are no SPF tags appearing.

The risk is that users don't look at the sender, only the From:
field of their email, and this can potentially allow phishing.

Has anyone encountered this issue and resolved it?


which issue?
that your own mail to the list don't get rejected?

From: francis picabia fpica...@gmail.com
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])

if you are doing checks on SPF, Sender-Spoofing or PTR on headers you 
don't understand how mail works resulting in break mailing-lists


large mail-filter companies like Barracuda networks did all that 
mistakes long ago multiple times leading in make feature after feature 
unuseable because it breaks legit mail





signature.asc
Description: OpenPGP digital signature

Re: SPF rules do not look at spoofed From: address

[francis picabia]

On Thu, Feb 12, 2015 at 12:33 PM, Kevin A. McGrail kmcgr...@pccc.com wrote:
 Spf deals with the envelope sender not the from address.

 Beyond that it, you might find dkim to be a better solution to prevent
 others spoofing your domain.
 Regards,
 KAM


Thanks for the reply.  Has anyone tried a test like the Spoofing
test available at knowb4.com?

You fill in a form, then they send a test email
from your.b...@example.com , where example.com
is your own domain.

It is not caught by SPF, and it passes DKIM.

I'm talking about inbound email at your MX,
and spoofing of the From address.  Everything
else (sender, helo) matches the origin.


 On February 12, 2015 11:17:38 AM EST, francis picabia fpica...@gmail.com
 wrote:

 Our spamassassin 3.3.1 is marking email with tags like and
 SPF_SOFTFAIL and SPF_FAIL, as long as the sender info
 is failing the SPF test.  But if the sender passes the test
 and the From: address is from our domain, then there
 are no SPF tags appearing.

 The risk is that users don't look at the sender, only the From:
 field of their email, and this can potentially allow phishing.

 Has anyone encountered this issue and resolved it?

Re: SPF rules do not look at spoofed From: address

[Reindl Harald]

Am 12.02.2015 um 17:58 schrieb francis picabia:

On Thu, Feb 12, 2015 at 12:33 PM, Kevin A. McGrail kmcgr...@pccc.com wrote:

Spf deals with the envelope sender not the from address.

Beyond that it, you might find dkim to be a better solution to prevent
others spoofing your domain.


Thanks for the reply.  Has anyone tried a test like the Spoofing
test available at knowb4.com?

You fill in a form, then they send a test email
from your.b...@example.com , where example.com
is your own domain.

It is not caught by SPF, and it passes DKIM.

I'm talking about inbound email at your MX,
and spoofing of the From address.  Everything
else (sender, helo) matches the origin


AGAIN: it's all about envelopes and not From-Headers

YOU CAN NOT prevent spoofing From-Header without reject *for sure* a 
ton of legit mail too including your own to most mailing lists leading 
in a suspended subscription or unsubscribe when you permanently reject 
list mail


there is nothing to to about - period



signature.asc
Description: OpenPGP digital signature

Re: SPF rules do not look at spoofed From: address

[Benny Pedersen]

On 12. feb. 2015 17.40.13 Kevin A. McGrail kmcgr...@pccc.com wrote:


Spf deals with the envelope sender not the from address.


envelope_sender_header From

bad example to follow, it not really a spf question, sender-id is the 
untrusted version of dkim


current dmarc rfc have design faults :(

SPF rules

[Ray Jette]

Good morning,
The SPF_PASS and SPF_HELO_PASS rules hit several hundred messages a day.
I am doing SPF lockup's at the MTA. How do I go about stopping these
tests from within SA?

Thanks,
Ray

Re: SPF rules

[Matus UHLAR - fantomas]

On 02.10.08 10:28, Ray Jette wrote:
 The SPF_PASS and SPF_HELO_PASS rules hit several hundred messages a day.
 I am doing SPF lockup's at the MTA. How do I go about stopping these
 tests from within SA?

if your MTA pushes Received-SPF: headers to the mail, the SA will use it.

There are still many possibilities where SA may use SPF result even if it
passed in (there are some unsure results that score a bit...)
-- 
Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fucking windows! Bring Bill Gates! (Southpark the movie)

Re: SPF rules

[McDonald, Dan]

On Thu, 2008-10-02 at 10:28 -0400, Ray Jette wrote:
 Good morning,
 The SPF_PASS and SPF_HELO_PASS rules hit several hundred messages a day.
 I am doing SPF lockup's at the MTA. How do I go about stopping these
 tests from within SA?

score SPF_PASS 0
score SPF_HELO_PASS 0

or just remove the module from the .pre file that it's loaded from.

-- 
Daniel J McDonald, CCIE #2495, CISSP #78281, CNX
Austin Energy
http://www.austinenergy.com



signature.asc
Description: This is a digitally signed message part

Re: SPF rules

[Ray Jette]

Thanks for the quick reply. Do you know what .pre file this is contained
in? From the /etc/spamassassin directory I ran the following:
grep SPF_PASS *.pre but came up with nothing.

Thanks.

On Thu, 2008-10-02 at 09:44 -0500, McDonald, Dan wrote:
 or just remove the module from the .pre file that it's loaded from.

Re: SPF rules

[Matus UHLAR - fantomas]

 On Thu, 2008-10-02 at 10:28 -0400, Ray Jette wrote:
  Good morning,
  The SPF_PASS and SPF_HELO_PASS rules hit several hundred messages a day.
  I am doing SPF lockup's at the MTA. How do I go about stopping these
  tests from within SA?

On 02.10.08 09:44, McDonald, Dan wrote:
 score SPF_PASS 0
 score SPF_HELO_PASS 0
 
 or just remove the module from the .pre file that it's loaded from.

that's very bad idea. SPF can give good results even using at SA level.
e.g. SPF soft fail means that care should be taken as the mesasge is
suspicious. That means, score is added. Of course, PASS tells nothing, but
there are *FAIL, NEUTRAL etc.
-- 
Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
There's a long-standing bug relating to the x86 architecture that
allows you to install Windows.   -- Matthew D. Fuller

Re: SPF rules

[McDonald, Dan]

On Thu, 2008-10-02 at 10:57 -0400, Ray Jette wrote:
 Thanks for the quick reply. Do you know what .pre file this is contained
 in? From the /etc/spamassassin directory I ran the following:
 grep SPF_PASS *.pre but came up with nothing.

[EMAIL PROTECTED] spamassassin]$ grep -i -C 1 spf *.pre
init.pre-
init.pre:# SPF - perform SPF verification.
init.pre-#
init.pre:loadplugin Mail::SpamAssassin::Plugin::SPF
init.pre-

Although, I do agree with Matus that SPF is low-cost and adds value even
if it is checked elsewhere.

 
 Thanks.
 
 On Thu, 2008-10-02 at 09:44 -0500, McDonald, Dan wrote:
  or just remove the module from the .pre file that it's loaded from.
 
-- 
Daniel J McDonald, CCIE #2495, CISSP #78281, CNX
Austin Energy
http://www.austinenergy.com



signature.asc
Description: This is a digitally signed message part

Re: SPF rules

[Kelson]

Matus UHLAR - fantomas wrote:

Of course, PASS tells nothing, but
there are *FAIL, NEUTRAL etc.


Actually, PASS can tell you quite a bit if you're trying to whitelist a 
specific address or domain (eg. whitelist_from_spf).


--
Kelson Vibber
SpeedGate Communications www.speed.net

Re: SPF rules

[Benny Pedersen]

On Thu, October 2, 2008 16:28, Ray Jette wrote:
 Good morning,

evening here :)

 The SPF_PASS and SPF_HELO_PASS rules hit several hundred messages a day.
 I am doing SPF lockup's at the MTA. How do I go about stopping these
 tests from within SA?

perldoc Mail::SpamAssassin::Conf
perldoc Mail::SpamAssassin::Plugin::SPF

if spf test is adding header to the mail, disable the perl spf code
modules and let spf plugin use the header

if want no spf test at all in sa, disable the plugin in a pre file

-- 
Benny Pedersen
Need more webspace ? http://www.servage.net/?coupon=cust37098

Re: SPF rules

[mouss]

Benny Pedersen wrote:

On Thu, October 2, 2008 16:28, Ray Jette wrote:

Good morning,


evening here :)


it keeps changing here :)




The SPF_PASS and SPF_HELO_PASS rules hit several hundred messages a day.
I am doing SPF lockup's at the MTA. How do I go about stopping these
tests from within SA?


The question is why? If your MTA does SPF checks, then doing them again 
in SA costs nothing if you have a recommended setup (DNS caching).




perldoc Mail::SpamAssassin::Conf
perldoc Mail::SpamAssassin::Plugin::SPF

if spf test is adding header to the mail, disable the perl spf code
modules and let spf plugin use the header

if want no spf test at all in sa, disable the plugin in a pre file



but this will break all things that depend on SPF (including 
whitelist_from_spf, ...). not clear whether OP wants this.