Need to clarfiy how to implement spamtrap address checking & discard with before-queue filtering.

[rg8...@airpost.net]

I'm building a Postfix server with postscreen & a before-queue filter.

I'm trying to get spamtraps working so that if a spamtrap address is in
ANY of the recipients, then delivery of the message to ALL recipients is
quietly DISCARDED.

Seems my misreading/misunderstanding of posts has me a bit confused.

My master.cf includes,

192.168.1.10:smtp inet n - n - 1
postscreen

smtpd pass - - n - 20
smtpd
-o smtpd_proxy_filter=inet:127.0.0.1:10025
-o smtpd_proxy_timeout=100s
-o smtpd_proxy_ehlo=$myhostname
-o smtpd_client_connection_count_limit=10
-o smtpd_proxy_options=speed_adjust
-o smtp_send_xforward_command=yes
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
-o disable_mime_output_conversion=yes
-o
smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_non_fqdn_sender,reject_unknown_sender_domain,permit_mynetworks,reject_unknown_recipient_domain,reject_unlisted_recipient,reject_unauth_destination,$spamtraps

Mail receiving and delivery is working OK so far.

main.cf has the $spamtraps definition,

spamtraps = check_recipient_access hash:/etc/postfix/spamtrap

And,

cat /etc/postfix/spamtrap
sp...@rogermail.lan DISCARD
postmap /etc/postfix/spamtrap

With this config, I get in log,

access table hash:/etc/postfix/spamtrap: with smtpd_proxy_filter
specified, action DISCARD is unavailable

A quick search finds this post,

Re: 'smtpd_proxy_filter' and 'action DISCARD'
http://permalink.gmane.org/gmane.mail.postfix.user/222778

Where Wietse comments

As the message suggests, the DISCARD action is not implemented
for
before-queue content filters.

Ok ... and then proposes a workaround,

Maybe the before-queue filter can discard the message instead.

Which seems to suggest doing exactly what's stated as "not implemented"
just above.

I'd like to DISCARD spamtrap-addressed messages as soon as possible in
the process. With my config, what's the right method & place to do
that?

Cheers,

Roger

--
Roger Garrington
Wilimington, NC

[Noel Jones]

On 2/23/2012 2:34 AM, rg8...@airpost.net wrote:
> I'm building a Postfix server with postscreen & a before-queue filter.
>
> I'm trying to get spamtraps working so that if a spamtrap address is in
> ANY of the recipients, then delivery of the message to ALL recipients is
> quietly DISCARDED.

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


OR you can add rules to your filter to blacklist mail addressed to
the spamtrap.

With DISCARD you must receive the whole message anyway, so don't go
overboard trying to optimize "soon as possible".



-- Noel Jones

[Stan Hoeppner]

On 2/23/2012 2:34 AM, rg8...@airpost.net wrote:
> I'm building a Postfix server with postscreen & a before-queue filter.
>
> I'm trying to get spamtraps working so that if a spamtrap address is in
> ANY of the recipients, then delivery of the message to ALL recipients is
> quietly DISCARDED.

This isn't how spamtraps are typically implemented, and may be why
you're having trouble. The proper way to implement a spamtrap for
rejecting inbound spam is:

1. Check recipients of inbound connection for spamtrap address
2. Append new sender address to an access table
3. Use the table in a check_sender_access rule to reject inbound
spam--no need for discard

Pretty simple. 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.

Note that very few people do this. The reason is there are dozens of
spamtrap driven dnsbls freely available that have a few million combined
spamtrap addresses. You have one. Thus, the ROI is typically extremely
low for self run spamtraps.

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.

--
Stan

[/dev/rob0]

On Thu, Feb 23, 2012 at 08:06:34AM -0600, Stan Hoeppner wrote:
> On 2/23/2012 2:34 AM, rg8...@airpost.net wrote:
> > I'm building a Postfix server with postscreen & a before-queue
> > filter.
> >
> > I'm trying to get spamtraps working so that if a spamtrap address
> > is in ANY of the recipients, then delivery of the message to ALL
> > recipients is quietly DISCARDED.
>
> This isn't how spamtraps are typically implemented, and may be why
> you're having trouble. The proper way to implement a spamtrap for
> rejecting inbound spam is:
>
> 1. Check recipients of inbound connection for spamtrap address
> 2. Append new sender address to an access table
> 3. Use the table in a check_sender_access rule to reject inbound
> spam--no need for discard

Why not the client address and check_client_access? I don't see
how/why a sender listing would be useful. Was this a typo or a
"thinko" on your part, Stan? :)

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 fully agree with the reject vs. discard idea. You don't need to
wait for end-of-DATA and waste that bandwidth (offer void where taxed
or prohibited, or where the spammer properly implemented pipelining.)
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.

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. :)

> Pretty simple. 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.
>
> Note that very few people do this. The reason is there are dozens
> of spamtrap driven dnsbls freely available that have a few million
> combined spamtrap addresses. You have one. Thus, the ROI is
> typically extremely low for self run spamtraps.

Agree here too, and with this:

> 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.
--

http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

[Noel Jones]

On 2/23/2012 8:06 AM, Stan Hoeppner wrote:
> Pretty simple. 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.

REJECT doesn't really help with multi-recipient mail.

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.


-- Noel Jones

[Wietse Venema]

Noel Jones:

> On 2/23/2012 8:06 AM, Stan Hoeppner wrote:
> > Pretty simple. 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.
>
> 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.

Wietse

[rg8...@airpost.net]

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., "sp...@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

"sp...@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 "sp...@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.

[Noel Jones]

On 2/23/2012 10:28 AM, rg8...@airpost.net wrote:
> 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=

Yes, that's where it goes unless you've (unwisely) set
smtpd_delay_reject=no.

>
> and
>
> smtpd_recipient_restrictions=

That works too, but needs additional settings. Simpler to put it in
smtpd_sender_restrictions.

>
> which seems to make a bit more sense to my read.
>
> Still no luck - the spamtrap check is never triggered.

For reporting a problem, please see:
http://www.postfix.org/DEBUG_README.html#mail

> 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.

Recipient checks in smtpd_data_restrictions are ineffective with
multi-recipient mail. When there are multiple recipients,
check_recipient_access cannot be performed and is silently skipped,
and policy services are supplied an empty recipient value.
http://www.postfix.org/postconf.5.html#smtpd_data_restrictions

As a general rule, avoid doing recipient checks in
smtpd_data_restrictions.


-- Noel Jones

[/dev/rob0]

On Thu, Feb 23, 2012 at 08:28:05AM -0800,
rg8...@airpost.net wrote:
> 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?

A policy service is an external daemon, yes. Examples of such which
are in common use include policyd and postfwd.

> 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?

http://www.postfix.org/SMTPD_POLICY_README.html and the sites for
both aforementioned third-party projects.

> > 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.

Most spam trap operators are not so confident. There are possible
ways in which legitimate senders might accidentally hit a spamtrap.
Similarly, a hostile third party could submit spamtrap addresses to
listservs and legitimate bulk mailers. Granted, multi-recipient mail
including spamtrap addresses is unlikely to be seen from responsible
bulk mailers, but what if Aunt Minnie made a stray click in her mail
client, or mistyped a few characters ... ?

Typical spamtrap-driven DNSBL services look for multiple hits for
spamtrap addresses, not just one, to make a listing decision. Or in
some cases such as CBL, they combine the envelope check with content
examination.

My view remains unchanged; I would not do what you are describing.
Naturally you are free to disagree and do it anyway, but by posting
here, you opened it up for opinions, and you got mine.

> 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.

> 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'm still not clear on why a REJECT (or any other valid access(5)
result, DISCARD included) wouldn't work with a check_policy_service
lookup at DATA, but I have to defer to Wietse and Noel. I hope either
of them will explain where I am wrong about this.

<pause to check>

<Explanation received from Noel>

> >> would be to use a policy service in smtpd_data_restrictions.
>
> Recipient checks in smtpd_data_restrictions are ineffective with
> multi-recipient mail. When there are multiple recipients,
> check_recipient_access cannot be performed and is silently skipped,
> and policy services are supplied an empty recipient value.
> http://www.postfix.org/postconf.5.html#smtpd_data_restrictions

Oh, thanks. But in theory could this work if the policy daemon was
checked twice, once in smtpd_recipient_restrictions and then again in
smtpd_data_restrictions?

I can see that it might be a challenge to ensure that the RCPT TO
check is correlated with the DATA check, but protocol_state=DATA
might then look to see what happened from the same helo_name /
client_address et c. at protocol_state=RCPT ? Or ... /me RTFMs ...

* The "instance" attribute value can be used to correlate
different requests regarding the same message delivery. ...

I apologize if I have muddied up the issue here, but at least I am
learning something, and maybe others will too. :)

[Wietse Venema]

Wietse:

> Agreed. rejecting mail that hits a spamtrap would require a
> flag that is raised before DATA time, and that is tested at
> DATA time.

/dev/rob0:

> I'm still not clear on why a REJECT (or any other valid access(5)
> result, DISCARD included) wouldn't work with a check_policy_service
> lookup at DATA, but I have to defer to Wietse and Noel. I hope either

At DATA time, recipient-based features are undefined for multi-recipient
mail. Such things are beyond what is possible with the built-in
access language.

With the current access language, a policy daemon would have to
maintain state (the afore-mentioned flag) about preceding queries
for the same mail trasaction (the same "instance" attribute) and
then reject mail at DATA time.

Wietse

[rg8...@airpost.net]

Hello,

On 02/23/2012 08:55 AM, Noel Jones wrote:
>> smtpd_sender_restrictions=
>
> Yes, that's where it goes unless you've (unwisely) set
> smtpd_delay_reject=no.

I have not set that.

>> and
>>
>> smtpd_recipient_restrictions=
>
> That works too, but needs additional settings. Simpler to put it in
> smtpd_sender_restrictions.

Ok. SImpler is better. I'll put it there.

>> Still no luck - the spamtrap check is never triggered.
>
> For reporting a problem, please see: http://www.postfix.org/DEBUG_README.html#mail

Follows below.

> As a general rule, avoid doing recipient checks in smtpd_data_restrictions.

Got it.

> Reporting problems to postfi...@postfix.org

> A summary of the problem. Please do not just send some logging without explanation of what YOU believe is wrong.

I'm trying to get spamtrap recipient address detection and subsequent
all-recipient DISCARD of the message, as advised in this thread, I added
to the "reinjection listener",

