Hello everyone,
On 02/23/2012 05:57 AM, Noel Jones wrote:
> You can use an access map in the reinjection listener:
>
> # master.cf
> 127.0.0.1:10026 inet n - n - - smtpd
> ...
> -o
> smtpd_sender_restrictions=check_recipient_access,hash:/etc/postfix/spamtrap
I moved the "check_recipient_access ..." to the reinjection listener on
127.0.0.1:10026, receiving from the SPAMPD proxy filter on
127.0.0.1:10025.
I tried it in both
smtpd_sender_restrictions=
and
smtpd_recipient_restrictions=
which seems to make a bit more sense to my read.
Still no luck - the spamtrap check is never triggered.
> OR you can add rules to your filter to blacklist mail addressed to
> the spamtrap.
I'm not sure what you mean here.
On 02/23/2012 06:06 AM, Stan Hoeppner wrote:
> I'm left wondering why/how you came up with the method you describe above.
> Nobody does it that way. This leads me to believe you don't really understand
> what a spamtrap is.
Perhaps you've misunderstood my intention.
I'm well aware of what a spamtrap address is. I've both seeded them
purposefully, and have 'inherited' them as a result of compromise.
I've been disposing of emails based on inclusion of such spamtrap
address in the recipient list for years.
And I've been doing that with a widely-used, commercially provided
implementation, as have countless others,
http://www.stalker.com/CommuniGatePro/Protection.html#SpamTrap
I am simply trying to achieve the same *outcome* with this new server.
> Maybe it would be helpful if you explained exactly what you're trying to
> do here, and the reasons why you wish to do so. There are likely many
> alternatives that may well work better.
I'm trying to replicate the functionality that has served me well for so
long.
I have a list of compromised addresses. For the sake of this
discussion, let it include, e.g., "s...@myserver.com".
Prior to its compromise, it was verifiable as an existing & valid
"user@domain" in the virtual user/domain (sql) lookup tables.
After compromise, I removed the user from the 'valid user' table, and
added
"s...@myserver.com DISCARD"
to a hash table.
Any email delivered containing this spamtrap-address as any ONE of its
TO:/CC:/BCC: recipient addresses -- even when mixed in with valid
addresses -- is for my uses, certainly and without fail, spam. And I
wish to quietly DISCARD the message for ALL addresses. I.e., it should
be delivered for NOONE.
On 02/23/2012 06:53 AM, /dev/rob0 wrote:
> I see the goal as being, in part, to detect a spammer in THIS
> transaction. That sounds reasonable to me. But the proper thing here
> would be to use a policy service in smtpd_data_restrictions.
I'd have to create a policy service, right? Some sort of additional
filter, or some such? I didn't get to this yet, so some more reading is
required. I'll pore over my book and the site, but any good references
you can share?
> Also I consider it reckless and irresponsible to accept and discard
> mail unless you are absolutely certain it is spam. I would not have
> such confidence in this case.
That's simply an operating choice.
If the spam-address is one of the recipients, I am absolutely sure it's
spam.
The only thing I would find 'reckless and irresponsible' is delivering
such email to ANY of its intended targets.
> If a spammer is paid per delivery, why not reject? That way said
> spammer has to alter the results from his ratware to show more
> delivery success. :)
Because, as I understand it ...
On Thu, Feb 23, 2012, at 09:15 AM, Noel Jones wrote:
> REJECT doesn't really help with multi-recipient mail.
... REJECT fails on the multi-recipient disposal.
At the moment, without the spamtrap check working somewhere,
multi-recipient mail IS delivered to all valid user@domain addresses.
It is currently REJECTED for the "s...@myserver.com", but on the basis
that it's NOT a valid user@domain. That's NOT by any stretch a
sufficient criterion to dispose of the email for all the reset of the
recipients.
Again, the goal is to dispose of the email for ALL the recipients IFF
one or more of the recipients are ID'd as a spamtrap address.
> To block for all recipients you need something that acts on the
> message level, such as DISCARD, or PREPEND a header that you later
> reject in header_checks, or REDIRECT to a forensic account.
DISCARD seem the most straighforward in intention, in that it's doing
exactly what I intend to do.
To be honest, after reading comments, I'm still not yet sure how I'd
implement the spamtrap-based DISCARD.
On Thu, Feb 23, 2012, at 10:31 AM, Wietse Venema wrote:
> > REJECT doesn't really help with multi-recipient mail.
>
> Agreed. rejecting mail that hits a spamtrap would require a flag
> that is raised before DATA time, and that is tested at DATA time.
> However I shudder at the thought of adding more code to the current
> smtpd access engine.
>
> I'd rather go through a lengthy development cycle where a new
> smtpd access engine evolves in parallel with the existing one,
> but that is easier to update.
This is well over my head, but it sounds like that to do what I want to
do will require some new/additional development. Is that correct?
I think I need to sit on my hands for a minute until it dawns on me what
is and isn't "doable" right now.
To be fair, I'm not wedded to one implementation or other. I do
require:
(1) postscreen stays in place
(2) before-queue filtering stays in place
(3) mail sent to a list of recipients that includes one or more
spamtrap addresses listed in a hash table is not delivered for ANY of
the recipients
(4) no inadverdent backscatter is caused by my actions
Thanks for the comments so far.
Cheers,
Roger
--
Roger Garrington
Wilimington, NC
