Szerző: W B Hacker Dátum: Címzett: exim users Tárgy: Re: [exim] Alias to external server and SPF failure
Graeme Fowler wrote: > On Sun, 2010-05-23 at 17:48 -0400, W B Hacker wrote:
>> And probably would still do so even if 100% of the 'proper' smtp world published
>> such records, simply because WinBots will not.
>
> But... you don't know that.
>
> For any domain that publishes an SPF record, there is a finite (and
> growing) chance that a bot or trojan will attempt to use an address
> within that domain as a sender address.
>
> *That* is what SPF is all about: forgeries.
That part is pointless duplication of effort.
rDNS stops THAT one cold w/o need of extra records.
The backside 'pool' IP have no 'useful' PTR RR et al.
If the 'real' MTA's IP is being forged, that's anopther matter. But SPF records
are no cure for the rare resolver heirarchy compromises. That's a BIND and
sputniks discussion anyway, as it breaks a lot more than just smtp if/as/when it
happens.
Compromise of the LAN approved-relay, smarthost, or credentialed MUA itself so
as to abuse its *valid* AUTH creds is another matter.
But is that a realistic case? And will SPF help if it were to occur?
let's have a look...
>
> Hypothetical example: I register example.com. I provide an SPF record of
> "-all" for example.com, which means "this domain does not send email". I
> also publish an address for people to send *to* - hell, say,
> postmaster@???.
>
> Imagine an outbreak (it's not very hard) of a bot within a corporate
> network. These are hosts behind a NAT firewall, forced to send via
> Windows group policy via a local authenticated SMTP gateway. The bot
> uses the corporate policy to send junk via the corporate mail gateway
> using someone's credentials.
>
The last-mile gateway from whence 'bots can *effectively* jump-off to the
unsuspecting world certainly WILL have proper credentials. And that could as
easily include SPF/SRS as PTR, MX, DK/DKIM et al.
But if there IS NO such MTA, and/or there is one, but the IP block is not meant
to be used for smtp outbound, THAT operator / IP-block holder has to be the one
doing the vetting.
Otherwise his creds and his rep go down the tubes and he is blacklisted as
careless or incompetent - regardless of publlishing the most proper of credentials.
Which, as we all know - does happen. Daily if not hourly.
> Eventually, the bot uses postmaster@??? as the sender address.
>
> Everyone using SPF on inbound mail has their MTA say "whoa, this domain
> uses -all, go away" after only a couple of lookups - or even after only
> one.
>
True as far as it goes. But not actually a likely case.
IF/AS/WHEN that registrant does not want mail leaving his IP block (receiving is
not seen as a problem for this discussion), his best defense is to block
outbound traffic 'TO ANY port 25' in whatever router is best placed to do so.
That stops the unauthorized traffic *at source*, while still allowing his OWN
MTA to send if he so chooses. Cron'ed reports if nothing else...
And it is ALL that he needs.
Voluntary listing in dynamic-IP or other RBL, SPF et al are polite, but no
longer essential.
There IS NO bogus traffic to worry about.
*Absent* such hard blocking, the garbage is let out onto the whole 'net, THEN
AFTERWARDS SPF 'politely' provides a note, and only to those who care to check -
that says in effect. 'Don't blame my carelessness. It wasn't really me'
That's on the same level as hooking your apartment complex's toilets to the
public drinking water supply, then saying 'Oh, BTW, don't drink the part that's
OUR sewage - it shouldn't be there'.
No shit?
;-)
Too little. Too late. No real help.
> I appreciate that the SPF Kool-Aid is strong on the "this is the
> solution" side (or at least it was), which seems to make arguing for SPF
> a weak exercise; however on the flip side the "SPF is a complete waste
> of time" is just as weak.
It isn't a 'complete' waste of time. But its 'real' value - over and above the
still-wise rDNS check - is more attuned to adding to 'positive' vetting'. As in
'not only is all else right and proper, but we ALSO have SPF that says it is OK
to do what they have just done - send traffic'.
BFD.
As most of the 'good guys' actually ARE 'good guys, there isn't much need for
that extra blessing.
The '-all' for a domain.tld that also has the credentials to paas an rDNS check
as you suggest, but chooses NOT to send, is superfluous if they have done their
router management, as there will BE NO such traffic to check.
But if they have NOT also blocked or intercepted such traffic, they can end up
on a blacklist in a New York Minute. Even if they have a '-all' SPF record
published.
Network actions before the fact speak louder than SPF intent after-the-fact.
>
> SPF has its place. Don't discount it just because a number of loud
> voices on both ends of the argument make vociferously opposing points -
> the middle ground, as per usual, is where it's at.
>
> rDNS is not the solution.
NOTHING is a 100% solution.
But rDNS, as peformed by Exim, is more than just a PTR RR verification.
It already covers the most-often abused part of what SPF purports to cover -
forgery detection - and does so when SPF records are not available, and for
senders who might *never* provide such records.
So - of the two, I'd have to give rDNS, reying on records EVERY legitimate
sender has been expected to have for for decades, a 90% plus utility score and
SPF not even a 5%, even if only because so few use it. Or ever will.
> It [rDNS] isn't even a decent placebo
Beg to differ. Anything that stops near-as-dammit 100% of Zombots and similar
forgeries cold with zero falsing as Exim's rDNS does, is a very damn good
'solution' and way the Hell and gone more than a 'placebo'.
> - and neither
> is SPF.
> But in conjunction they can (and do) work fairly well; added to
> other checks they work even more accurately.
>
> Graeme
>
>
Beetle-tracking with a watchmaker's eye-loupe.
What is left after rDNS, protocol, HELO/FQDN, and header format checks -
regardless of how strictly or loosely enforced - can ALWAYS include garbage from
a compromised - or just stoopid - AUTHED MUA-user. Distant OR local.
So one still has to provide for AV, headers, attachment and other content checking.
In that environment, I still cannot get my arms around a case where SPF or SRS
adds 'enough' *unique* functionality to reliably measure, let alone claim value
for. Unless one simply ignores more broadly useful tests. Downright hazardous,
that in a low-takeup SFP world.