-o
smtpd_sender_restrictions=check_recipient_access,hash:/etc/postfix/spamtrap

After a

postfix reload
postsuper -d ALL
service postfix restart

When I test-send a 2-recipient message, where one recipient is the
hash-table-identified spamtrap address,

sendmail -i -t
From: ro...@deskmail.rogermail.lan
To: ro...@mail.rogermail.lan,sp...@mail.rogermail.lan
Subject: test
testing

Instead of DISCARDing the message for both recipients,
the "spam@" recipient is rejected for "User unknown in virtual mailbox
table", and
the "roger@" recipient is accepted & delivered via lmtp to my local mail
store.

I don't know if that's because I misconfigured or misused something, or
there's a problem.

So I'm including

> Complete error messages.
> Postfix logging.

tail -f /var/log/mail ==>
-----------------------------------------------------------------------
Feb 23 09:37:15 mx postfix/postscreen[17166]: cache
/var/lib/postfix/postscreen_cache.db full cleanup: retained=3 dropped=0
entries
Feb 23 09:37:16 mx postfix/postscreen[17166]: PASS OLD
[192.168.1.13]:43486
Feb 23 09:37:16 mx postfix/smtpd[17175]: connect from
deskmail.rogermail.lan[192.168.1.13]
Feb 23 09:37:16 mx postfix/smtpd[17175]: NOQUEUE:
client=deskmail.rogermail.lan[192.168.1.13]
Feb 23 09:37:16 mx postfix/smtpd[17175]: NOQUEUE: reject: RCPT from
deskmail.rogermail.lan[192.168.1.13]: 550 5.1.1
<sp...@mail.rogermail.lan>: Recipient address rejected: User unknown in
virtual mailbox table; from=<ro...@deskmail.rogermail.lan>
to=<sp...@mail.rogermail.lan> proto=ESMTP helo=<deskmail.rogermail.lan>
Feb 23 09:37:16 mx postfix/smtpd[17183]: connect from
localhost[127.0.0.1]
Feb 23 09:37:16 mx postfix/smtpd[17183]: 8B81B20337:
client=localhost[127.0.0.1],
orig_client=deskmail.rogermail.lan[192.168.1.13]
Feb 23 09:37:16 mx spampd[32019]: processing message
<201202231737...@deskmail.rogermail.lan> for
<ro...@mail.rogermail.lan> ORCPT=rfc822;ro...@mail.rogermail.lan
Feb 23 09:37:26 mx spampd[32019]: clean message
<201202231737...@deskmail.rogermail.lan> (0.80/4.00) from
<ro...@deskmail.rogermail.lan> for <ro...@mail.rogermail.lan>
ORCPT=rfc822;ro...@mail.rogermail.lan in 9.56s, 602 bytes.
Feb 23 09:37:26 mx postfix/cleanup[17186]: 8B81B20337:
message-id=<201202231737...@deskmail.rogermail.lan>
Feb 23 09:37:26 mx postfix/qmgr[16440]: 8B81B20337:
from=<ro...@deskmail.rogermail.lan>, size=1066, nrcpt=1 (queue active)
Feb 23 09:37:26 mx postfix/smtpd[17175]: proxy-accept: END-OF-MESSAGE:
250 2.0.0 Ok: queued as 8B81B20337; from=<ro...@deskmail.rogermail.lan>
to=<ro...@mail.rogermail.lan> proto=ESMTP helo=<deskmail.rogermail.lan>
Feb 23 09:37:26 mx postfix/smtpd[17175]: disconnect from
deskmail.rogermail.lan[192.168.1.13]
Feb 23 09:37:26 mx postfix/smtpd[17183]: disconnect from
localhost[127.0.0.1]
Feb 23 09:37:26 mx postfix/lmtp[17212]: 8B81B20337:
to=<ro...@mail.rogermail.lan>,
relay=mail.rogermail.lan[private/dovecot-lmtp], delay=10,
delays=9.7/0.02/0.03/0.23, dsn=2.0.0, status=sent (250 2.0.0
<ro...@mail.rogermail.lan> ihjKFVZ5Rk89QwAAwJ+ohQ Saved)
Feb 23 09:37:26 mx postfix/qmgr[16440]: 8B81B20337: removed
-----------------------------------------------------------------------


> Output from "postconf -n". Please do not send your main.cf file, or 500+ lines of postconf output.
> Better, provide output from the postfinger tool. This can be found at http://ftp.wl0.org/SOURCES/postfinger.

The config below comes from a LOT of digging, copy/paste and trial &
error from the mailing lists and the Postfix book. It seems to works
for most usage, so far as I've tested. There's obviously more testing
to do.

postfinger ==>
-----------------------------------------------------------------------
postfinger - postfix configuration on Thu Feb 23 09:11:38 PST 2012
version: 1.30

--System Parameters--
mail_version = 2.8.7
hostname = mail.rogermail.lan
uname = Linux mail.rogermail.lan 3.1.9-1.4-xen #1 SMP Fri Jan 27
08:55:10 UTC 2012 (efb5ff4) x86_64 x86_64 x86_64 GNU/Linux

--Packaging information--
looks like this postfix comes from RPM package:
postfix-2.8.7-126.1.x86_64

--main.cf non-default parameters--
append_dot_mydomain = no
authorized_submit_users = root roger wwwrun
biff = no
body_checks = pcre:/etc/postfix/body_checks
daemon_directory = /usr/lib/postfix
disable_vrfy_command = yes
header_checks = pcre:/etc/postfix/header_checks
inet_interfaces = 192.168.1.10 192.168.1.11
local_recipient_maps =
mailbox_size_limit = 0
mail_name = mail.rogermail.lan
message_size_limit = 20480000
milter_default_action = accept
mime_header_checks = pcre:/etc/postfix/mime_header_checks
mydestination = localhost.mail.rogermail.lan, localhost
mydomain = mail.rogermail.lan
mynetworks = 127.0.0.0/8
nested_header_checks = pcre:/etc/postfix/nested_header_checks
parent_domain_matches_subdomains = debug_peer_list smtpd_access_maps
postscreen_access_list = permit_mynetworks,
cidr:/etc/postfix/postscreen_access.cidr
postscreen_blacklist_action = drop
postscreen_client_connection_count_limit = 10
postscreen_dnsbl_action = drop
postscreen_dnsbl_sites = zen.spamhaus.org*2 b.barracudacentral.org*1
postscreen_dnsbl_threshold = 2
postscreen_greet_action = enforce
smtp_bind_address = 192.168.1.10
smtpd_banner = mail.rogermail.lan ESMTP
smtpd_helo_required = yes
smtpd_recipient_restrictions =
smtpd_timeout = ${stress?10}${stress:60}s
smtpd_tls_auth_only = yes
smtpd_tls_CApath = /etc/ssl/certs
smtpd_tls_cert_file = /usr/local/etc/ssl/certs/mail.rogermail.lan.crt
smtpd_tls_ciphers = HIGH
smtpd_tls_exclude_ciphers = MEDIUM, LOW, EXPORT, NULL, aNULL
smtpd_tls_key_file = /usr/local/etc/ssl/private/mail.rogermail.lan.key
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_ciphers = HIGH
smtpd_tls_mandatory_exclude_ciphers = MEDIUM, LOW, EXPORT, NULL, aNULL
smtpd_tls_mandatory_protocols = TLSv1, SSLv3, !SSLv2
smtpd_tls_protocols = TLSv1, SSLv3, !SSLv2
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_loglevel = 1
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
strict_rfc821_envelopes = yes
unknown_address_reject_code = 554
unknown_client_reject_code = 554
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_mailbox_domains = proxy:mysql:/etc/postfix/sql/vdomains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/sql/vmailboxes.cf
virtual_transport = lmtp:unix:private/dovecot-lmtp

--master.cf--

192.168.1.10:smtp inet n - n - 1
postscreen
smtpd pass - - n - 20 smtpd
-o smtpd_proxy_filter=inet:127.0.0.1:10025
-o smtpd_proxy_timeout=100s

-o smtpd_proxy_ehlo=mail.rogermail.lan

-o smtpd_client_connection_count_limit=10
-o smtpd_proxy_options=speed_adjust
-o smtp_send_xforward_command=yes
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
-o disable_mime_output_conversion=yes
-o
smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_non_fqdn_sender,reject_unknown_sender_domain,permit_mynetworks,reject_unknown_recipient_domain,reject_unlisted_recipient,reject_unauth_destination

127.0.0.1:10026 inet n - n - - smtpd

-o smtpd_authorized_xforward_hosts=127.0.0.0/8
-o smtpd_client_restrictions=
-o smtpd_helo_required=yes
-o smtpd_helo_restrictions=
-o
smtpd_sender_restrictions=check_recipient_access,hash:/etc/postfix/spamtrap
-o
smtpd_recipient_restrictions=permit_mynetworks,reject_unauth_destination
-o smtpd_data_restrictions=
-o smtpd_end_of_data_restrictions=
-o smtpd_etrn_restrictions=
-o mynetworks=127.0.0.0/8
-o receive_override_options=no_unknown_recipient_checks
submission inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/auth
-o smtpd_sasl_security_options=noanonymous
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_sender_login_maps=
-o
smtpd_recipient_restrictions=permit_mynetworks,reject_unauth_destination
-o smtpd_etern_restrictions=reject
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_milters=inet:127.0.0.1:10030
-o non_smtpd_milters=inet:localhost:10030
dnsblog unix - - n - 0
dnsblog
tlsproxy unix - - n - 0
tlsproxy
pickup fifo n - n 60 1
pickup
cleanup unix n - n - 0
cleanup
qmgr fifo n - n 300 1 qmgr
tlsmgr unix - - n 1000? 1
tlsmgr
rewrite unix - - n - -
trivial-rewrite
bounce unix - - n - 0
bounce
defer unix - - n - 0
bounce
trace unix - - n - 0
bounce
verify unix - - n - 1
verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - -
proxymap
proxywrite unix - - n - 1
proxymap
smtp unix - - n - - smtp
relay unix - - n - - smtp
-o smtp_fallback_relay=
showq unix n - n - - showq
error unix - - n - - error
discard unix - - n - -
discard
local unix - n n - - local
virtual unix - n n - -
virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scache unix - - n - 1
scache
policyd-spf unix - n n - 0 spawn
user=nobody argv=/usr/bin/python /usr/local/bin/policyd-spf
retry unix - - n - - error

