Autor: W B Hacker Data: Dla: exim users Temat: Re: [exim] Alias to external server and SPF failure
Graeme Fowler wrote: > On Sun, 2010-05-23 at 06:25 -0400, W B Hacker wrote:
>> Stone me for an ignorant heathen, but what could possibly be wrong with ignoring
>> BOTH SPF and SRS altogether?
>
> Well... (takes a deep breath):
>
> If a message arrives claiming to be
Therein lies the first major part tale.
I/We don't need SPF to detect that at all.
Not from day-one.
> from user@???, and
> example.com has an SPF record of "-all", and you subsequently either
> send the message through your filters, SpamAssassin, anti-virus and
> perhaps even accept the message then you've completely wasted the
> resources you have assigned to the message.
>
I will have 'assigned' a (probably doubly) cacheable *series of* DNS lookups to
do the rDSN check, p/o said returned info retained for HELO / FQDN check. Or
not. But cheap calls either way.
Even with DNS and local cache, that/those DO constitute arguably higher on-box
total resource load than the simpler SPF go/no-go callout,
BUT...
I will be making that rDNS++ call for all the arrivals that have no SRS/SPF
records anyway...
And probably would still do so even if 100% of the 'proper' smtp world published
such records, simply because WinBots will not.
> You won't actually *know* if SRS is in use - you may be able to deduce
> with high accuracy from the envelope FROM format, but you won't know
> absolutely. I suppose what I'm trying to say there is that you must
> ignore SRS, because usage of it on a remote server has no relevance to
> your server.
>
> All that above is for operators of an MX, ie. those *receiving* mail.
>
ACK.
> "Ignoring" SPF and SRS on outgoing mail is left as an exercise for the
> reader ;-)
>
> Graeme
>
>
The day may come when those with whom we wish to correspond insist that *we*
publish such records.
But it will not be anytime soon that enough do so to matter.
As with DK/DKIM, SRS/SPF and other 'band aid' flavor-of-the-year add-ons...
- All bring *something* useful to the party.
No argument there.
- But most simply don't add *enough* value *enough* of the time for *enough*
players.
They cannot, for example, entirely displace proper 'legacy' credentials and
well-managed ISP networks (port 25 blocked or intercepted to their back-end pools).
Further, as faults or holes are found, each of these 'new features' soon morph
into 'improved' variants. Or are slowly adandoned outright for newer methods.
In every case so far - the faults are found and changes made long before the old
variants have been widely adopted. Worse - too few are backward-compatible or
'sideways' compatible.
Some even break things. Or can do (forwarding?)
So I tend to look at most of these as a form of 'directly interested first
party' managed BL/WL. Often rather ephemeral ones, at that, and - so far -
ALWAYS with spotty coverage.
Do we see more than 2 years in the spotlight?
Deployment/uptake of even 20% 10%? ..... Less?
On which score one is generally better served to trust the 'disinterested'
third-party RBL's.
IF the connection even survives rDNS checks to reach that stage.
Few do.
I'm not opposed to progress.
But these tools would only BE *worthwhile* progress if the legacy DNS system
that has supported forward/reverse lookups since 'day one' of smtp were to
somehow disappear.
