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