-- end of postfinger output --
-----------------------------------------------------------------------

On 02/23/2012 09:28 AM, /dev/rob0 wrote:
>> I'd have to create a policy service, right? Some sort of
>> additional filter, or some such?
>
> A policy service is an external daemon, yes. Examples of such which
> are in common use include policyd and postfwd.

Ok. If that's the eventual solution, I'll have to learn how to do that.

> http://www.postfix.org/SMTPD_POLICY_README.html and the sites for
> both aforementioned third-party projects.

I'd read that already. Time to read it some more. Thanks.

> My view remains unchanged; I would not do what you are describing.
> Naturally you are free to disagree and do it anyway, but by posting
> here, you opened it up for opinions, and you got mine.

Thanks for the input. I will disagree, and will attempt to achive the
same outcome that my prior commercial implementation has enabled me to
do, by design.

On 02/23/2012 09:45 AM, Wietse Venema wrote:
> At DATA time, recipient-based features are undefined for multi-recipient
> mail. Such things are beyond what is possible with the built-in
> access language.
>
> With the current access language, a policy daemon would have to
> maintain state (the afore-mentioned flag) about preceding queries
> for the same mail trasaction (the same "instance" attribute) and
> then reject mail at DATA time.

Again way over my head -- though I'm not even sure that's targeted at
me. I think that if I wrote a policy daemon that's what I'd have to
*do*.

IIUC, the

-o
smtpd_sender_restrictions=check_recipient_access,hash:/etc/postfix/spamtrap

as advised should be doing the trick. Apprently it's not working for
me. I hope to learn how to get there. Ideally just using what Postfix
provides and without writing additional code.

[Noel Jones]

On 2/23/2012 12:11 PM, rg8...@airpost.net wrote:
>
> sendmail -i -t
> From: ro...@deskmail.rogermail.lan
> To: ro...@mail.rogermail.lan,sp...@mail.rogermail.lan
> Subject: test
> testing

The various smtpd_*_restrictions only work with mail submitted via SMTP.



-- Noel Jones

[rg8...@airpost.net]

I'm missing what the point of your comment is.

I'm sending my test mail using postfix/sendmail from my desktop to the
mail server. Doesn't that qualify as "submitted via SMTP" ?

Cheers,

Roger

[rg8...@airpost.net]

Hello,

On Thu, Feb 23, 2012, at 11:06 AM, rg8...@airpost.net wrote:
> > The various smtpd_*_restrictions only work with mail submitted via SMTP.

Even though I still don't understand why the sendmail session I
described isn't "mail submitted via SMTP", I tried a different method of
testing. Using telnet.

Following this,

Using Telnet to send mail by SMTP
http://arnab.org/notes/using-telnet-to-send-mail-by-smtp
"... So now we can send email using SMTP, (and recieve
using POP) all without the use of a mail client or a web
browser."

With Postfix still configured at the reinjection listener with,

127.0.0.1:10026 inet n - n - -
smtpd

...
-o
smtpd_sender_restrictions=check_recipient_access,hash:/etc/postfix/spamtrap
...

and

cat /etc/postfix/spamtrap
sp...@mail.rogermail.lan
postmap /etc/postfix/spamtrap

I initiate the telnet session from my desktop to the server,

telnet 192.168.1.10 25
Trying 192.168.1.10...
Connected to 192.168.1.10.
Escape character is '^]'.
220 mail.rogermail.lan ESMTP
EHLO desk.rogermail.lan
250-mail.rogermail.lan
250-PIPELINING
250-SIZE 20480000
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:<ro...@desk.rogermail.lan>
250 2.1.0 Ok
RCPT TO:<ro...@mail.rogermail.lan>
250 2.1.5 Ok
RCPT TO:<sp...@mail.rogermail.lan>

550 5.1.1 <sp...@mail.rogermail.lan>: Recipient address
rejected: User unknown in virtual mailbox table

IIUC, that's a legitimate SMTP session, and that's "mail submitted via
SMTP", no?

Still, no hash-table smaptrap check & detection.

Logs for this session are,

tail -f /var/log/mail ==>
Feb 23 11:16:03 mx postfix/postscreen[19761]: CONNECT
from [192.168.1.10]:53348
Feb 23 11:16:03 mx postfix/postscreen[19761]: PASS OLD
[192.168.1.10]:53348
Feb 23 11:16:03 mx postfix/smtpd[19684]: connect from
mail.rogermail.lan[192.168.1.10]
Feb 23 11:16:14 mx postfix/smtpd[19684]: NOQUEUE:
client=mail.rogermail.lan[192.168.1.10]
Feb 23 11:16:22 mx postfix/smtpd[19684]: NOQUEUE:
reject: RCPT from mail.rogermail.lan[192.168.1.10]: 550

5.1.1 <sp...@mail.rogermail.lan>: Recipient address
rejected: User unknown in virtual mailbox table;

from=<ro...@desk.rogermail.lan>
to=<sp...@mail.rogermail.lan> proto=ESMTP
helo=<desk.rogermail.lan>

Cheers,

Roger

[Reindl Harald]

Am 23.02.2012 20:06, schrieb rg8...@airpost.net:
>
>
> On Thu, Feb 23, 2012, at 12:49 PM, Noel Jones wrote:
>> On 2/23/2012 12:11 PM, rg8...@airpost.net wrote:
>>>
>>> sendmail -i -t
>>> From: ro...@deskmail.rogermail.lan
>>> To: ro...@mail.rogermail.lan,sp...@mail.rogermail.lan
>>> Subject: test
>>> testing
>>
>>

>> The various smtpd_*_restrictions only work with mail submitted via SMTP.
>

> I'm missing what the point of your comment is.
>
> I'm sending my test mail using postfix/sendmail from my desktop to the
> mail server. Doesn't that qualify as "submitted via SMTP"?

SMTP = Simple mail Transfer Protocol
http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol

the sendmail-bianry is using pickup and does NOT go over NETWORK

sorry but this are basics you should normally learn
before trying setup complex systems

[rg8...@airpost.net]

On Thu, Feb 23, 2012, at 08:37 PM, Reindl Harald wrote:
> > I'm sending my test mail using postfix/sendmail from my desktop to the
> > mail server. Doesn't that qualify as "submitted via SMTP"?
>
> SMTP = Simple mail Transfer Protocol
> http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol
>
> the sendmail-bianry is using pickup and does NOT go over NETWORK

If it "does NOT go over NETWORK", rather than being flippantly
dimsissive about what I "should learn", might you recognize that that is
what I'm trying to do by asking my questions, and explain how mail sent
from one machine (my desktop with postfix) is getting to the other -- if
not over the network? clearly, postscreen on port 25 is 'getting' the
message ...

And, perhaps you might be kind enough to further comment at my
subsequent post which addresses using telnet over the network -- perhaps
I've failed to learn that also.

[Wietse Venema]

> 127.0.0.1:10026 inet n - n - -
> smtpd
> ...
> -o
> smtpd_sender_restrictions=check_recipient_access,hash:/etc/postfix/spamtrap

This has a spamtrap on 127.0.0.1.

>
> and
>
> cat /etc/postfix/spamtrap
> sp...@mail.rogermail.lan
> postmap /etc/postfix/spamtrap
>

> I initiate the telnet session from my desktop to the server,
>
> telnet 192.168.1.10 25

That is not 127.0.0.1.

Wietse

[rg8...@airpost.net]

Hello,

On Thu, Feb 23, 2012, at 02:51 PM, Wietse Venema wrote:
> > 127.0.0.1:10026 inet n - n - -
> > smtpd
> > ...
> > -o
> > smtpd_sender_restrictions=check_recipient_access,hash:/etc/postfix/spamtrap
>
> This has a spamtrap on 127.0.0.1.

Yes, that's correct, as that's the reinjection listener that receives
the localhost-only handoff from the prior before-queue filter. It does
not listen @ the external address.

> > and
> >
> > cat /etc/postfix/spamtrap
> > sp...@mail.rogermail.lan
> > postmap /etc/postfix/spamtrap
> >
> > I initiate the telnet session from my desktop to the server,
> >
> > telnet 192.168.1.10 25
>
> That is not 127.0.0.1.

That's also correct, as that's the 'real, external address' postscreen
listens at -- and where email is sent to.

Are you suggesting with your comments that this will not work for mail
received -- as is normally the case -- through the 'front door',
192.168.1.10:25, listened to by postscreen?

Roger

[/dev/rob0]

On Thu, Feb 23, 2012 at 11:31:53AM -0800, rg8...@airpost.net wrote:
> On Thu, Feb 23, 2012, at 11:06 AM, rg8...@airpost.net wrote:

Noel:

> > > The various smtpd_*_restrictions only work with mail
> > > submitted via SMTP.
>

> Even though I still don't understand why the sendmail session I
> described isn't "mail submitted via SMTP",

sendmail(1) writes mail to a file which is enqueued by the pickup(8)
daemon. smtpd(8) is not used. smtpd-specific settings such as
smtpd_sender_restrictions are irrelevant in this mode of submission.

> I tried a different method of testing. Using telnet.
>
> Following this,
>
> Using Telnet to send mail by SMTP
> http://arnab.org/notes/using-telnet-to-send-mail-by-smtp

The SMTP protocol is documented in RFC 5321 and predecessors.

> With Postfix still configured at the reinjection listener with,

Why do you have this on reinjection? It will be rejected as an
unknown user before reinjection can occur.

> 127.0.0.1:10026 inet n - n - -
> smtpd
> ...
> -o
> smtpd_sender_restrictions=check_recipient_access,hash:/etc/postfix/spamtrap

> ...

>
> and
>
> cat /etc/postfix/spamtrap
> sp...@mail.rogermail.lan
> postmap /etc/postfix/spamtrap

This should have caused an error, because a hash: map format is "key
whitespace value":

sp...@mail.rogermail.lan DISCARD

Here's another thought, which I think someone else mentioned
upthread: you could PREPEND a special header, then handle that in
your content filter.

sp...@mail.rogermail.lan PREPEND X-spamtrap-garbage: YES

> I initiate the telnet session from my desktop to the server,
>
> telnet 192.168.1.10 25

