> From: Russell Robinson
> 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.
How do you know?
No, many spamtraps need to accept spam and keep it as evidence.
Moreover, if a spamtrap replies "not a valid email address" to RCPT
then it cannot distinguish between a callout and spam.
> Really?
http://www.backscatterer.org/?target=sendercallouts
> how do you handle this case?
>
> 1. Spammer Sam attempts to send you an email with forged
> address "spamtrap@???".
> 2. Exim verifies sender and accepts the email because spamtraps.org is a
> valid domain (from what you've said).
> 3. You reply to the email because it looks like a genuine enquiry
No, you don't reply to spam, you (a human, unlike software)
very easily see that it's a spam. If a spammer wants a reply
(such as Nigerian scammers) then he specifies a real mailbox in Reply-To,
and your MUA replies to Reply-To (unlike callouts which go to $sender_address).
> (or maybe
> you have an automated "out of office" reply or similar).
Using automated "out of office" can cause your server blacklisted.
Better don't give such ability to your users.
You can decrease (but not eliminate) probability of such blacklisting
by using effective anti-spam means in ACLs ("don't bounce spam").
> 4. You're blacklisted for sending email to a spam trap.
Yes.
> The correct action, as I understand it, is to check
> that "spamtrap@???" is a valid email address (if you try,
> spamtraps.org will report 550 error
It'll not.
> - not a valid address) not just a valid
> domain at step 2.
No, it's the opposite. The checking (callouts) can cause you blacklisted.
> From: W B Hacker <wbh@???>
> As the spammer trying to forge their identity will not be connecting from the
> 'real' spamtraps.org MX (a.mx.niet.net on IP 194.109.153.82), the connection
> will be rejected.
Connecting not from a MX for the domain of sender address
is completely normal and happens very often in real life
with honest messages (ham, not spam).
Existence of PTR and its back-resolving to IP-address is entirely
another matter.
