Re: [spfbis] Local macros strike again, was Suggestion...

Perhaps it is also important to remember that SPF is not really an anti 
spam system per se, rather it is a standard which primarily confirms 
that a domain name has indeed been permitted by its holders to send 
messages from a defined set of MTAs.  Obviously, SPF does have some uses 
as regards reducing spam in situations where a bad guy may be hijacking 
a domain name for their spam and thus besmirching the reputation of the 
domain name in the eyes of the receivers of said spam.

So, if a spammer sends a message via a domain which they actually do 
hold (and thus can control DNS and consequentially create appropriate 
SPF or TXT records), their mail would certainly be legitimate from an 
SPF standpoint.  The value of SPF in this case is that the spammer 
cannot then go on to claim that they were not the originators of the 
mail, or that somehow their mail servers were hijacked by some unknown 
bad guy.

A positive SPF eval should always confirm that the sending domain name 
was permitted to send, by DNS configuration, a message via the MTA from 
which the message came.  Thus, all the intended valid email for a domain 
name should make it through to the receiving MTA, while additional MTA 
processing would be needed to address the spammier looking email which 
made it through, as it was before SPF ever existed.

Best,

Alan M.

On 1/23/2012 9:18 AM, Philip Gladstone wrote:
> There is significant value in distinguishing neutral from positive. This
> is when this signal is an input into an anti-spam system. A positive SPF
> eval will (typically) allow slightly spammier looking emails through,
> whereas a neutral would be slightly stricter.
>
> Philip
>
> On 1/22/2012 12:55 AM, Hector Santos wrote:
>> Hi Murray,
>>
>> I guess it all depends on how its written, but my only concern is that
>> no one should get bent out of shape about trying to implement a
>> "default rule" that would apply to all. I say that from the point of
>> view that REJECTION is a strong part of SPF and this best guess idea
>> can only serve a purpose for "reporting," at best, for one data point:
>>
>> The sender and receiver are part of the same network.
>>
>> If this was a fundamental concept for all, i.e. part of the spec, then
>> I can see the default "rule" applying for filters and IMO, we really
>> never would need SPF.
>>
>> But that is not an SMTP setup operational requirement, so I find no
>> value in this default rule other than getting some "interesting data
>> point" about the sender network setup. The Sender/Receiver is part of
>> the same network. So what? It means nothing, at least I don't see it
>> unless a NON-SPF logic is done to see if the MX is black listed or
>> doesn't exist.
>>
>> Per SMTP, an MX is not a requirement and we use a fall back to the A
>> record. If that fails, depending on the implementation it could be
>> filtered. i.e. many systems use a "NO MX/TRIED A record Once" concept
>> when sending mail.
>>
>> --
>>
>>
>> Murray S. Kucherawy wrote:
>>>> -----Original Message-----
>>>> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On
>>>> Behalf Of Hector Santos
>>>> Sent: Wednesday, January 18, 2012 2:46 AM
>>>> To: spfbis@ietf.org
>>>> Subject: Re: [spfbis] Local macros strike again, was Suggestion...
>>>>
>>>>> AFAIK, t-online.de never published SPF records. Some implementers
>>>>> leveraged SPF built-in functions to make "best guesses" about domains
>>>>> lacking SPF records. This tactic is found in many SPF implementations
>>>>> as it will be for years.
>>>> Who?
>>>>
>>>> This must be completed isolated.
>>>
>>> It's not. A Google search for "best guess SPF" comes up with
>>> numerous records, and I've seen it referenced in white papers. And I
>>> know for a fact that Gmail uses it.
>>>
>>> The best definition I've seen is here:
>>> http://www.openspf.net/FAQ/Best_guess_record
>>>
>>> I think part of the -bis effort should include an appendix that talks
>>> about this, albeit informatively, just so that a real consensus
>>> definition exists someplace.
>>>
>>> -MSK
>>> _______________________________________________
>>> spfbis mailing list
>>> spfbis@ietf.org
>>> https://www.ietf.org/mailman/listinfo/spfbis
>>>
>>>
>>
>