> Trying 192.168.1.10...
> Connected to 192.168.1.10.
> Escape character is '^]'.
> 220 mail.rogermail.lan ESMTP
> EHLO desk.rogermail.lan
> 250-mail.rogermail.lan
> 250-PIPELINING
> 250-SIZE 20480000
> 250-ETRN
> 250-STARTTLS
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN
> MAIL FROM:<ro...@desk.rogermail.lan>
> 250 2.1.0 Ok
> RCPT TO:<ro...@mail.rogermail.lan>
> 250 2.1.5 Ok
> RCPT TO:<sp...@mail.rogermail.lan>
> 550 5.1.1 <sp...@mail.rogermail.lan>: Recipient address
> rejected: User unknown in virtual mailbox table
>
> IIUC, that's a legitimate SMTP session, and that's "mail submitted
> via SMTP", no?

But it does not get to the content filter and reinjection smtpd.

> Still, no hash-table smaptrap check & detection.
>
> Logs for this session are,
>
> tail -f /var/log/mail ==>
> Feb 23 11:16:03 mx postfix/postscreen[19761]: CONNECT
> from [192.168.1.10]:53348
> Feb 23 11:16:03 mx postfix/postscreen[19761]: PASS OLD
> [192.168.1.10]:53348
> Feb 23 11:16:03 mx postfix/smtpd[19684]: connect from
> mail.rogermail.lan[192.168.1.10]
> Feb 23 11:16:14 mx postfix/smtpd[19684]: NOQUEUE:
> client=mail.rogermail.lan[192.168.1.10]
> Feb 23 11:16:22 mx postfix/smtpd[19684]: NOQUEUE:
> reject: RCPT from mail.rogermail.lan[192.168.1.10]: 550
> 5.1.1 <sp...@mail.rogermail.lan>: Recipient address
> rejected: User unknown in virtual mailbox table;
> from=<ro...@desk.rogermail.lan>
> to=<sp...@mail.rogermail.lan> proto=ESMTP
> helo=<desk.rogermail.lan>

[Wietse Venema]

rg8...@airpost.net:

> Hello,
>
> On Thu, Feb 23, 2012, at 02:51 PM, Wietse Venema wrote:

> > > 127.0.0.1:10026 inet n - n - -
> > > smtpd
> > > ...
> > > -o
> > > smtpd_sender_restrictions=check_recipient_access,hash:/etc/postfix/spamtrap
> >

> > This has a spamtrap on 127.0.0.1.
>
> Yes, that's correct, as that's the reinjection listener that receives
> the localhost-only handoff from the prior before-queue filter. It does
> not listen @ the external address.

You have the spamtrap address configured on 127.0.0.1, but you
telnet to 192.168.1.10, and then you are surprised that the SMTP
server on 192.168.1.10 does not know about the spamtrap address.

If you want to reject the spamtrap address while connected to
192.168.1.10, then you need to implement the spamtrap check at
192.168.1.10.

Wietse

[rg8...@airpost.net]

On Thu, Feb 23, 2012, at 02:28 PM, /dev/rob0 wrote:
> sendmail(1) writes mail to a file which is enqueued by the pickup(8)
> daemon. smtpd(8) is not used. smtpd-specific settings such as
> smtpd_sender_restrictions are irrelevant in this mode of submission.

Yes, it does that locally. I am sending from one machine to another.

@ my desktop,

sendmail -i -t <<EOF
From: ro...@presence-group.com

To: ro...@mail.rogermail.lan,sp...@mail.rogermail.lan
Subject: test
testing

EOF

This clearly invokes postfix on the desktop machine, and sends it to the
server,

@ my desktop's log,

tail -f /var/log/mail

Feb 23 11:51:52 desk postfix/pickup[19611]: 986C040083: uid=1000
from=<roger>
Feb 23 11:51:52 desk postfix/cleanup[20619]: 986C040083:
message-id=<201202231951...@desk.rogermail.lan>
Feb 23 11:51:52 desk postfix/qmgr[5927]: 986C040083:
from=<ro...@desk.rogermail.lan>, size=371, nrcpt=2 (queue
active)
Feb 23 11:51:52 desk postfix/smtp[20627]: connect to
mail.rogermail.lan[192.168.1.10]:25: Connection refused
Feb 23 11:51:52 desk postfix/smtp[20627]: 986C040083:
to=<sp...@mail.rogermail.lan>,
relay=mail.rogermail.lan[192.168.1.10]:25, delay=0.3,
delays=0.21/0/0.03/0.06, dsn=5.1.1, status=bounced (host
mail.rogermail.lan[192.168.1.10] said: 550 5.1.1

<sp...@mail.rogermail.lan>: Recipient address rejected: User

unknown in virtual mailbox table (in reply to RCPT TO command))
Feb 23 11:51:54 desk postfix/smtp[20627]: 986C040083:
to=<ro...@mail.rogermail.lan>,
relay=mail.rogermail.lan[192.168.1.10]:25, delay=1.5,
delays=0.21/0/0.03/1.2, dsn=2.0.0, status=sent (250 2.0.0 Ok:
queued as 2CF8320337)
Feb 23 11:51:54 desk postfix/cleanup[20619]: 01AC540084:
message-id=<201202231951...@desk.rogermail.lan>
Feb 23 11:51:54 desk postfix/qmgr[5927]: 01AC540084: from=<>,
size=2601, nrcpt=1 (queue active)
Feb 23 11:51:54 desk postfix/bounce[20628]: 986C040083: sender
non-delivery notification: 01AC540084
Feb 23 11:51:54 desk postfix/qmgr[5927]: 986C040083: removed
Feb 23 11:51:54 desk postfix/local[20633]: 01AC540084:
to=<ro...@desk.rogermail.lan>, relay=local, delay=0.12,
delays=0.08/0/0/0.03, dsn=2.0.0, status=sent (delivered to
mailbox)
Feb 23 11:51:54 desk postfix/qmgr[5927]: 01AC540084: removed


which then receives it at port:25

@ my server's log,

tail -f /var/log/mail

Feb 23 11:51:49 mail postfix/postscreen[20700]: CONNECT from
[192.168.1.13]:44173
Feb 23 11:51:49 mail postfix/postscreen[20700]: PASS OLD
[192.168.1.13]:44173
Feb 23 11:51:49 mail postfix/smtpd[20618]: connect from
desk.rogermail.lan[192.168.1.13]
Feb 23 11:51:49 mail postfix/smtpd[20618]: NOQUEUE:
client=desk.rogermail.lan[192.168.1.13]
Feb 23 11:51:49 mail postfix/smtpd[20618]: NOQUEUE: reject: RCPT
from desk.rogermail.lan[192.168.1.13]: 550 5.1.1

<sp...@mail.rogermail.lan>: Recipient address rejected: User
unknown in virtual mailbox table;
from=<ro...@desk.rogermail.lan> to=<sp...@mail.rogermail.lan>
proto=ESMTP helo=<desk.rogermail.lan>

Feb 23 11:51:49 mail postfix/smtpd[20625]: connect from
localhost[127.0.0.1]
Feb 23 11:51:49 mail postfix/smtpd[20625]: 2CF8320337:
client=localhost[127.0.0.1],
orig_client=desk.rogermail.lan[192.168.1.13]
Feb 23 11:51:49 mail spampd[32019]: processing message
<201202231951...@desk.rogermail.lan> for
<ro...@mail.rogermail.lan> ORCPT=rfc822;ro...@mail.rogermail.lan
Feb 23 11:51:50 mail spampd[32019]: clean message
<201202231951...@desk.rogermail.lan> (0.00/4.00) from
<ro...@desk.rogermail.lan> for <ro...@mail.rogermail.lan>
ORCPT=rfc822;ro...@mail.rogermail.lan in 1.02s, 603 bytes.
Feb 23 11:51:50 mail postfix/cleanup[20628]: 2CF8320337:
message-id=<201202231951...@desk.rogermail.lan>
Feb 23 11:51:50 mail postfix/qmgr[16440]: 2CF8320337:
from=<ro...@desk.rogermail.lan>, size=991, nrcpt=1 (queue
active)
Feb 23 11:51:50 mail postfix/smtpd[20618]: proxy-accept:
END-OF-MESSAGE: 250 2.0.0 Ok: queued as 2CF8320337;
from=<ro...@desk.rogermail.lan> to=<ro...@mail.rogermail.lan>
proto=ESMTP helo=<desk.rogermail.lan>
Feb 23 11:51:50 mail postfix/smtpd[20618]: disconnect from
desk.rogermail.lan[192.168.1.13]
Feb 23 11:51:50 mail postfix/smtpd[20625]: disconnect from
localhost[127.0.0.1]
Feb 23 11:51:50 mail postfix/lmtp[20654]: 2CF8320337:
to=<ro...@mail.rogermail.lan>,
relay=mail.rogermail.lan[private/dovecot-lmtp], delay=1.5,
delays=1.2/0/0.02/0.28, dsn=2.0.0, status=sent (250 2.0.0
<ro...@mail.rogermail.lan> x/CQFtaYRk/gUAAAwJ+ohQ Saved)
Feb 23 11:51:50 mail postfix/qmgr[16440]: 2CF8320337: removed

Both @desktop and @server, that certainly looks like an SMTP transaction
to me.

> > With Postfix still configured at the reinjection listener with,
>
> Why do you have this on reinjection? It will be rejected as an
> unknown user before reinjection can occur.

Because I was advised to.

I reference this specific example,

Configuring the Postfix SMTP pass-through proxy feature
http://www.postfix.org/ SMTPD_PROXY_README.html#config

Based on that, my current understanding of my config is that email is
received by postscreen, passed to the before-queue filter, then
reinjected back to a local smtpd,

(1) "POSTSCREEN"
192.168.1.10:25 |--> postscreen
192.168.1.11:25 | 'private' smtpd
-o
smtpd_proxy_filter=inet:127.0.0.1:10025
---->----

(2) "SPAMPD - BeforeQueueFilter"
--> 127.0.0.1:10025 | spampd
--host=127.0.0.1:10025
--relayhost=127.0.0.1:10026 ---->----

(3) "Reinjection Listener"
--> 127.0.0.1:10026 | smtpd
-o
smtpd_sender_restrictions=check_recipient_access,hash:/etc/postfix/spamtrap

Earlier in this thread I was *specifically* advised,

> 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

Which, as you can see, I've done.

> > cat /etc/postfix/spamtrap
> > sp...@mail.rogermail.lan
> > postmap /etc/postfix/spamtrap
>
> This should have caused an error, because a hash: map format is "key
> whitespace value":
>

You're correct. But that was simply a copy & paste typo on my part.

This

> sp...@mail.rogermail.lan DISCARD

