Russell Robinson wrote:
> Hi Bill,
>
> On Sat, 15 May 2010 06:16:06 pm W B Hacker wrote:
>> Short answer is 'you cannot'. Not with enough reliability to matter.
>>
>> Best use is within a grouping of MTA/relays that are all part of a
>> cooperative group - eg - single-control 'pool', or an affinity group, such
>> as a globally distributed F/OSS software project, a body corporate, an
>> institution - anywhere 'family members' are expected to present credentials
>> to be allowed to pass, and the Sysadmins have agreed on how so.
>>
>> Doing sender verification attempts to any correspondent MTA with which you
>> do NOT have such an expectation in-place - read 'the world at large' - will
>> seldom get you a reliable response.
>>
>> ... and may get your calling MTA blacklisted for what some sysadmins
>> consider unwelcome probes - even abuse of their resources.
>
> I'm not sure that's right.
>
> The problem is there are spam traps out there and if you send email to them
> you get blacklisted.
How is that a 'problem'?
IOW *WHY* would you initiate a mail send to a spam trap?
>
> Now, a spammer or malicious person can send you an email claiming to be from
> one of these spam traps.
>
So what?
If you have your head on straight you will have rejected as early as
acl_smtp_connect
>>From my research, the correct way to handle this is to verify that the sender
> is a valid email address.
>
Or at least a 'listed' MX.
But sender verify is not your first line of defense.
It is a trivial exercise for a zombot to respond in the affirmative to even a
bespoke-user sender verification CALLOUT. All it needs is to be programmed to
always so respjond, regardless of addressee.
IF, of course, you fire your query in the direction of the IP from whence
connected instead of looking up the records for the <domain>,<tld> associated
with it.
If there is one. 90% + of the time for these arschloken, there is not.
So your first line of defense is to check that the 'connectee' *server* is legit
- eg - has (a path to) proper published DNS entries. (PTR RR & A RR for-sure, MX
RR as well - hopefully)
rDNS is your friend here:
deny
!condition = [ several lines here. Exempt your user community AUTHing on 587]
!condition = [ exempt some form of VSS whitelist]
!condition = [ exempt cetain relay hosts w/o DNS entries - eg internal LAN]
!verify = reverse_host_lookup
> If you do an SMTP "rcpt" request against that email address, the spam trap
> server will tell you it's not a valid email address. So, you should not send
> to it, and, of course, you (EXIM) should not receive the email it wants to
> send you.
I'll have to take your word for all that. I don't traffic with spam trap
servers. Nor even understand why anyone else would want to.
>
> This can be done at the connect stage when the spammer connects to EXIM to
> attempt to send you the spam.
>
> Here's an article that explains it:
> http://www.dontbouncespam.org/
All well and good. But sender verification is not only NOT the best/only player
in the first line of defense - it is only marginally relevant to the general goal.
What the article you cite points out is the bigger picture:
WHATEVER your reason for rejection - even if a whim or a dice-roll - do it
*while connected*.
Eg *during* the 'original' smtp session.
That is the only time you know with absolute certainty that the 'connectee' is
the one who SHOULD be told and HAS been told, and forged or valid - an 'online'
in-session handshake cannot go to a bystander.
No lookups required.
We try very, very, hard and very, very successfully, to never, ever, send an
out-of-session DSN (bounce) 'OFF BOX'.
It isn't all that hard - just make sure you accept only what is 'yours', then
make sure you always deliver it - even if 'delivery' is to a 'Suspect:'
quarantine folder three levels below a cetacean's latrine. If your filtering is
even half-way decent, it won't see much traffic. Generally less than one
'marginal' message in twenty.
IOW - all rejection is in acl's, none in router/transport sets.
Further, IF/AS/WHEN Exim (or more often, the MLM using Exim) *ass u me's* it
sees a need to generate such noise, the 'errors_to' puts it into my own inbox fo
rmanual follow-up.
>
>> BTW - You should be at not less than 4.6X if 4.7X will not build for you.
>>
>> 4.43 is pretty stale, and there are both needful new features and
>> bug/security fixes since it was current.
>>
>
> Yes. The problem is that there is no RPM for Centos 4.8 that I can find later
> than 4.43.
>
> I'll try compiling 4.6X.
>
