I just happened to notice I'm getting a 3-4 minute delay on occasion between SA scanning a msg and it being piped back into Postfix. Here's one such complete transaction. Note spamd processing takes 10 seconds, then we have a ~4 minute delay. For 95% of these SA deliveries the delay is less than 5 seconds.

On 1/8/2013 3:46 PM, <a href="mailto: ... at vheuser dot com"> ... at vheuser dot com</a> wrote:

To stop list mail, send mail to <a href="mailto: ... at postfix dot org"> ... at postfix dot org</a> with content (not
subject) one or more of the following commands:

unsubscribe postfix-announce
* unsubscribe postfix-users
unsubscribe postfix-users-digest
unsubscribe postfix-devel

* Denotes the list to which you are currently subscribed.

Would someone kindly point me to the docs that describe the behavior of
smtpd socket open time in relation to clients that do connection caching?

I've been assisting in a troubleshooting effort. A sendmail/mailman
based list server is opening more than 4 concurrent connections to my MX
even when it has less than a half dozen messages to deliver, which
suggests connection caching on their end is not working properly.

Thanks.

/etc/postfix/master.cf:
# =============================================================
# service type private unpriv chroot wakeup maxproc command
# (yes) (yes) (yes) (never) (100)
# =============================================================
smtp inet ...other stuff here, do not change... smtpd
-o content_filter=filter:dummy

The "-o content_filter" line causes Postfix to add one content filter
request record to each incoming mail message, with content
"filter:dummy".

I can't seem to find any logging of permit_dnswl_client actions. Maybe
I just don't know what to grep for. I would like to be able to track
such data.

As fqrdns.pcre has been a topic recently, I feel this needs to be stated
again, for those of you who have missed previous threads on this topic.

1. Postscreen rejects most bots BEFORE they reach smtpd processes
(fqrdns.pcre is evaluated by smtpd)
2. AFAIK postscreen never FP's
3. postscreen consumes very little resources

*Therefore postscreen is preferred over fqrdns.pcre for rejecting bots.*

You can still run fqrdns.pcre in tandem behind postscreen, in
smtpd_*_restrictions, but it will likely reject few bots.

Received: from mail-iw0-f176.google.com (biz88.inmotionhosting.com
[66.117.14.32])
by greer.hardwarefreak.com (Postfix) with ESMTP id F297D6C12E
for < ... at hardwarefreak dot com>; Thu, 31 Mar 2011 06:29:19 -0500

biz88.inmotionhosting.com is the reverse name and
mail-iw0-f176.google.com is the forward name, correct? How is this VPS
hosted snowshoe spammer spoofing a forward host name of google.com?

I'm no DNS expert but I didn't think spoofing a forward lookup was
possible, as one must control the DNS servers (or a zone) for that
domain. What am I missing?

I'm trying to match this and similar phish mail subjects:

postmap -q matches this expression, but this is too broad.
/Subject:.*won.*\d.*/ REJECT Probable phish

In the second, and variations, escaping the $ doesn't seem to work.
/Subject:.*won.*\$\d.*/ REJECT Probable phish
/Subject:.*won \$\d.*/ REJECT Probable phish

What the heck am I missing WRT making $ literal?

How would I go about passing strictly the rDNS and EHLO hostnames to a
policy daemon? Is this possible? If not, other suggestions?

Thanks.

Victor,

Would you please give us the run down on why these map types (and maybe
others) shouldn't be used with proxymap due to performance reasons? You
mentioned something about this long ago but I can't seem to locate that
email in my archives. IIRC you didn't go into much technical detail as
to why the performance would be lower using proxymap.

Thanks.

=?iso-8859-1?Q?Le_invitamos_a_asistir_a_la_Presentaci=F3n_de_la_Oportunid?=
=?iso-8859-1?Q?ad_de_negocio_en_ACN_Marketing_y_Servicios_de_Telecomunica?=
=?iso-8859-1?Q?ciones?=

Does anyone have a header_checks pcre that would allow me to reject or
discard any email with an encoded subject such as, but not limited to,
that above. I.e. non plain text?

I can't recall ever receiving legit email with an encoded subject, only
spam.

What's the CIDR lookup table performance difference between say 256 /32
entries and a single /24 entry? Is it 256:1? Or, how about 90,000 /32
entries vs 60,000 entries that consolidate many of those 90,000 /32s
into larger CIDRs such as /24s and /21s etc? I have no idea what the
total processing time would be on such size CIDRs. Is it small enough
to be irrelevant, or are we looking at something like multiple seconds
per lookup (obviously dependent on hardware)?

Thanks.

Is there a way to have locally submitted mail (my_networks) bypass
header_checks when using a single master.cf smtpd instance?

Since implementing Sahil's fine checkdbl.pl tcp server in header_checks,
I've noticed a 1-3 second delay when submitting from my workstation MUA.
Prior to this submission was instantaneous.

If implementing a submission smtpd is the only way to solve this, is
there an easy one line parameter to instruct it to bypass all
header_checks and smtp_foo_restrictions and simply permit everything
from 192.168.100.0/24?

Thanks.

Considering that spam accounts for the bulk of all client connections to
an MX these days, it might be beneficial if we had log data showing
total time per session, not just for queued mail, so an OP can see how
long it's taking to reject at the smtpd stage, as well as time elapsed
when rejecting messages at cleanup with header/body checks, or with a
pre-queue content filter, etc.

If a server accepts 10k smtpd connections a day and rejects 9k via
smtpd_*_restrictions, 400 via a pre-queue content filter, and 100 via
header checks, etc, it would seem that the amount of processing time
required