is exactly what I have.

> Here's another thought, which I think someone else mentioned
> upthread: you could PREPEND a special header, then handle that in
> your content filter.
>
> sp...@mail.rogermail.lan PREPEND X-spamtrap-garbage: YES

Will such a header be added for ALL recipients? or just for the matched
address?

Also, I assume that's still done with the check_recipient_access
restriction? If yes, then at which stage?

> > IIUC, that's a legitimate SMTP session, and that's "mail submitted
> > via SMTP", no?
>
> But it does not get to the content filter and reinjection smtpd.

That may well be the case. If so, then I'm receiving contradictory
advice. But that's a different issue than had been raised, dismissed
the test because it's not "via SMTP"

I've pored over the site, the mailing lists, and the books, and have
shared that which I've done to date, based on the understanding I've
gleaned ...
I've been asked to state my goals. Check.
I've been instructed to add the check_recipient_access constraint to my
localhost, reinjection listener. Check.
I've been told to test the mail sending via SMTP. Check.
I've been requested to send copied & pasted logs. Check.
I've been directed to post relevant configuration information, using
postfinger. Check.

I've communicated that I'm not at all wedded to a particular method of
check/discard, and that only the functional outcome is of interest to
me.

Naively, I'd assume 'this' is best done @postscreen time. Iiuc, though,
that's not currently possible, and/or would require 'additional
development'.

I'm still hoping to get some specific advice, in layman's terms, how to
specifically get done what i've set out to do.

Two pending questions for me, atm,

(1) is the PREPEND header option an all-recipient solution, or just for
the matched recipient address?
(2) at what stage should this restriction check be added? i've got both
a 'yes' and a 'no' for @ the reinjection listener.

Roger

[Charles Marcus]

On 2012-02-23 3:58 PM, rg8...@airpost.net <rg8...@airpost.net> wrote:
> This clearly invokes postfix on the desktop machine, and sends it to the
> server,
>
> @ my desktop's log,
>
> tail -f /var/log/mail
>
> Feb 23 11:51:52 desk postfix/pickup[19611]: 986C040083: uid=1000
> from=<roger>

You are not listening.

Yes, it invokes postfix - no one said otherwise - but it invokes postfix
via the PICKUP service, not via the SMTPD daemon, as your log clearly
shows - and messages submitted like this are not subject to the various
smtpd_mumble restrictions, as your evidence also clearly shows.

I believe some serious book-learning is in order...

--

Best regards,

Charles

[rg8...@airpost.net]

On Thu, Feb 23, 2012, at 03:35 PM, Wietse Venema wrote:
> You have the spamtrap address configured on 127.0.0.1, but you
> telnet to 192.168.1.10, and then you are surprised that the SMTP
> server on 192.168.1.10 does not know about the spamtrap address.

Frakly, I'm not suprised by a thing. I'm simply looking at what's in
front of me, asking questions about it knowing full well that
something's not quite right -- as I've mentioned several times -- and
trying to dig through dribbles of sometimes conflicting responses.

I'm a new user taking the time to learn this product and explore it's
capabilities. I doubt that you're suprised that there's a lot to learn
and explore.

This is a user list where users come to ask questions, right? Is it a
prerequisite that we know answers, or recognize which among the
conflicting ones provides are correct, before asking our questions? If
it is, please let me know.

> If you want to reject the spamtrap address while connected to 192.168.1.10

As I've said repeatedly -- I'm not wedded to a method. Just the
outcome. I'm looking to others, here, to advise what the best approach
is to achive my clearly stated goals.

> then you need to implement the spamtrap check at 192.168.1.10.

Happy to. Where and how? *Specifically*, at which stage?

To the best of my ability, I've attempted to follow the examples
provided on the site and in posts. Attempting to understand what's
depicted and properly extend it to my use case, that seems to include
only postscreen listening on the 'real' external address(es), and "the
rest" listening on localhost:various_ports for handoffs.

I was *specifically* advised on this list, in this thread, to add the
check to the reinjection listener on localhost:10026.

If that's not the correct advice, can you kindly clarify -- for the
*specific* configuration I've provided per request at:

http://marc.info/?l=postfix-users&m=133002076514425&w=2

What specific changes need be made? Your admonition to "then you need
to implement the spamtrap check at 192.168.1.10" still leaves me
unclear.

Roger

[Wietse Venema]

rg8...@airpost.net:

> > If you want to reject the spamtrap address while connected to 192.168.1.10
>
> As I've said repeatedly -- I'm not wedded to a method. Just the
> outcome. I'm looking to others, here, to advise what the best approach
> is to achive my clearly stated goals.
>
> > then you need to implement the spamtrap check at 192.168.1.10.
>
> Happy to. Where and how? *Specifically*, at which stage?

1) To reject mail to the spamtrap address

2) In an SMTP session

3) With the SMTP server at 192.168.1.10

4) Configure the spamtrap reject rule with the Postfix SMTP
daemon that listens on 192.168.1.10.

Wietse

[Noel Jones]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Let's lighten up here. They guy asked a fairly simple and
legitimate question and has gotten a bunch of crap from folks who
either didn't read his question or didn't understand what he was
trying to do.

I would like to think we are collectively better than that.



-- Noel Jones
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPRrGRAAoJEJGRUHb5Oh6ge5QH/iIPOAxz61+eWO4Vc2ES2Ddb
2ZOtHlVsg3y4V1WzvhsHZAjg5+NxYK3noD5a4spD+ZkxQdO1l3MRhP4fsOcdH+iv
hbcxXVsYFT2kvMg4AjQSLLXb51s2mVgy653J0Rv/ptUxpY9W71EO9vrJVEKojTZu
Pu6nok0B1Wvmc77HphEvHtW8oYnwvLRoSFOqPB7JaGGHbpQWrBrYxudUlirsQGw1
+dG640oNImt7D/pTfpfEmO3C2YPjPPbsoQmW4vrXHAPY9CGmpUVt4CU3Bl4FdWLs
XFV4vsuv0JSAFCnusH9J83vDqmDZHVBsqhXNcWqt5kyPp9jilsERDHVi+JH0tEQ=
=ad8j
-----END PGP SIGNATURE-----

[/dev/rob0]

On Thu, Feb 23, 2012 at 12:58:46PM -0800, rg8...@airpost.net wrote:
> On Thu, Feb 23, 2012, at 02:28 PM, /dev/rob0 wrote:
> > sendmail(1) writes mail to a file which is enqueued by the
> > pickup(8) daemon. smtpd(8) is not used. smtpd-specific settings
> > such as smtpd_sender_restrictions are irrelevant in this mode of
> > submission.
>
> Yes, it does that locally. I am sending from one machine to
> another.
>
> @ my desktop,
>
> sendmail -i -t <<EOF
> From: ro...@presence-group.com
> To: ro...@mail.rogermail.lan,sp...@mail.rogermail.lan
> Subject: test
> testing
> EOF
>

> This clearly invokes postfix on the desktop machine, and sends it
> to the server,

Gotcha. This was not clear, or I was not paying attention. Anyway, I
did explain what happened to it.

> @ my desktop's log,
>
> tail -f /var/log/mail
>
> Feb 23 11:51:52 desk postfix/pickup[19611]: 986C040083: uid=1000
> from=<roger>

> Feb 23 11:51:52 desk postfix/cleanup[20619]: 986C040083:
> message-id=<201202231951...@desk.rogermail.lan>
> Feb 23 11:51:52 desk postfix/qmgr[5927]: 986C040083:
> from=<ro...@desk.rogermail.lan>, size=371, nrcpt=2 (queue
> active)
> Feb 23 11:51:52 desk postfix/smtp[20627]: connect to
> mail.rogermail.lan[192.168.1.10]:25: Connection refused
> Feb 23 11:51:52 desk postfix/smtp[20627]: 986C040083:
> to=<sp...@mail.rogermail.lan>,
> relay=mail.rogermail.lan[192.168.1.10]:25, delay=0.3,
> delays=0.21/0/0.03/0.06, dsn=5.1.1, status=bounced (host
> mail.rogermail.lan[192.168.1.10] said: 550 5.1.1
> <sp...@mail.rogermail.lan>: Recipient address rejected: User
> unknown in virtual mailbox table (in reply to RCPT TO command))

The invalid recipient is eliminated before the content filter.
Therefore it cannot get to the reinjection smtpd.

snip

> > > With Postfix still configured at the reinjection listener
> >

> > Why do you have this on reinjection? It will be rejected as
> > an unknown user before reinjection can occur.
>
> Because I was advised to.
>
> I reference this specific example,
>
> Configuring the Postfix SMTP pass-through proxy feature
> http://www.postfix.org/ SMTPD_PROXY_README.html#config
>
> Based on that, my current understanding of my config is that
> email is received by postscreen,

No, postscreen receives no mail. It receives a connection, identifies
it as legitimate, and passes that connection on to smtpd. I've only
ever done after-queue content filtering with postscreen, so I am not
sure how they interact. Looks like it goes to smtpd, filter, smtpd,
very much as after-queue content filtering works.

> passed to the before-queue filter, then
> reinjected back to a local smtpd,

See "Principles of operation" in SMTPD_PROXY_README.html which says:

* The before-filter Postfix SMTP server accepts connections from
the Internet and does the usual relay access control, SASL
authentication, TLS negotiation, RBL lookups, rejecting
non-existent sender or recipient addresses, etc.

It's the very last item before "etc" that you are missing. You are
not getting to the filter.

snip

> > Here's another thought, which I think someone else mentioned
> > upthread: you could PREPEND a special header, then handle that in
> > your content filter.
> >
> > sp...@mail.rogermail.lan PREPEND X-spamtrap-garbage: YES
>
> Will such a header be added for ALL recipients? or just for the
> matched address?

A header is part of the message, the DATA part of SMTP. There is one
DATA for all RCPT TO addresses. So, yes.

> Also, I assume that's still done with the check_recipient_access
> restriction? If yes, then at which stage?

I presume that you could continue to reject the spamtrap as invalid,
as long as you are doing the check_recipient_access PREPEND action
before reject_unknown_recipient (or, anywhere, if you're only using
the implicit smtpd_reject_unknown_recipient rejection.)

snip

> Naively, I'd assume 'this' is best done @postscreen time. Iiuc,
> though, that's not currently possible, and/or would require
> 'additional development'.

Not going to happen; postscreen does what it does, and that is
probably all it will ever do. Forget postscreen, irrelevant to this.

