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

[Hector Santos <[e-mail]>]

Philip Gladstone wrote:

>> Hector Santos:
>> I just don't see why you think this has any value.
>>
> I think that the question could be rephrased as:
> 
> For a particular receiving MTA, for all mail senders who do not publish 
> an SPF record, does the addition of "a mx/24 ~all" improve spam 
> detection accuracy or not?
> 
> It is clear that using this record will cause all spam to be marked as 
> ~. 

My Opinion.

I would think an ? (Neutral) would more closer follow technical 
expectations.  A Softfail (~) presumes a specific operational SMTP 
setup for the sender's receiver network being integrated in some 
fashion and since this is not a requirement, presuming a "level" of 
failure would be, IMO, erroneous if its to be reported as a SoftFail 
and there was never an official domain declaration, nor expectation, 
for this practice - a form of misrepsentation and tort.

> Depending on your spam detection algorithm, this may be the level
> that you would select if there was no SPF processing. If this is the 
> case, then the "a mx/24" record will only improve the situation.

IMO, only to get a PASS, at best, which can only yield a data point 
indicating the sender/receiver network is the same or related via the 
"a mx/24" rule. What value does this type of sender/receiver 
operational knowledge offer?

IMO, anything less than a PASS and more than unknown/neutral, i.e, 
soft fail, would have to be determined using some non-SPF logic. 
Perhaps an MX IP "RBL" check or perhaps an CBV on the return path 
which MUST NOT be invalid per 5321.

So it seems to me, this is more about "leveraging" SPF reporting for 
some form of "Failure" checking entirely unrelated to SPF.

Maybe the question is how much does a "A MX/24" rule apply today as 
compared to yester-years?  One can suggest that with multi-core and 
faster OS/hardware, tons of virtual memory, the TCO can be lowered by 
scaling up (more CPU) and reducing scaling out (less machines).  In 
this vain, I can see this rule being increasingly more applicable or 
imaginable to be true using a Pareto 80% of the time, but its still 
not a requirement for systems to be setup like this.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com