After replacing pflogsumm with logwatch, I've noticed in each summary a
"resent" stat I wasn't noticing before. What is the significance of
"resent-message-id"?

Is there a straightforward (i.e. relatively painless) way to check the
header from, reply-to, and message-id domains against dbl.spamhaus.org
and reject on a positive reply as with reject_r*bl_client?

Without having to write a content filter to be called in action
filter:nexthop in header_checks.pcre?

Would anyone happen to have an example guide showing the proper
master.cf and main.cf parameters for setting up daemonized spamassassin
to run super selectively via FILTER?

I've reached the point that I'm killing about 98% of my spam load but
I'm tired of the few phish/419 that make it into my inbox due to "zero
day" attacks from compromised Hotmail, Yahoo, Squirrelmail, Horde,
Exchange accounts and the like.

Does Postfix consider "architettobellucci.com" an FQDN? I've always
understood an FQDN as requiring all 3 of host.domain.tld. If my understanding
of FQDN is correct, then a spam slipped through that I believe should have
been rejected by reject_non_fqdn_helo_hostname.

I'm current using recipient_bcc_maps to forward spam trap emails to a dnsbl.
I've been asked by another dnsbl to provide them the same trap data.
According to recipient_bcc_maps, I can't bcc to more than one address. I
thought of creating a local alias that expands to both addresses and bcc'ing
that local alias address, but my further reading of recipient_bcc_maps says
I can't do that either.

How can I accomplish this "simple" task? I'm using 2.5.5.

Thanks.

"Thou shalt not quote RFC whilst composing in HTML or RTF!"

I think that's chiseled on a stone tablet somewhere. If not it should have
been.

What's the best way to integrate the Spamhaus DBL for folks not already
using SA et al?

Will the following work, or does it check only the entire hostname, and not
the domain portion in isolation as well?

smtpd_recipient_restrictions =
reject_rhsbl_client dbl.spamhaus.org

Kay put forth on 2/1/2010 11:49 AM:

I think you're making some incorrect assumptions. Squirrelmail has had a pretty
abysmal security track record of its own over the years. One reason for that is
probably exactly what you're calling out Roundcube for here, which has nothing
to do with the software, but the administration of the system. That said, you
appear to think the world runs on Red Hat, and if Red Hat doesn't have a
Roundcube package, admins will install from source or an external RPM that
doesn't get updated by Red Hat's uptodate or whatever it's called.

Hay Wietse,

Someone was wondering on spam-l why Postfix defaults smtpd VRFY to ON instead of
OFF. Their theory being that the default of ON makes it easier for spammers to
harvest addresses.

Most people shut if off (including me). Then spammers go to RCPT TO checking,
so IMO it makes little difference. Just wanted your position on this so I can
post an official response to spam-l. I don't want Postfix (or you) getting any
kind of ill-deserved reputation due to VRFY defaulting to on. Minor issue,
silly yes, but apparently important to some.

So, what do I tell them?

Based on purely visual non-scientific observation (top), it seems my smtpd
processes on my MX hang around much longer in (Debian) 2.5.5 than they did in
(Debian) 2.3.8. In 2.3.8 Master seemed to build them and tear them down very
quickly after the transaction was complete. An smtpd process' lifespan was
usually 10 seconds or less on my 2.3.8. In 2.5.5 smtpd's seem to hang around
for up to 30 secs to a minute.

Local shows very speedy delivery.

Stan Hoeppner put forth on 1/22/2010 1:28 AM:

Bad form replying to my own post but...

After a hint from Ralf, I started digging around and here is what I found:

1. Spamhaus has banned Google Public DNS resolver queries. I didn't know this
until today. If Postfix is using Google Public DNS resolvers, rbl queries to
zen.spamhaus.org fail but Postfix (Debian Lenny 2.5.5-1.1) logs NOTHING about
it. Not the query attempt, not the failure, zilch, nut'n.

I've wondered for a couple of months why my rbl check is being skipped. I've
not seen a spamhaus entry in my logs since Sept 25 '09. Interestingly, postgrey
is being called now and then, and it is after the rbl check in main.cf. Any
idea why my rbl check is being skipped?

Daniel L. Miller put forth on 1/18/2010 1:30 PM:

How is the above mentioned solution an "OP-maintained" list? The scripts and
cron scheduling would be OP maintained (not much time expended after initial
setup) but once setup the white listing is fully automated. As an example...

Add in the appropriate place in main.cf
check_sender_access hash:/etc/postfix/auto-whtlst

Set your log rotation for 24 hours so you never have a huge /var/log/mail.log
file to process. Touch /etc/postfix/auto-whtlst and
/etc/postfix/auto-whtlst.raw.

This question touches on far more than Postfix, so I hope it doesn't offend
anyone being slightly OT.

A little background may help:

I built my current Postfix host in late 2005 as a single purpose
firewall/gateway to sit in front of an old Ms Exch server, on which I've
archived email since 2000. The Postfix firewall has functioned in this mode for
4+ years. It's running on a Debian system up to date at 5.0.3 with all patches
installed and a custom kernel, 2.6.31.1.

I finally consolidated all my smtpd_foo_restrictions into
smtpd_recipient_restrictions, as many have suggested, mainly to get my
whitelisting working properly/reliably. Since doing so, I've noticed a
substantial increase in smtpd warnings. Is this smtpd warning increase
a result of this consolidation, or something unrelated?

Previously, I'd see a half dozen or so of these per day max. This is a
very low volume (vanity) server, less than 1000 connects/day.

I can't figure out why my whitelist entry for 204.238.179.0/24 is being
ignored. If not for a transient DNS failure this afternoon I'd not have
known this was broken. The check_client_access whitelist entry _should_
have triggered before reject_unknown_client_hostname.