> I'm still hoping to get some specific advice, in layman's terms,
> how to specifically get done what i've set out to do.
>
> Two pending questions for me, atm,
>
> (1) is the PREPEND header option an all-recipient solution, or just
> for the matched recipient address?

answered above

> (2) at what stage should this restriction check be added? i've got
> both a 'yes' and a 'no' for @ the reinjection listener.

Since you want to see the header in the filter, it must be added
before the filter.

[Noel Jones]

On 2/23/2012 3:36 PM, Wietse Venema wrote:
> 4) Configure the spamtrap reject rule with the Postfix SMTP
> daemon that listens on 192.168.1.10.

but he's trying to DISCARD mail to the spamtrap in a post-filter
listener. That's the listener on 127.0.0.1:10026

The problem to solve is the spamtrap must not be rejected as an
unknown recipient at the pre-filter listener.

-- Noel Jones


>
> Wietse

[Noel Jones]

On 2/23/2012 3:39 PM, /dev/rob0 wrote:
> On Thu, Feb 23, 2012 at 12:58:46PM -0800, rg8...@airpost.net wrote:

>
> snip
>>> Here's another thought, which I think someone else mentioned
>>> upthread: you could PREPEND a special header, then handle that in
>>> your content filter.
>>>
>>> sp...@mail.rogermail.lan PREPEND X-spamtrap-garbage: YES
>>
>> Will such a header be added for ALL recipients? or just for the
>> matched address?

This works too, but brings its own complication of requiring a
separate cleanup service for the post-filter smtpd so the
header_check DISCARD action can be performed post-filter.

The check_recipient_access with DISCARD is probably easiest, but the
spamtrap address must be accepted by the pre-filter postfix.



-- Noel Jones

[Stan Hoeppner]

On 2/23/2012 8:53 AM, /dev/rob0 wrote:
> On Thu, Feb 23, 2012 at 08:06:34AM -0600, Stan Hoeppner wrote:
>> On 2/23/2012 2:34 AM, rg8...@airpost.net wrote:
>>> I'm building a Postfix server with postscreen & a before-queue
>>> filter.
>>>
>>> I'm trying to get spamtraps working so that if a spamtrap address
>>> is in ANY of the recipients, then delivery of the message to ALL
>>> recipients is quietly DISCARDED.
>>
>> This isn't how spamtraps are typically implemented, and may be why
>> you're having trouble. The proper way to implement a spamtrap for
>> rejecting inbound spam is:
>>
>> 1. Check recipients of inbound connection for spamtrap address
>> 2. Append new sender address to an access table
>> 3. Use the table in a check_sender_access rule to reject inbound
>> spam--no need for discard
>
> Why not the client address and check_client_access? I don't see
> how/why a sender listing would be useful. Was this a typo or a
> "thinko" on your part, Stan? :)

Maybe a "thinko" ;) I was trying diligently to avoid mentioning
anything that would block based on the remote host, either IP or domain,
lest spam hitting the trap address from a compromised gorilla/freemail
account might end up blacklisting everything from said domains or hosts
within. That would usually be a bad thing. Using the sender address
seems much safer, reasonably targeted.

> 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 always thought one purpose of a trap is to remain 'invisible'. If one
is rejecting based on the trap address being a recipient, this can tend
to unmask the trap address, eventually making it useless for stopping
spam, which is the goal after all.

> I fully agree with the reject vs. discard idea. You don't need to
> wait for end-of-DATA and waste that bandwidth (offer void where taxed
> or prohibited, or where the spammer properly implemented pipelining.)

> 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.

I was unaware of the fact that you can't REJECT connections containing
multiple recipients. Does this depend on the type of check*access, or
is this global? If global, wouldn't this pretty much make the REJECT
action useless, as spammers could simply always send to $us...@domain.com
and postm...@domain.com?

I agree with your discard philosophy Rob. I use DICARDs very sparingly,
in header_checks only: to ditch some spam arriving via listservs that
tend to be boot happy if you 5xx anything (LKML), and as a plonk filter
for trolls and miscreants on certain lists (Shmuel on SDLU for example).
Basically where a 5xx causes unwanted problems.

--
Stan

[rg8...@airpost.net]

Hello Noel,

On Thu, Feb 23, 2012, at 03:31 PM, Noel Jones wrote:
>
> (sorry, had to work for a while)

No worries. Nice to have someone reasonable to chat with. Bit of a dry
spell on that. It's appreciated.

> On 2/23/2012 2:58 PM, rg8...@airpost.net wrote:
> Ah, a different server. Important infomation (or maybe I missed it...).

Easy to miss. Fwiw, as originally @

http://marc.info/?l=postfix-users&m=133002076514425&w=2

my sendmail 'send' was sent from 192.168.1.13 to postfix listening @
"inet_interfaces = 192.168.1.10 192.168.1.11".

Clearly mistakenly having presumed that that's clear enough, I called it
out specifically only recently in response to the lashings.

> > Feb 23 11:51:52 desk postfix/smtp[20627]: 986C040083:
> > to=<sp...@mail.rogermail.lan>,
> > relay=mail.rogermail.lan[192.168.1.10]:25, delay=0.3,
> > delays=0.21/0/0.03/0.06, dsn=5.1.1, status=bounced (host
> > mail.rogermail.lan[192.168.1.10] said: 550 5.1.1
> > <sp...@mail.rogermail.lan>: Recipient address rejected: User
> > unknown in virtual mailbox table (in reply to RCPT TO command))
>

> This is the error you need to get rid of. The spamtrap user must be
> accepted for the downstream listener to use it to trigger the DISCARD.
>
> If you add the spam@ user to your local storage all will be well.

Aha, I think ...

So IIUC, I need to RE-add the list of spamtraps in the has table as
valid users (removed as valid after known to be compromised ...) so
that, rather than being off-hand rejected as an unkonw/non-existent
user@domain, the multiple-recipient message gets carried through far
enought to get to where that DISCARD check+action is valid?

Is that approaching correct?

If so, then I assume that I leave only postscreen listening at the
'real' external address, and the spamtrap address check shoud remaing
associated with the 127.0.0.1:10026 reinjection listener, as you'd
previously advised?

Or, per this,

> > > then you need to implement the spamtrap check at 192.168.1.10.
> > Happy to. Where and how? *Specifically*, at which stage?
>
> 1) To reject mail to the spamtrap address
> 2) In an SMTP session
> 3) With the SMTP server at 192.168.1.10

> 4) Configure the spamtrap reject rule with the Postfix SMTP daemon that listens on 192.168.1.10.

do I need to move the check BACK to the postscreen's "private smtpd"
daemon listening on 19.168.1.10 ? My understanding was that that was
too early in the process.

Thanks again for the help.

Cheers,

Roger

[rg8...@airpost.net]

On Thu, Feb 23, 2012, at 10:32 PM, Reindl Harald wrote:
> you are not asking ONE question, you are trying to misuse a
> mailing-list as replacment read all available docs and
> using google

misuse? consider yourself ignored -- and prattle on all you wish. not
a peep more will be heard from you.

[rg8...@airpost.net]

Hello rob

On Thu, Feb 23, 2012, at 03:39 PM, /dev/rob0 wrote:
> > Based on that, my current understanding of my config is that
> > email is received by postscreen,
>
> No, postscreen receives no mail. It receives a connection,
> identifies it as legitimate, and passes that connection on to smtpd. I've only
> ever done after-queue content filtering with postscreen, so I am not
> sure how they interact. Looks like it goes to smtpd, filter, smtpd,
> very much as after-queue content filtering works.

Connection vs mail.

That's a distcintion I hadn't understood from reading. Nice short,
clear explanation. Thanks.

> See "Principles of operation" in SMTPD_PROXY_README.html which says:
>
> * The before-filter Postfix SMTP server accepts connections from
> the Internet and does the usual relay access control, SASL
> authentication, TLS negotiation, RBL lookups, rejecting
> non-existent sender or recipient addresses, etc.
>
> It's the very last item before "etc" that you are missing. You are
> not getting to the filter.

Yes. I think Noel's comments and post are also addressing that.

> > Will such a header be added for ALL recipients? or just for the
> > matched address?
>

> A header is part of the message, the DATA part of SMTP. There is one
> DATA for all RCPT TO addresses. So, yes.

snip

Great. That seems like it's a real option, then. I'll explore further.
Thanks.

> > Naively, I'd assume 'this' is best done @postscreen time. Iiuc,
> > though, that's not currently possible, and/or would require
> > 'additional development'.
>
> Not going to happen; postscreen does what it does, and that is
> probably all it will ever do. Forget postscreen, irrelevant to this.

Per your explanation above, Gotcha.

Cheers,

Roger

[Noel Jones]

On 2/23/2012 3:52 PM, Stan Hoeppner wrote:

>
> I was unaware of the fact that you can't REJECT connections containing
> multiple recipients. Does this depend on the type of check*access, or
> is this global? If global, wouldn't this pretty much make the REJECT
> action useless, as spammers could simply always send to $us...@domain.com
> and postm...@domain.com?

REJECT only acting on individual recipients is an artifact of the
SMTP protocol.

Maybe a band-aid would be a REJECT_IF_PERMIT (aka REJECT_DAMMIT)
action based on DEFER_IF_PERMIT. I expect this would take more
effort to properly document than it would to code, as is frequently
the case.


-- Noel Jones

[/dev/rob0]

On Thu, Feb 23, 2012 at 03:46:49PM -0600, Noel Jones wrote:
> On 2/23/2012 3:39 PM, /dev/rob0 wrote:
> > On Thu, Feb 23, 2012 at 12:58:46PM -0800, rg8...@airpost.net
> > wrote:
>
> > snip
> >>> Here's another thought, which I think someone else mentioned
> >>> upthread: you could PREPEND a special header, then handle that
> >>> in your content filter.
> >>>
> >>> sp...@mail.rogermail.lan PREPEND X-spamtrap-garbage: YES
> >>

> >> Will such a header be added for ALL recipients? or just for the
> >> matched address?
>

> This works too, but brings its own complication of requiring a
> separate cleanup service for the post-filter smtpd so the
> header_check DISCARD action can be performed post-filter.

I was thinking the filter itself could do the rejection, but yes,
understood. Either way means some extra configuration is needed,
either Postfix or filter.

There is an advantage (or disadvantage, depending) of doing the
PREPEND and rejecting in the content filter: this way, single-
recipient mails to the spamtrap are rejected.

