Autor: W B Hacker Data: Para: exim users Assunto: Re: [exim] Sender callout verification on BATV signed addresses
David Saez Padros wrote: > Hi
>
>>> it takes less resouces to do the callback at rcpt than at the very
>>> end of the spam filtering
>> You could argue that using N lumps of somebody elses resources is worse
>> than using 10xN lumps of your own. Especially if the 10xN is going idle,
>> which on many systems it is...
>
> we do really very few callouts, zoombies get detected before
> reaching the callout check so we almost do not do callouts for
> mail comming from non real servers, and for real servers without
> spf and that are not whitelist we only do callouts until that
> servers gets whitelisted, which is pretty fast if it's a real
> server not doing weird things.
>
> In the other hand, checking if a user exists or not should
> be quite fast (we don't mind that other do callouts for our
> domains, altough we use spf on all of them)
>
> Anyway if you just want to prevent people doing callout for your
> domains just publish spf records, it will not hurt.
>
'Once upon a time' it needed only a bit of mechanicals and a 'WRU'.
The *carrier* assured the validity of the end-points.
smtp usd what it could find, given the nature of IP.
That meant to publish MX records and PTR records and make sure to HELO with
something that a DNS check could at least 'associate with' those.
As BIND was improved and DNS cache poisoning became more difficult, these turned
out to be pretty reliable. Still hard to forge an IP over any distance, and hard
to beat rDNS for unmasking the 'free range rude'.
But mx & ptr presence and rDNS tests are no longer 'sexy'.
.. and not the 'invention' of anyone looking for fame or promotion in a major
corporation, so...
.. the sort of folk who *were* after their 15-minutes of fame started adding new
mnemonics.
No point in trying to break sysadmins of the bad habit of NOT using what was
already there.
They'll beat you to death for suggesting hard-reject on rDNS fail.
20 years hence, we'll have about 50 more of these spf, DK/DKIM thingies,
call-backs, notes from the sender's Mother, certified copies of vaccination
records, testimonials translated from UTF_bark-speak from the dog that 'e ain't
been beaten that week ... each with clever initials assigned...
And *still* not be rejecting on forward/reverse lookup fail.
Gotta fill all them terabyte drives with *something* and why NOT bloated headers
with the family history of the mnemonics tested? Or forged. And the further
tests to determine a probability figure for each ... and warn, disclaim, or
print the analysis..
After all .. the few bytes of *payload* will be down to 10% of the storage needed.
And 1% of the network traffic it took to negotiate their passage....
