> The following log excerpt (email addresses changed to protect the
> innocent and guilty), seem to indicate 2 problematic issues with
> spamtraps as implemented in SIMS.
>
> > 18:17:18 1 SMTP-489([200.121.224.249]) SPAM? address
> > <mydomain.comsmtpjim@mydomain.com> is a SpamTrap address
> > 18:17:18 1 SMTP-489([200.121.224.249]) SPAM? address
> > <mydomain.comrobertson@mydomain.com> is a SpamTrap address
> > 18:17:18 1 SMTP-489([200.121.224.249]) SPAM? Recipient
> > '<sales@mydomain.com>' rejected: user unknown
> > 18:17:18 1 SMTP-489([200.121.224.249]) SPAM? The host is now on
> > TempBanned list for the next 1200 seconds
> > 18:17:18 1 SMTP-489([200.121.224.249]) SPAM? Mail from
> > '<apparent.spammer@royalplast.ru>' rejected: SpamTrap
>
> First of all, as you can see, the session (SMTP-489) is not
> terminated upon receiving the first attempt to send to a spamtrap
> address, in the first line. Instead, it another spamtrap contact is
> logged and then an unknown recipient is logged. Shouldn't SMTP-489
> have been killed after line 1?

I'm not 100% positive, but I think that if both of the spamtraps were given
as RCPT arguments in the same SMTP session, SIMS will probably run them
both through the router and log that they are rejected as spamtraps.
Encountering a spamtrap causes SIMS to reject a message for all recipients,
but I think that it ends the SMTP session politely rather than terminating
it abruptly. IOW, it does its address routing, sends rejection messages to
the sending host for all recipients and allows the sending host to
terminate the session normally. After all, if you're going to reject one or
more recipients of a message because they're spamtraps, you don't really
want the sender to know which of the recipients are spamtrapped, which are
deliverable and which are unknown.

> The second issue, which suggests a downside in using spamtrap
> addresses, is that they seem not to be counted toward a tempban. The
> above excerpt had been preceded by 4 rejected: user unknowns from the
> same server. The first 2 items in the excerpted log (spamtraps) are
> evidently not counted toward the tempban threshold, so the tempban is
> not instituted until line 3, effectively, after 7 incorrect addresses.

Sending to spamtrap addresses is not a protocol violation nor are spamtrap
addresses unknown addresses, so they don't count toward tempban.

> It seems to me that if spamtraps are not doing what they are supposed
> to do, and are actually interfering with the useful mechanism that
> automatically blacklists servers that persistently send to bad
> addresses, it is better not to use them.

What makes you think that spamtraps are not doing what they are supposed to
do? Whether the sending host gets tempbanned or not, messages with
spamtrapped recipients are rejected for all recipients. Spamtrap address
are not bad addresses (unknown, unroutable, etc.). SIMS does know about
them, they're defined in its routing table.