Personally, I would want to do more with a spamtrap than this as
alluded upthread. Your suggestion of a REDIRECT action would be
better, because then content analysis can be done.

> The check_recipient_access with DISCARD is probably easiest, but
> the spamtrap address must be accepted by the pre-filter postfix.

Got it. And I have reviewed and learned SMTPD_PROXY_README a bit
better in the process. Thanks.

[Stan Hoeppner]

On 2/23/2012 10:28 AM, rg8...@airpost.net wrote:

> I have a list of compromised addresses. For the sake of this
> discussion, let it include, e.g., "sp...@myserver.com".
>
> Prior to its compromise, it was verifiable as an existing & valid
> "user@domain" in the virtual user/domain (sql) lookup tables.

If this was at one time an actual address to a mailbox in which someone
received legit mail, and other persons corresponded with said person,
possessed this email address, then there are some BCPs regarding turning
such addresses into traps:

1. Mailbox must be disabled
2. 5xx "unknown user" must be returned for at least 2 years,
5 years if the mailbox has existed for more than 5 years
3. Monitor mailbox for this 2 years for legit mail
4. If the mailbox received legit mail in the last 6 months,
extend period another year, repeat as necessary
5. When you reach no legit mail in the last 6 months, turn
mailbox back on for spamtrap use
6. Collect and analyze the spam, use the data as you wish

I get the impression that what you've done is taken mailboxes that were
phished or password cracked , used by spammers to SEND spam, and have
used these addresses in a filter scheme. This is NOT the same as a
spamtrap. I don't even know if there's been a term coined for such a
thing. Is this indeed what you're doing?

--
Stan

[Noel Jones]

Yes, that is the intent. The recipient must be accepted to get to
the post-filter DISCARD.

>
> If so, then I assume that I leave only postscreen listening at the
> 'real' external address, and the spamtrap address check shoud remaing
> associated with the 127.0.0.1:10026 reinjection listener, as you'd
> previously advised?

Yes, the check for the spamtrap recipient must be in the
127.0.0.1:10026 listener for DISCARD to work.



-- Noel Jones

[rg8...@airpost.net]

Hello,

On Thu, Feb 23, 2012, at 03:46 PM, Noel Jones wrote:

> On 2/23/2012 3:39 PM, /dev/rob0 wrote:
> The check_recipient_access with DISCARD is probably easiest, but the
> spamtrap address must be accepted by the pre-filter postfix.

Looking for the most straightforward place to do this, in my main.cf I
have currently

...
virtual_transport = lmtp:unix:private/dovecot-lmtp
virtual_mailbox_domains = proxy:mysql:/etc/postfix/sql/vdomains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/sql/vmailboxes.cf
...

Where "valid addresses ( == <valid user>@<valid domain>)" are assembled
from "valid users" queried for in 'vmailboxes.cf' and "valid domains"
queried for in 'vdomains.cf'.

It is this combination/check that's being done for (non)existing users.
Those that don't exist, get rejected on the spot.

Since spamtrap addresses sourced by compromise of previously-good
addresses are all, by definition, at domains I own/manage, I was
thinking that a hash: table of <valid user> parts only, e.g.

cat /etc/postfix/spamtrap_userparts
test1
test2
test3
postmap /etc/postfix/spamtrap_userparts

then changing

- virtual_mailbox_maps = proxy:mysql:/etc/postfix/sql/vmailboxes.cf
+ virtual_mailbox_maps = hash:/etc/postfix/spamtrap_userparts
+ proxy:mysql:/etc/postfix/sql/vmailboxes.cf

might do the trick for getting through the pre-filter postfix; my
intention would be here that those spamtrap addresses are identified as
valid_users.
then the downstream check at 127.0.0.1:10026 reinjection listener,
checking against

cat /etc/postfix/spamtrap
te...@mydomain1.com DISCARD
te...@mydomain2.com DISCARD
te...@mydomain3.com DISCARD
postmap /etc/postfix/spamtrap

should now actually receive, and hopefully trigger upon, the
spamtrap-containing message?

Does this sound like a reasonable approach that will, most importantly,
not cause other inadvertent breakage?

If so, I'd eventually consolidate the /etc/postfix/spamtrap
/etc/postfix/spamtrap_userparts into a sql table, so as to remove
overlap/redundancy of information ...

Cheers,

Roger

[rg8...@airpost.net]

Hello,

On Thu, Feb 23, 2012, at 04:11 PM, Stan Hoeppner wrote:
> > Prior to its compromise, it was verifiable as an existing & valid
> > "user@domain" in the virtual user/domain (sql) lookup tables.
>
> If this was at one time an actual address to a mailbox in which someone
> received legit mail

It was

> and other persons corresponded with said person, possessed this email address,

They did

> then there are some BCPs regarding turning such addresses into traps:

Assuming BCP == Best Current Practice (?), these

> 1. Mailbox must be disabled
> 2. 5xx "unknown user" must be returned for at least 2 years,
> 5 years if the mailbox has existed for more than 5 years
> 3. Monitor mailbox for this 2 years for legit mail
> 4. If the mailbox received legit mail in the last 6 months,
> extend period another year, repeat as necessary
> 5. When you reach no legit mail in the last 6 months, turn
> mailbox back on for spamtrap use
> 6. Collect and analyze the spam, use the data as you wish

are useful & generally followed

in the actionable cases I'm considering, the spamtrap addressed -- yes,
they're 'converted' from prior valid usage -- were unique,
singly-purposed addresses, given to single vendors for sole usage by
them. in all cases of documented compromise, I contacted the vendor,
change my working, unique email to something else, and then and ONLY
then, converted the compromised address for spamtrap usage.

> I get the impression that what you've done is taken mailboxes that were
> phished or password cracked

no. accounts that vendors had for business transaction with me, that
were compromised on THEIR end. e.g., data breach. no shortage of those
...

> used by spammers to SEND spam, and have used these addresses in a filter scheme.

as was the object of the compromise, they're now used by spammers to
send spam TO ...

> This is NOT the same as a spamtrap. I don't even know if there's been a term coined for such a thing. Is this indeed what you're doing?

Per above, not really.

Thanks for the info.

Cheers,

Roger

[rg8...@airpost.net]

Hello Noel,

On Thu, Feb 23, 2012, at 04:13 PM, Noel Jones wrote:
> > So IIUC, I need to RE-add the list of spamtraps in the has table as
> > valid users (removed as valid after known to be compromised ...) so
> > that, rather than being off-hand rejected as an unkonw/non-existent
> > user@domain, the multiple-recipient message gets carried through far
> > enought to get to where that DISCARD check+action is valid?
> >
> > Is that approaching correct?
>
> Yes, that is the intent. The recipient must be accepted to get to
> the post-filter DISCARD.
>

> > If so, then I assume that I leave only postscreen listening at the
> > 'real' external address, and the spamtrap address check shoud remaing
> > associated with the 127.0.0.1:10026 reinjection listener, as you'd
> > previously advised?
>
> Yes, the check for the spamtrap recipient must be in the
> 127.0.0.1:10026 listener for DISCARD to work.

This has become so much clearer with your comments & direction. Thanks
very much.

Now to take it for a spin.

Cheers,

Roger

[Noel Jones]

Wrong format; table entries must have a result. In this specific
case, postfix doesn't actually use the result, but *something* must
be there.

And I'm pretty sure you need full addresses, not just usernames.

# these are all considered valid users
te...@example.tld valid_user
te...@example.tld Anything
te...@example.tld melt_CPU

>
> then changing
>
> - virtual_mailbox_maps = proxy:mysql:/etc/postfix/sql/vmailboxes.cf
> + virtual_mailbox_maps = hash:/etc/postfix/spamtrap_userparts
> + proxy:mysql:/etc/postfix/sql/vmailboxes.cf

Yes, that should work fine without any ill effects.

>
> might do the trick for getting through the pre-filter postfix; my
> intention would be here that those spamtrap addresses are identified as
> valid_users.
> then the downstream check at 127.0.0.1:10026 reinjection listener,
> checking against
>
> cat /etc/postfix/spamtrap
> te...@mydomain1.com DISCARD
> te...@mydomain2.com DISCARD
> te...@mydomain3.com DISCARD
> postmap /etc/postfix/spamtrap
>
> should now actually receive, and hopefully trigger upon, the
> spamtrap-containing message?

Yes.



-- Noel Jones

[rg8...@airpost.net]

Hello

On Thu, Feb 23, 2012, at 04:36 PM, Noel Jones wrote:
> > cat /etc/postfix/spamtrap_userparts
> > test1
> > test2
> > test3
> > postmap /etc/postfix/spamtrap_userparts

> Wrong format; table entries must have a result. In this specific
> case, postfix doesn't actually use the result, but *something* must
> be there.

Gotcha.

> And I'm pretty sure you need full addresses, not just usernames.
>
> # these are all considered valid users
> te...@example.tld valid_user
> te...@example.tld Anything
> te...@example.tld melt_CPU

Noted.

In this check I've only been using SQL stored function calls in the
queries (query = SELECT func('arg');), where the query results are just
"1" or "null",

postmap -q valid_domain_part
proxy:mysql:/etc/postfix/sql/vdomains.cf
1
postmap -q invalid_domain_part
proxy:mysql:/etc/postfix/sql/vdomains.cf
null
postmap -q valid_user_part
proxy:mysql:/etc/postfix/sql/vmailboxes.cf
1
postmap -q invalid_user_part
proxy:mysql:/etc/postfix/sql/vmailboxes.cf
null

and it's been working great. Didn't realize that there was a
full_address requirement for the hash: table check. Thanks for pointing
out the possibility -- I'll keep an eye on it.

> > + virtual_mailbox_maps = hash:/etc/postfix/spamtrap_userparts
> > + proxy:mysql:/etc/postfix/sql/vmailboxes.cf

> Yes, that should work fine without any ill effects.

> > should now actually receive, and hopefully trigger upon, the
> > spamtrap-containing message?

> Yes.

Then, I've homework to do. Thanks again.

Cheers,

Roger

[Stan Hoeppner]

On 2/23/2012 4:01 PM, Noel Jones wrote:

> (aka REJECT_DAMMIT)

Oh I like that action. ;) And it's self documenting.

Probably a bit irreverent for Wietse's taste, though. :(

--
Stan

[Noel Jones]

after this thread he may consider it.

[Stan Hoeppner]

On 2/23/2012 4:32 PM, rg8...@airpost.net wrote:

> in the actionable cases I'm considering, the spamtrap addressed -- yes,
> they're 'converted' from prior valid usage -- were unique,
> singly-purposed addresses, given to single vendors for sole usage by
> them. in all cases of documented compromise, I contacted the vendor,
> change my working, unique email to something else, and then and ONLY
> then, converted the compromised address for spamtrap usage.

Ahh, ok.

>> I get the impression that what you've done is taken mailboxes that were
>> phished or password cracked
>
> no. accounts that vendors had for business transaction with me, that
> were compromised on THEIR end. e.g., data breach. no shortage of those

Heheh. At least it was someone else fault then. :)

> as was the object of the compromise, they're now used by spammers to
> send spam TO ...

Ok, so what's the practical difference between this 'spamtrap' DISCARD
solution and simply returning a 5xx unknown user for these addresses?

Does this spammer always send to multiple recipients including at least
one of these 'spamtrap' addresses?

--
Stan

[rg8...@airpost.net]

Hello,

On Thu, Feb 23, 2012, at 06:12 PM, Stan Hoeppner wrote:
> Ok, so what's the practical difference between this 'spamtrap' DISCARD
> solution and simply returning a 5xx unknown user for these addresses?
>
> Does this spammer always send to multiple recipients including at least
> one of these 'spamtrap' addresses?

Sending to any of

<valid_user>@<unknown_domain>
<unknown_user>@<valid_domain>
<unknown_user>@<unknown_domain>

can, and is, subject to immediate reject based solely on the 'unkown'
criterion.

The specific use case I'm targeting, which is far too common, is as
follows,

Let's say I have two valid users,

ro...@rogermail.com
rogers_bobs...@rogermail.com

and "Bob's Electronics" gets hacked, and their user DB compromised so
that my new Uzbekistani best friends now have that address for keeping
in touch at the holidays.

I immediately change my official Bob's Electronics-dedicated, registered
address from

rogers_bobs...@rogermail.com

to

rogers_NEW_bo...@rogermail.com

Henceforth, the ONLY usage of that old address,
rogers_bobs...@rogermail.com, is for spam. It never has been
used for anything other than communications to/from Bob's Electronics,
and now that it's no longer valid, it can be only used for one thing.

Now, I'll almost immediately start seeing emails addressed as, e.g.,

TO:
<ro...@rogermail.com>,<rog...@rogermail.com>,<luc...@microsoft.com>,<rogers_bobs...@rogermail.com>

If only the 1st three of those addresses were present, my policy would
be to
-- accept the mail to the 1st address, subjecting it to usual "heavy"
scanning
-- reject the second & third addresses as an unknown

But, for all I know, the second address could be a fat-thumbed typo from
a legit sender, and lucifer@miscrosoft really COULD be on the same
interest list as I am.
I.e., insufficient cause to DISCARD all.

However, if all FOUR addresses are there, including,
<rogers_bobs...@rogermail.com>, since it's no longer a viable
address for comms from Bob's Electronics, it's -- for my uses and by my
definitions -- from a spammer.
That IS sufficient criterion by my measure, for DISCARDing the message
to/for all the recipients.

Over the past years, amidst countless 3rd party breaches, I've amassed
several hundreds of these formerly-valid, now-compromised 'spamtrap'
addresses.
I've dumped several 10Ks of definitely-spam messages using this
approach, and not once in all those years have I ever become aware of a
false positive. Either because there were none, or it wasn't that
important in the 1st place. Either works for me.

CommunigatePro has, for many years, provided a mechanism to deal with
this trivially. Again, method for me is irrelevant -- simply outcome is
of interest. And that, in this thread, is what I've been striving for.

With your, Rob's and Noel's help, I have something tangible and
reasonably promising to try.

Thanks.

Cheers,

Roger

[rg8...@airpost.net]

Success.

Changes required were exactly what Noel suggested, getting the mail past
the pre-queue filter.

In informed hindsight, simple to implement.

In main.cf

- virtual_mailbox_maps =
proxy:mysql:/etc/postfix/sql/vmailboxes.cf
+ virtual_mailbox_maps =

proxy:mysql:/etc/postfix/sql/vmailboxes.cf
+ hash:/etc/postfix/spamtrap

In master.cf, at the *localhost* -- NOT external-address -- reinjection
listener,

127.0.0.1:10026 inet n - n - -
smtpd
...
-o
smtpd_sender_restrictions=check_recipient_access,hash:/etc/postfix/spamtrap

...

and,

cat /etc/postfix/spamtrap
sp...@mail.rogermail.lan DISCARD
postmap /etc/postfix/spamtrap

Test-sending from desktop to server,

sendmail -i -t
From: ro...@desk.rogermail.lan

To: ro...@mail.rogermail.lan,sp...@mail.rogermail.lan
Subject: test
testing

@ server logs,

Feb 23 17:15:23 mail postfix/postscreen[28255]: CONNECT from
[192.168.1.13]:45288
Feb 23 17:15:23 mail postfix/postscreen[28255]: PASS OLD
[192.168.1.13]:45288
Feb 23 17:15:23 mail postfix/smtpd[28284]: connect from
desk.rogermail.lan[192.168.1.13]
Feb 23 17:15:23 mail postfix/smtpd[28284]: NOQUEUE:
client=desk.rogermail.lan[192.168.1.13]
Feb 23 17:15:23 mail postfix/smtpd[28285]: connect from
localhost[127.0.0.1]
Feb 23 17:15:23 mail postfix/smtpd[28285]: 7766720337:

client=localhost[127.0.0.1],
orig_client=desk.rogermail.lan[192.168.1.13]

!! Feb 23 17:15:23 mail postfix/smtpd[28285]: 7766720337: discard:
RCPT from localhost[127.0.0.1]: <sp...@mail.rogermail.lan>: Recipient
address triggers DISCARD action; from=<ro...@desk.rogermail.lan>
to=<sp...@mail.rogermail.lan> proto=ESMTP helo=<mail.rogermail.lan>
Feb 23 17:15:23 mail spampd[32019]: processing message
<201202240115...@desk.rogermail.lan> for
<ro...@mail.rogermail.lan>
ORCPT=rfc822;ro...@mail.rogermail.lan,<sp...@mail.rogermail.lan>
ORCPT=rfc822;sp...@mail.rogermail.lan
Feb 23 17:15:25 mail spampd[32019]: clean message
<201202240115...@desk.rogermail.lan> (0.00/4.00) from
<ro...@desk.rogermail.lan> for <ro...@mail.rogermail.lan>
ORCPT=rfc822;ro...@mail.rogermail.lan,<sp...@mail.rogermail.lan>
ORCPT=rfc822;sp...@mail.rogermail.lan in 1.55s, 566 bytes.
Feb 23 17:15:25 mail postfix/smtpd[28284]: proxy-accept:
END-OF-MESSAGE: 250 2.0.0 Ok: queued as 7766720337;

from=<ro...@desk.rogermail.lan> to=<ro...@mail.rogermail.lan>
proto=ESMTP helo=<desk.rogermail.lan>

Feb 23 17:15:25 mail postfix/smtpd[28284]: disconnect from
desk.rogermail.lan[192.168.1.13]
Feb 23 17:15:25 mail postfix/smtpd[28285]: disconnect from
localhost[127.0.0.1]

I note the DISCARD action is now triggered -->
<sp...@mail.rogermail.lan>: Recipient address triggers DISCARD action;

Although I don't specifically see a second DISCARD for the 2nd, 'valid'
recipient address, it's never delivered. I'm guessing that that DISCARD
does effectively prevent subsequent delivery/processing of the *message*
for any/all of the recipients. I'd like to prove affirmatively to
myself that that's the case, rather than simply make an assumption based
on lack of delivery. Perhaps more verbose logging and/or an additional
bit of reading will help there.

Again, Noel, Rob & Stan -- Thanks.

Cheers,

Roger

[Noel Jones]

On 2/23/2012 7:33 PM, rg8...@airpost.net wrote:
> Success.

Congratulations.

>
> I note the DISCARD action is now triggered -->
> <sp...@mail.rogermail.lan>: Recipient address triggers DISCARD action;
>
> Although I don't specifically see a second DISCARD for the 2nd, 'valid'
> recipient address, it's never delivered. I'm guessing that that DISCARD
> does effectively prevent subsequent delivery/processing of the *message*
> for any/all of the recipients.

One of the things I really like about Postfix is the remarkably
complete and accurate documentation. You can reliably expect the
program to behave like the docs say. Example from
http://www.postfix.org/access.5.html

DISCARD optional text...
Claim successful delivery and silently discard the
message. Log the optional text if specified, oth-
erwise log a generic message.

Note: this action currently affects all recipients
of the message. To discard only one recipient
without discarding the entire message, use the
transport(5) table to direct mail to the discard(8)
service.

I also like that the normal non-debug logging tells you just about
everything important, and yet contains very little non-relevant
fluff. So once DISCARD is triggered and logged, you can expect the
entire message and all recipients to be discarded.

> I'd like to prove affirmatively to
> myself that that's the case, rather than simply make an assumption based
> on lack of delivery.

Grep the log for the QUEUEID of the message in question to see where
the message came from and how it was disposed.

> Perhaps more verbose logging and/or an additional
> bit of reading will help there.

For fun you can increase the log verbosity (see DEBUG_README), but
that generally just hides the important stuff in a pile of unrelated
noise.



-- Noel Jones

[rg8...@airpost.net]

Hello Noel,

On Thu, Feb 23, 2012, at 09:28 PM, Noel Jones wrote:
> On 2/23/2012 7:33 PM, rg8...@airpost.net wrote:

> Congratulations.

Your help was key. Thanks.

> One of the things I really like about Postfix is the remarkably
> complete and accurate documentation.

You forgot a couple of descriptors -- dense and voluminous. In
reference form, quite useful once one's learned to search for & find the
relevant info efficiently.

> Grep the log for the QUEUEID of the message in question to see where the message came from and how it was disposed.

Thanks.

> For fun you can increase the log verbosity (see DEBUG_README), but
> that generally just hides the important stuff in a pile of unrelated noise.

I was just reading, and experimenting with that. Certainly lots of
detail available. I'd evolved to be able to read Communigate logs for
gist with a mere glance. It'll take me a little while to get similarly
used to the form & format of Postfix logs.

Given a choice, tho, I do prefer the unrelated noise of debug logs to
that in threads!

Cheers,

Roger