[pfx] Re: Update issue 3.8.5-3.9.0

[Michael Orlitzky via Postfix-users]

On Sat, 2024-08-31 at 15:33 -0400, Phil Stracchino via Postfix-users
wrote:
> 
> My conclusion is:  The mail_version set by 3.9.0 is not what is 
> expected, but *this will only be a problem to you* if you have config 
> directives that you no longer need ANYWAY.  Go through main.cf and clean 
> up anything not actually needed, and PROBABLY the problem will disappear.

Pending confirmation, I think what happened is that the postfix install
routine upgraded your existing $shlib_directory in main.cf to refer to
3.9.0, but the default $mail_version (absent from main.cf) was changed
to 3.9.

In any case, it's fixable now that we know there's a problem.

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Update issue 3.8.5-3.9.0

[Michael Orlitzky via Postfix-users]

On Sun, 2024-09-01 at 04:41 +1000, Viktor Dukhovni via Postfix-users
wrote:
> 
> How did you get Postfix to believe its version is "3.9".  There was
> never such a release.  Official Postfix release versions always have
> a micro "patch level".

Looks to be from

  #define MAIL_VERSION_NUMBER   "3.9"

in postfix-3.9.0/src/global/mail_version.h.


> If Gentoo builds arrange it to be otherwise, why odes Phil's version 
> have the expected three parts?

That part is still a mystery. We set

  shlib_directory = /usr/lib64/postfix/${mail_version}

but somehow his new postfix didn't get the memo.

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Re: postfix-policyd-spf-python

[Michael Orlitzky]

On Thu, 2022-05-12 at 21:03 +, Dino Edwards wrote:
> Hi,
> 
> Not sure if this is the right place to post the question concerning
> postfix-policyd-spf-python but I can't seem to find any working links
> for the openspf project.
> 

You should start here,

  https://launchpad.net/spf-engine

but the author is also on this list (I believe) and may reply directly.

Re: How can I build a reliable distribution list?

[Michael Orlitzky]

On Thu, 2022-01-13 at 15:20 +0100, Markus Grunwald wrote:
> 
> I'm a bit at the end of my wits. All I want is that people can 
> send a mail to distribut...@myserver.de and some 20 other people 
> with various addresses will get that mail reliably. Being able to 
> respond is a bonus, but not really necessary.
> 

The hardest problems often have the simplest statements. An alias will
never work due to SPF. A mailing list can, but you have to be careful
with DKIM/DMARC. Those signatures protect the "From" address and the
body of the message, so when the sender has a policy that insists the
signature be valid, you either (a) can't touch them, or (b) can't
retain the original sender/signature.

In short, you have to choose a mailing list package that is aware of
the issues and can work around them, like the 3.x series of GNU
Mailman. And then you have to configure it very carefully.

Re: TCP wrappers and Postfix

[Michael Orlitzky]

On Tue, 2021-02-16 at 01:51 +0300, Eugene Podshivalov wrote:
> Generic approach to system administration and access control
> reconfiguration at runtime (without service reload).
> 

If you want something more generic than what's already in postfix, the
next level up is probably iptables.

Re: Postscreen Logfile Analyser

[Michael Orlitzky]

On 2020-09-11 14:24, Jos Chrispijn wrote:
> Can someone recommend a reliable Postscreen logfile analyser (FreeBSD 12)?
> Thanks in advance!

I still use postfix-logwatch (http://logreporters.sourceforge.net/), but
there are a few patches to apply since the maintainer went AWOL:

https://gitweb.gentoo.org/repo/gentoo.git/tree/net-mail/postfix-logwatch/files

Postfix is stable enough that I can afford to learn perl whenever the
log format changes.

Re: Cached postscreen blacklist bypass

[Michael Orlitzky]

On 2020-07-14 09:29, Michael Orlitzky wrote:
> It appears that the blacklist entry is superseded by the cache?
> 
>  ...
> 
> Is that intentional? Fixable? Work-aroundable?
> 

For posterity: digging into the source led me to discover the

  postscreen_blacklist_action (default: ignore)

parameter that was new to me. Setting it to "enforce" or "drop" makes
postscreen reject these connections.

Cached postscreen blacklist bypass

[Michael Orlitzky]

Out postmaster/abuse addresses fall through a trapdoor at the top of
smtpd_recipient_restrictions, and every once in a while someone decides
to abuse that kindness. Yesterday I added 84.54.12.0/24 to postscreen's
blacklist to prevent them from ever reaching the trapdoor. This morning
I was surprised to have an inbox full of junk. It appears that the
blacklist entry is superseded by the cache?

> Jul 13 23:50:32 mx1 postfix/postscreen[29809]: BLACKLISTED 
> [84.54.12.227]:37300
> Jul 13 23:50:32 mx1 postfix/postscreen[29809]: PASS OLD [84.54.12.227]:37300
> Jul 13 23:50:33 mx1 postfix/smtpd[3580]: connect from 
> pupiledition.club[84.54.12.227]

Is that intentional? Fixable? Work-aroundable?

Re: Bounce mails manually

[Michael Orlitzky]

On 1/15/20 5:12 PM, Noel Jones wrote:
> 
> We've had problems with users mistyping domain names, such as hotmal.com
> or aoil.com. And they ignore the delay warning message because they
> still don't notice their typo. 

I can +1 this request, even if it's something I morally shouldn't need.

Sometimes while checking the queue for some other reason, I'll notice a
message that I'm sure won't be deliverable: typo domain, mailbox over
quota, moribund provider, etc.

I'd like to bounce these immediately as a courtesy to the sender.
Blacklisting typo domains is a (technically incorrect) losing battle,
and if the message is to a distribution list, then it's useful for the
sender to know that the recipient is dead.

Yes, they'd get the bounce anyway when the message expires. But if I've
already done the thinkative work to figure out that the message will
bounce, it's a win at zero cost to bounce it immediately.

Docs clarification

[Michael Orlitzky]

POSTSCREEN_README.html says that the error

  NOQUEUE: reject: CONNECT from [address]:port: all server ports busy

is affected by the postscreen_pre_queue_limit parameter. However, in
postscreen.c it looks like the error associated with the "pre_queue"
parameter is "all screening ports busy", and that the error above is
actually affected by the postscreen_POST_queue_limit parameter.

Re: Upgrade to -3.2.5: permissions question

[Michael Orlitzky]

On 01/29/2018 03:31 PM, Viktor Dukhovni wrote:
> 
> This issue affects a lot more than just Postfix, for example tar(1)
> when run as root will chown files to the owner listed in the archive
> metadata, and is almost certainly equally exposed.

I'm not 100% sure, but it looks like GNU tar will use fchown on the
newly-extracted fd to avoid this problem. But you're right that a lot of
other software does the same thing.


> Therefore, while it may be possible to attempt to work around this
> in Postfix, the only sensible solution is at the OS level.

Alas, those linking restrictions are still disabled by default on a
vanilla linux kernel (upstream rejected the patch to enable them), and
on every non-linux OS.

If you absolutely must do a recursive, *automated* ownership change, the
best defense that I'm aware of is to immediately call fstatat() on the
fd obtained from openat() at each stage of the recursive traversal. If
the descriptor has more than one link, reject it as suspicious. There's
still a tiny window between openat() and fstatat() where the attacker
can delete his link (so that your fd points to something juicy, but the
link count is 1), but AFAIK that's as good as it gets.

If you need to do a recursive chown that isn't automated -- like for
example to update $old_mail_owner to $new_mail_owner -- then e.g. GNU
chown has the "--from" option to prevent $old_mail_owner from
introducing hard links.

The best case is when you don't really need to do the recursive chown at
all. Since we have

  $queue_directory:d:root:-:755:uc

it's safe for root to call chown non-recursively on "active/" and
friends. Afterwards, the $mail_owner himself should be creating things
in "active/" and the only way for them to have some other owner would be
if root changed it. Do we want postfix to "fix" things in that case?
Maybe as a last resort... but as part of the standard upgrade procedure?

Re: Upgrade to -3.2.5: permissions question

[Michael Orlitzky]

On 01/29/2018 12:25 PM, Joris (ideeel) wrote:
> 
> Doesnt postfix use proxymap for that?
> http://www.postfix.org/proxymap.8.html
> 

For what? I'm wondering whether or not the upgrade procedure is safe
w.r.t. the $mail_owner user.

Re: Upgrade to -3.2.5: permissions question

[Michael Orlitzky]

On 01/28/2018 01:53 PM, Viktor Dukhovni wrote:
> 
> You're not supposed to do this "by hand".  Instead, when upgrading from 
> source, run:
> 
>   # postfix set-permissions upgrade-configuration
> 

How sensitive is the $mail_owner account? From what I gather, the
set-permissions script (which defers to post-install) is intended to be
run more than once on the same system. It reads postfix-files, which
contains e.g.

  $queue_directory/active:d:$mail_owner:-:700:ucr

and then in post-install, lines like that are read...

  while IFS=: read path type owner group mode flags junk

and the flags are parsed:

  case $flags in *u*) upgrade_flag=1;; *) upgrade_flag=;; esac
  case $flags in *c*) create_flag=1;; *) create_flag=;; esac
  case $flags in *r*) recursive="-R";; *) recursive=;; esac

In particular, that will result in "chown -R" being called on my active
queue directory whenever "postfix set-permissions" is run:

  test -n "$set_permission" && {
chown $recursive $owner $path || exit 1

My question is, can't the $mail_owner -- who knows that this is going to
take place eventually -- throw a hard link into the active queue that
points to a sensitive file? Proof of concept:

  $ sudo su postfix -s /bin/sh -c 'ln /etc/passwd
/var/spool/postfix/active/x'
  $ sudo postfix set-permissions
  $ ls /etc/passwd
  -rw-r--r-- 2 postfix root 1.4K 2018-01-27 11:47 /etc/passwd

Re: disable receiving for particular email

[Michael Orlitzky]

On 10/20/2017 09:57 AM, Ralph Seichter wrote:
> 
> Depending on the use case, discarding email can be as valid a method as
> rejecting email. Messages sent by automation- or monitoring-services
> (Jenkins, Icinga) come to mind. If somebody chooses to reply to these
> machine-generated notifications, I expect him to manually select a human
> recipient, or the reply will be silently ignored.
> 

You don't want to send Nagios alerts to someone who keeps replying "YOU
HAVE THE WRONG PHONE NUMBER."

You don't want to send Jenkins reports to an email address that has been
dead since Dave quit five years ago.

If one of your coworkers who apparently has something important to
communicate hits "reply" on a build failure, I'm not sure how silently
ignoring him is better than responding with "I think you meant to send
this to the Jenkins admin."

tl;dr use a real address

Re: What user should be specified for the opendikm -u UID option?

[Michael Orlitzky]

On 09/03/2017 07:43 AM, Wietse Venema wrote:
> Tom Browder:
>> The docs mention not to use root or postfix for the "-u UID" option. Then
>> what user should it be? Is a new user to be created for that purpose?
>> Should that same user own the /var/db/dkim directory and files?
> 
> All my opendkim FILES are owned by root, in directories owned by
> root, and those files/directories are writable only by root. Note
> that opendkim reads the secret key before dropping root privileges.
> 

I just did some experiments with this. If you're using a KeyTable and
SigningTable, it looks like OpenDKIM will read those as root, but not
all of the secret keys.

(The rest is quite skippable if you're not interested in such a setup.)

If your OpenDKIM user is named "opendkim" and is a member of the
"opendkim" group, then the obvious way to deal with that is to make your
keys (and the directories they're contained in) read-only to the
"opendkim" group. So far so good.

But now what if you want to use a local UNIX socket to talk to OpenDKIM?
Postfix needs to be able to write to it. On most systems, the socket
will be created as opendkim:opendkim, and if you add the "postfix" user
to the "opendkim" group, then

  1. that's more access than postfix should have to your keys, and

  2. the OpenDKIM daemon will complain to the effect of #1.

So to share a socket, you need another group. I created a new group
called "milter", and added both the "postfix" and "opendkim" users to
it. Here I tried to tell OpenDKIM to run as "opendkim:milter",  but that
doesn't work because when you specify one particular group, it omits all
of that user's other groups -- including the "opendkim" group that you
need to read your keys!

Fortunately, you can tell the system to use "milter" as the primary
group for the "opendkim" user. Just swap the two with,

  $ usermod -g milter opendkim
  $ usermod -a -G milter opendkim

Now if OpenDKIM is running as user "opendkim", it will create the socket
with that user's primary group "milter", but still be able to access
your keys via the secondary group "opendkim".

To summarize,

  * OpenDKIM runs as UserID "opendkim", an otherwise-unused user.
  * all OpenDKIM files owned by "root"
  * key table and signing table are group "root"
  * secret keys are group "opendkim" and group-read-only
  * socket needs to belong to a third group containing "opendkim"
and "postfix"
  * you need to make that third group the primary group of "opendkim"
so that the socket gets created with the correct group

Re: Difficulty creating a "nobody@" address

[Michael Orlitzky]

On 01/31/2017 05:45 AM, Tim Smith wrote:
> Hi,
> 
> I’m trying to create a “nobody@“ email address for outbound-only
> transaction confirmations that will /dev/null any attempts to email
> it.
> 

If someone less computer-savvy takes the time to reply to your
confirmation, why would you throw away his response?

Sending these from a real address also helps highlight bugs elsewhere in
the process. For example, if you have a vulnerable web form, you will
find out when the "nobody@" address starts getting Viagra spam
rejections from nonexistent addresses in Russia.

Re: Stopping compromised accounts

[Michael Orlitzky]

On 12/05/2016 08:52 PM, Alex wrote:
> Hi,
> 
> I have a postfix-3.0.5 system with a few hundred users. They have
> access to submission, webmail, and dovecot to send and receive mail.
> 
> On occasion, user's local desktop are compromised, and with it their
> account on this system. This leads to their local desktop using the
> submission service to send hundreds or thousands of spam emails
> through this compromised account.
> 

Sign up for the feedback loops of major providers like AOL, Comcast, and
Yahoo. When their users hit "this is spam," you'll get a report in your
inbox, and you'll be able to see immediately if it was sent from a
compromised account.

On a smallish system where the size of the active queue is usually tiny,
you can also check the number of queued messages every minute or so and
send yourself an alert if it goes over some threshold.

Neither will stop the spam from going out, but they'll at least alert
you to the problem.

Re: [PATCH] Preserve timestamps during 'make install'

[Michael Orlitzky]

On 08/27/2016 07:42 PM, Wietse Venema wrote:
>>
>> Thanks. The "cp -p" feature was not portable in the days that this script
>> was written, but it should be safe to use now.
> 
> Unfortunately, I have to roll back this change, because it may
> install files with non-root ownership.
> 
> Those who built postfix-3.2-2060827 should do "postfix set-permissions"
> or install postfix-3.2-2060828 which I will upload in a few minutes
> time to ftp.porcupine.org.

The "-p" flag (at least in GNU coreutils) is a shortcut for,

  --preserve=mode,ownership,timestamps

Unfortunately, the behavior of "--preserve" is not sufficiently
standard. Perhaps "tar --no-same-owner" can be used as a poor man's cp,
since it preserves modification times by default?

Re: postscreen whitelist

[Michael Orlitzky]

On 05/31/2016 08:16 PM, Terry Barnum wrote:
> 
> Since web.com probably has a fleet of mail servers, do I need to find and 
> enter all their IPs into my postscreen_access.cidr? Is there an easier way?
> 

That's generally what you have to do. Postscreen is meant to catch the
most obvious offenders quickly, so false positives should be rare. Your
"grey area" mail should be analyzed by something more time-consuming and
configurable (i.e. easier to whitelist).

With that in mind, you're putting way too much faith in dnsbl.sorbs.net
and hostkarma.junkemailfilter.com. For a reference point, I have the
same threshold as you (3) but score them each one point.

Re: SV: access permissions 101

[Michael Orlitzky]

On 02/19/2016 08:05 PM, Sebastian Nielsen wrote:
> 
> Yeah, I agree that actually, only 644 is required on that config
> file. But why get so angry when someone 666's a file to just get
> things working? Its not like a list of banned spam domains is
> something super-sensitive.
> 

Maybe this makes a good case in point. Your "list of banned spam
domains" is actually whatever an attacker would like to feed into
check_sender_access. For example, your domain name was registered with
Gandi. Anyone who can execute *anything* on your server can now redirect
all Gandi emails to himself, reset the password on your account, and
take over every domain you own.

Re: SV: SV: Blocking TLDs

[Michael Orlitzky]

On 02/19/2016 06:52 PM, Sebastian Nielsen wrote:
> 
> 2: Its just a habit, everytime some process complains of not able to
> access a file, "666" is the universal solution. Of course, this isn't
> recommended in a web hosting setup, but if you're hosting for example
> a mail server for a company, and only you as a sysadmin has shell
> access to the server, its no danger 666'ing files that throw
> permission errors. Then the file isn't really "world writable", since
> only you have a account on the server anyways.
> 

There are two problems with this. First, you are never the only user in
/etc/passwd. Those other accounts belong to services potentially acting
on behalf of other people, and now they can overwrite your files.

But more importantly: when you need to add a second shell account for an
intern five years from now, did you keep track of every single file that
you changed to mode 666? Whoops, your intern has root.

Re: RegExp help

[Michael Orlitzky]

On 05/14/2015 10:41 AM, Barbara M. wrote:
> 
> I use SA in default config. Never tried to customize rules, so, may be it 
> isn't trivial for me. :-)
> N.B.: I want mail rejected from Postfix not marked as spam and delivered.
> If SA can do this I try it (better if someone give me some example/hints 
> for the .cf ;-))
> 

If the to/from rules aren't very fine-grained, then maybe you want to
put the senders or recipients into restriction classes?

  http://www.postfix.org/RESTRICTION_CLASS_README.html

Re: postfix stats

[Michael Orlitzky]

On 04/30/2015 08:24 PM, Terry Barnum wrote:
> I've been using pflogsumm but it's old and doesn't know about
> postscreen. I'd like to see how many connections are being refused by
> postscreen. What do you like? logwatch? awstats? other?
> 

http://logreporters.sourceforge.net/

I believe logwatch now includes recent copies of these two, but I like
to run them standalone anyway.

Re: Stan Hoeppner's fqrdns.pcre file?

[Michael Orlitzky]

On 04/27/2015 10:57 PM, Alex Regan wrote:
>>
>> check_client_access uses the verified name, which is more conservative.
>> I wasn't convinced this was a good idea, so I played it safe.
> 
> So check_client_access is performing an additional DNS query on the 
> hostname to check if it matches the IP?
> 

Right.


>>> Doesn't this all serve the same purpose as RDNS_DYNAMIC already included
>>> with spamassassin?
>>
>> It does, but RDNS_DYNAMIC matches fewer patterns.
> 
> Are you concerned about duplicate points for effectively the same rule?
> 

A little bit, but not nearly enough to figure out how the two overlap
and do something about it. I've never had a false positive report
involving my GENERIC_RDNS, so it can't be *that* bad. If it ever causes
an issue I'll probably drop the rule entirely.

Re: Stan Hoeppner's fqrdns.pcre file?

[Michael Orlitzky]

On 04/27/2015 06:55 PM, Alex Regan wrote:
> Hi,
> 
>>> I assume that means you use it in header_checks?
>>
>> It's still a client check; I have
>>
>>smtpd_recipient_restrictions =
>>  ...
>>  check_client_access pcre:$maps/generic_rdns.pcre,
> 
> If you're using a version of postfix later than 2.6, you should be using 
> check_reverse_client_hostname_access instead of check_client_access, 
> according to the fqrdns file itself
> 
> Unless there's some other reason/benefit I'm not seeing?
> 

check_client_access uses the verified name, which is more conservative.
I wasn't convinced this was a good idea, so I played it safe.


> Doesn't this all serve the same purpose as RDNS_DYNAMIC already included 
> with spamassassin?

It does, but RDNS_DYNAMIC matches fewer patterns.

Re: Stan Hoeppner's fqrdns.pcre file?

[Michael Orlitzky]

On 04/26/2015 03:55 PM, Wolfgang Zeikat wrote:
> 
> I assume that means you use it in header_checks?
> 

It's still a client check; I have

  smtpd_recipient_restrictions =
...
check_client_access pcre:$maps/generic_rdns.pcre,
...

And then in spamassassin,

  header GENERIC_RDNS exists:X-Generic-RDNS
  score GENERIC_RDNS 1.0
  describe GENERIC_RDNS Reverse DNS looks generic (e.g. residential)

Re: Stan Hoeppner's fqrdns.pcre file?

[Michael Orlitzky]

On 04/26/2015 09:07 AM, Patrick Laimbock wrote:
> 
> I would appreciate it if someone with a recent version of fqrdns.pcre 
> could put it up on github or post it to the mailing list or offline to 
> me or Steve. I found it very useful and would like to continue to use it.
> 

Here's my copy, modified to add a header rather than reject outright. It
should be easy enough to switch back.

Git says it's from 2014-07-04.



generic_rdns.pcre.gz
Description: application/gzip

Re: For Grsec/PaX hardened kernel, GNU gdb debugger issues to be aware of

[Michael Orlitzky]

On 02/23/2015 05:05 PM, miroslav.rov...@zg.ht.hr wrote:
> Hi!
> 
> as you can read in this new bug report that I submitted:
> 
> GNU debugger employed via Postfix crashed PaX hardened kernel
> https://bugs.gentoo.org/show_bug.cgi?id=541104
> 
> also:
> 
> GNU debugger checking for PaX and refusing to work with it
> https://forums.gentoo.org/viewtopic-t-1011162.html
> 
> and:
> 
> PAX terminating task on /usr/bin/gdb
> http://forums.grsecurity.net/viewtopic.php?f=3&t=4137
> 

There's some general info here,

  https://wiki.gentoo.org/wiki/Hardened/Debugging

but it will never be as easy debugging on a hardened system as it is on
a vanilla one.

That said, this particular problem can be traced back to a bug -- one
that will likely be fixed (see the PaX Team's comments on the grsecurity
forum).

Re: PATCH: PIE for Postfix 3.1

[Michael Orlitzky]

On 02/05/2015 09:58 AM, Christian Rößner wrote:
> 
> Sorry, if I correct you (hopefully I am right…)
> 
> This is not a profile I showed, this is the gcc compiler. And it is from the 
> hardened stage tar ball:
> 
> stage3-amd64-hardened-20121210.tar.bz2 (I kept it since install in / ;-) )
> 
> make.profile -> ../../misc/portage/profiles/hardened/linux/amd64/no-multilib/
> 
> The whole system is built hardened.
> 

You are correct, if you start with a hardened stage3 the entire system
is already built hardened. You have a hardened profile, and the (most)
hardened GCC. So everything you've built since the install has been
hardened too (unless the package maintainer had to disable it).

The gcc-config output is a little confusing, but the first one is the
MOST hardened:

 [6] x86_64-pc-linux-gnu-4.8.3 *
 [7] x86_64-pc-linux-gnu-4.8.3-hardenednopie
 [8] x86_64-pc-linux-gnu-4.8.3-hardenednopiessp
 [9] x86_64-pc-linux-gnu-4.8.3-hardenednossp
 [10] x86_64-pc-linux-gnu-4.8.3-vanilla

The others are "hardened, minus something."

[OT] Multiple Targets on transport map

[Michael Orlitzky]

On 06/18/2014 11:07 AM, Jim Reid wrote:
> On 18 Jun 2014, at 15:45, Michael Orlitzky 
> wrote:
> 
>> Nitpick: the ".local" TLD is reserved by RFC 6762, ".invalid" may
>> be a better long-term choice.
> 
> I'll raise you another nitpick. .invalid is reserved by RFC6761 and
> in the IANA registry of Special-Use Domain Names, just like .local:

Indeed, thanks for that. I hadn't seen it before.

The problem that arises is that you must choose a reserved name,
otherwise you may find one day that your made-up name belongs to
somebody else. RFC2606 reserved ".test", ".example", ".invalid" and
".localhost" but didn't specify how they should be handled. Among those,
I interpreted ".invalid" to have the closest meaning to "internal only."

Now, RFC6761 says that resolver libraries SHOULD immediately return a
negative response for ".invalid" queries. So I'm not sure what we're
left with. We have encountered problems with ".local" and Apple gizmos
as you mentioned. And personally I don't think I could stand to see
".test" on the end of a hostname for all eternity. But from RFC6761,
that seems like the best option.

Re: Multiple Targets on transport map

[Michael Orlitzky]

On 06/17/2014 11:58 PM, Jose Borges Ferreira wrote:
> If you wanto to deliver do 1.2.3.4 and , if fails, then try 8.9.10.11
> then you can create a dns entry with those IP an MX
> 
> ex:
> some_entry.local  IN MX 10 1.2.3.4
> some_entry.local  IN MX 20 8.9.10.11
> 
> then setup transport_maps to:
> 
> domain.com   smtp:some_entry.local
> 

Nitpick: the ".local" TLD is reserved by RFC 6762, ".invalid" may be a
better long-term choice.

Re: Regarding DNS lookup

[Michael Orlitzky]

On 04/16/2014 10:14 AM, Kris Deugau wrote:
> 
> "In case some customer changes the MX records away from me, how can I
> automatically stop accepting mail for that domain?"
> 
> About the best you can do is probably a cron job that checks on MX
> records for domains you supposedly host, that can lead to automatically
> disabling domains that suddenly point somewhere other than your mail system.
> 

Shameless plug: http://michael.orlitzky.com/code/haeredes.php

Re: Do not send mails to addresses with more than 3 dots in username part

[Michael Orlitzky]

On 11/22/2013 04:12 AM, Alexander Farber wrote:
> Hello,
> 
> I run a Drupal 7 website on a CentOS 6.4 server
> with postfix-2.6.6-2.2.el6_1.x86_64.
> 
> In the last few months the amount of fake users trying to register at my
> website has increased dramatically - I get 2 or 3 of such registrations
> per minute.
> 

This is one of the safer (i.e. less annoying to humans) things you can do:

  https://drupal.org/project/honeypot

It will add a spam trap field to the form, and refuse form submissions
that come faster than any human could submit them.

Re: Temporarily block domain.tld from sending?

[Michael Orlitzky]

On 10/08/2013 01:44 AM, Stan Hoeppner wrote:
> 
> Understood.  For a more permanent solution to this script problem, you
> may want to consider locking down or disabling the pickup service, and
> configuring all web applications and MUAs to use the submission service
> with auth.  This will prevent such scripts from being able to send mail
> in the event some crafty soul is able to get one uploaded via something
> other than FTP.
> 

Having mail() as the universal interface is nice while you're developing
in PHP, since there's no need to fiddle with the settings when moving
between development and production.

In case of smart hacker / stupid customer, we set,

  sendmail_path = /usr/sbin/sendmail -t -i -f postmas...@example.com

in php.ini so that any attempts at abuse generate bounces to an
administrator (postmaster@) rather than e.g. the From header of the message.

You'll need to override it in certain cases, but it's a safe default. An
additional layer of defense is to set,

  mail.log = syslog

in php.ini and then use the existing syslog notification mechanisms to
alert an admin of anything unusual. Unfortunately this fails in roughly
the same cases that the envelope sender override does: if someone is
running a massive phplist mailing list, they need their bounces (to
remove bad addresses), and I don't want to hear about every message they
send.

Re: ISP has no reverse DNS for ip address

[Michael Orlitzky]

On 09/01/2013 08:47 PM, Roman Gelfand wrote:
> But these emails ultimately do get sent out. It could take a long time.
> To me it sounds odd that they don't know their DNS lookups are screwed
> up. And if they do know, why are they placing such strict constraints
> on incoming mail.

Usually there are two or more ISP servers responsible for your block's
reverse DNS (or for delegating it). I'd make sure they all return the
same thing.

Re: Whitelisting from reverse DNS checks

[Michael Orlitzky]

On 07/19/2013 08:19 AM, L.W. van Braam van Vloten wrote:
> Hello list,
> 
> I have configured postfix to not accept connections from clients that
> fail the reverse dns check.
> But I want to be able to whitelist specific clients, even if the reverse
> hostname check fails.
>  
> To achieve this I configured the following:
> smtpd_client_restrictions =
> check_client_access hash:/etc/postfix/client-whitelist,
> reject_unknown_reverse_client_hostname
>  
> /etc/postfix/client-whitelist contains comment lines (starting with #)
> and entries, like this:
> # mail.acipol.ac.mz
> 197.218.14.50 OK
>  

What you probably want is,

  smtpd_client_restrictions =
check_client_access cidr:/etc/postfix/client_access

and then,

  $ cat /etc/postfix/client_access

  # Legitimate clients without rDNS.
  197.218.14.50 DUNNO

  # Default action
  0.0.0.0/0 reject_unknown_reverse_client_hostname

The first matching entry in /etc/postfix/client_access is what will be
used, so the whitelist entries will hit first. If none of the whitelist
entries are matched, then the default will kick in.

If you ever add more smtpd_client_restrictions, this method avoids
skipping the entire set of tests for hosts which should only be
whitelisted against the reject_unknown_reverse_client_hostname test.

Re: Auth/relaying issues with 2.10.0

[Michael Orlitzky]

On 06/04/2013 08:51 PM, Wietse Venema wrote:
> Please file a bug report with your distribution.
> 
> Postfix 2.10 as distributed by me will add a backwards-compatibility
> setting to main.cf, thusly:
> 
> # postfix upgrade-configuration
>   COMPATIBILITY: editing /etc/postfix/main.cf, overriding
>   smtpd_relay_restrictions to prevent inbound mail from unexpectedly
>   bouncing.  Specify an empty smtpd_relay_restrictions value to
>   keep using smtpd_recipient_restrictions as before.
> 
> And the backwards compatible setting is:
> 
> # postconf smtpd_relay_restrictions
> smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
> defer_unauth_destination
> 
> If your distributor has removed this backwards-compatibility safety
> net, then please tell them that they are doing their users a disservice.
> 
>   Wietse
> 

Postfix 2.10 on Gentoo adds the safety net, but the package manager
won't automatically clobber files under /etc. You're supposed to run a
tool (etc-update) afterwards to merge any changes. I'm guessing that's
what got skipped here.

Possible typo in http://www.postfix.org/workarounds.html

[Michael Orlitzky]

Is this map type (pcre) intended?

  /etc/postfix/main.cf:
smtp_discard_ehlo_keyword_address_maps =
pcre:/etc/postfix/discard_ehlo_keywords

  /etc/postfix/discard_ehlo_keywords:
# This is likely to be incomplete.
216.32.0.0/16 silent-discard, pipelining
213.199.0.0/16 silent-discard, pipelining
65.55.0.0/16  silent-discard pipelining
94.245.0.0/16 silent-discard pipelining

Not that this workaround is needed anymore, but sometimes it's easier to
copy/paste old solutions than think them up anew.

Re: Redirecting and rejecting a sender/recipient pair

[Michael Orlitzky]

On 11/12/12 11:29, Noel Jones wrote:
>>
>> Time to ask for help. Is there a way to make this work with a
>> before-queue amavisd?
> 
> The easy fix is to add a SpamAssassin rule or a clamav signature
> that marks the unwanted mail as spam/virus, and configure
> amavisd-new to quarantine the message.
> 
> Postfix will reject the message (OK, really the proxy filter), you
> keep a copy in the quarantine.
>

Per Wietse's response, I don't think I understand this well enough to do
it in amavis without subtly screwing it up. I've suggested they either
let me reject the messages outright on the MX, or do the filtering later
on, at the final destination (or in their Outlooks).

Thank you both.

Redirecting and rejecting a sender/recipient pair

[Michael Orlitzky]

We have a customer on a shared server who would like to reject mail from
one recipient while retaining a copy for legal purposes.

Last week, before they asked me to reject the guy, they just wanted to
discard the real copy (addressed to a human) and save a copy elsewhere,
for later review.

My first attempt used check_recipient_access with our customer's domain
to give them their own set of restrictions. Within that set, I used
check_sender_access and a REDIRECT action for this one guy. Whoops:

  Nov 12 09:50:25 mx1 postfix/smtpd[16622]: warning: access table
  cdb:/etc/postfix/maps/sender_access: with smtpd_proxy_filter
  specified, action REDIRECT is unavailable

I tried to work around this with two sets of sender_access maps, one
that BCCs and another which rejects. No luck:

  Nov 12 10:11:20 mx1 postfix/smtpd[22174]: warning: unknown smtpd
  restriction: "BCC"

Time to ask for help. Is there a way to make this work with a
before-queue amavisd?



# postconf -n
address_verify_negative_refresh_time = 1h
address_verify_positive_expire_time = 7d
address_verify_positive_refresh_time = 3h
address_verify_sender = postmas...@viabit.com
append_dot_mydomain = no
config_directory = /etc/postfix
default_database_type = cdb
disable_vrfy_command = yes
enable_long_queue_ids = yes
error_notice_recipient = postmas...@viabit.com
example_customer = check_sender_access cdb:$maps/sender_access
fast_flush_domains =
inet_interfaces = 127.0.0.1, 65.246.80.15
inet_protocols = ipv4
local_recipient_maps =
local_transport = error:local mail delivery is disabled.
maps = /etc/postfix/maps
max_idle = 180s
message_size_limit = 1
mydestination =
mydomain = viabit.com
myhostname = mx1.viabit.com
mynetworks_style = host
policyd-spf_time_limit = 3600
postscreen_bare_newline_action = enforce
postscreen_bare_newline_enable = yes
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = psbl.surriel.com*2, bl.spamcop.net*2,
zen.spamhaus.org*2, b.barracudacentral.org*2, bl.spameatingmonkey.net,
spamtrap.trblspam.com, dnsbl.sorbs.net, dnsbl.njabl.org, dnsbl.ahbl.org,
bl.mailspike.net
postscreen_dnsbl_threshold = 2
postscreen_greet_action = enforce
postscreen_non_smtp_command_action = enforce
postscreen_non_smtp_command_enable = yes
postscreen_pipelining_action = enforce
postscreen_pipelining_enable = yes
relay_domains = cdb:$maps/relay_domains,
cdb:$maps/relay_domains-permanent, proxy:pgsql:$maps/relay_domains.pgsql
relay_recipient_maps = cdb:$maps/relay_recipient_maps,
cdb:$maps/relay_recipient_maps-permanent,
proxy:pgsql:$maps/relay_recipient_maps.pgsql
relayhost = mail1.viabit.com
relocated_maps = cdb:$maps/relocated_maps
sendmail_fix_line_endings = strict
show_user_unknown_table_name = no
smtp_discard_ehlo_keywords = dsn
smtp_mx_session_limit = 3
smtp_skip_5xx_greeting = no
smtpd_client_connection_count_limit = 20
smtpd_data_restrictions = reject_unauth_pipelining, permit
smtpd_discard_ehlo_keywords = dsn
smtpd_error_sleep_time = 10
smtpd_hard_error_limit = 5
smtpd_helo_required = yes
smtpd_junk_command_limit = 3
smtpd_proxy_filter = localhost:10024
smtpd_proxy_options = speed_adjust
smtpd_proxy_timeout = 180s
smtpd_recipient_restrictions = reject_unauth_destination,
reject_unlisted_recipient, check_recipient_access
cdb:$maps/recipient_verify_domains, check_recipient_access
cdb:$maps/rfc_addresses, reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname, reject_non_fqdn_sender,
reject_unknown_reverse_client_hostname, reject_unknown_sender_domain,
check_client_access cidr:$maps/generic_rbl_clients.cidr,
check_sender_access cdb:$maps/backscatter_senders, reject_rhsbl_client
dbl.spamhaus.org, reject_rhsbl_helo dbl.spamhaus.org,
reject_rhsbl_sender dbl.spamhaus.org, check_sender_access
pcre:$maps/yahoo_domains.pcre, check_recipient_access
cdb:$maps/recipient_access, check_policy_service
unix:private/policyd-spf, permit
smtpd_restriction_classes = spf_pass_helo, spf_pass_from, example_customer
smtpd_soft_error_limit = 2
smtpd_tls_cert_file = /etc/ssl/mx1.viabit.com/mx1.viabit.com.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database =
btree:/var/lib/postfix/smtpd_tls_session_cache
spf_pass_from = check_sender_access cdb:$maps/domain_blacklist
spf_pass_helo = check_helo_access cdb:$maps/domain_blacklist
strict_rfc821_envelopes = yes
tls_append_default_CA = yes
transport_maps = cdb:$maps/transport_maps,
proxy:pgsql:$maps/transport_maps.pgsql
unknown_address_reject_code = 550
unknown_client_reject_code = 550
unverified_recipient_reject_code = 550
virtual_transport = error:virtual mail delivery is disabled.

Re: Preventing postscreen from logging local connections?

[Michael Orlitzky]

On 08/27/12 11:25, Rich Carreiro wrote:
> 
> I know the real answer is to figure out how to modify the
> relevant logwatch service script and/or to figure out how to get
> mailmain to submit on 587.

Update postfix-logwatch[1], this should already be fixed.


[1] http://logreporters.sourceforge.net/

Re: Minimal permissions on /etc/postfix

[Michael Orlitzky]

On 07/24/2012 07:33 PM, mouss wrote:
> 
> map_directory = /var/db/postmap
> cidr = cidr:${map_directory}/cidr
> db = ${db_type}:${map_directory}/${db_type}
> map_directory = /var/db/postmap
> regex = ${regex_type}:${map_directory}/${regex_type}
> sql = ${sql_type}:${map_directory}/${sql_type}
> ...
> 
> ls -l /var/db/
> ...
> drwxr-x---9 root  postfix   512 Feb 10  2011 postmap/
> ...

Ok, thanks, I'll stick with this for a while and see what happens. It
seems sendmail needs to read main.cf, but not any of the map files (at
least, not the ones I'm using in the way I'm using them) or master.cf.

We've only got two boxes that have anything sensitive in the maps; on
the one with the mail store, I have just:

  /etc/postfix:
cp -R etc/postfix /etc/
chgrp -R postfix /etc/postfix
find /etc/postfix -type d -print0 | xargs -0 chmod 755
find /etc/postfix -type f -print0 | xargs -0 chmod 640
chmod 644 /etc/postfix/main.cf

which is close to what you posted, modulo master.cf and 'rx' of the maps
directory.

On the MX, I also need to make one of the map files readable to the
amavis user, but there's nothing sensitive in that map, so 644 is fine
there.

I'll report if anything else breaks =)

Re: Minimal permissions on /etc/postfix

[Michael Orlitzky]

On 07/24/12 12:24, DTNX Postmaster wrote:
> On Jul 24, 2012, at 18:09, Michael Orlitzky wrote:
> 
>> We store our virtual_foo_maps in,
>>
>>  /etc/posfix/maps/virtual_foo_maps.pgsql
>>
>> and so the (read-only) database credentials are visible in that file.
>> I'd like to tighten this up if possible, but I don't want to do anything
>> stupid.
>>
>> If I'm not going about this all wrong, what can I do to prevent e.g. SSH
>> users from reading the DB credentials? Ideally, I'd also like to prevent
>> them from reading the rest of the maps, which contain lists of
>> addresses, clients, etc.
> 
> This works for us;
> 
> $ ls -ald /etc/postfix 
> drwxr-x--- 5 root postcfg 4096 Jul 24 18:05 /etc/postfix
> 
> The postfix user is a member of the 'postcfg' group. Any admin accounts 
> that need access to the contents can also be added if needs be.
> 

Thanks, I actually tried this but ran into a problem:

  Jul 24 01:45:50 localhost postfix/sendmail[26795]: fatal: open
  /etc/postfix/main.cf: Permission denied

That alone is easy to fix (allow $authorized_submit_users read access to
main.cf), but it suggested that I might run into more subtle problems if
I started messing with /etc/postfix.

Minimal permissions on /etc/postfix

[Michael Orlitzky]

We store our virtual_foo_maps in,

  /etc/posfix/maps/virtual_foo_maps.pgsql

and so the (read-only) database credentials are visible in that file.
I'd like to tighten this up if possible, but I don't want to do anything
stupid.

If I'm not going about this all wrong, what can I do to prevent e.g. SSH
users from reading the DB credentials? Ideally, I'd also like to prevent
them from reading the rest of the maps, which contain lists of
addresses, clients, etc.

Re: Queue file write errors with before-queue amavis

[Michael Orlitzky]

On 07/13/12 13:35, Noel Jones wrote:
> 
> This suggests that 25 is too many.  Rule of thumb -- if you're
> getting timeouts under heavy load, that means you're accepting more
> connections than your box can handle in a timely manner.
> 
>> I'll lower it back to 40 (this is a decent-sized server) to limit the
>> number of variables.
> 
> As a general rule, you can use somewhere between 3 to 10 amavisd-new
> processes per CPU, but you must have enough RAM to support that
> number; there must be no swapping.
> 

Admittedly, I only twiddled that knob because it was the first one I
saw, but I did check that the machine was under very little load at the
time.

I've blocked iContact for now (these messages were all spam, anyway),
but I'll let them through again to see if I can get some real numbers.

Re: Queue file write errors with before-queue amavis

[Michael Orlitzky]

On 07/13/12 12:23, Wietse Venema wrote:
> Michael Orlitzky:
>>   Jul 13 10:40:51 mx1 postfix/smtpd[14918]: warning: timeout talking to
>>   proxy localhost:10024
> 
> Could it be that amavisd is really taking longer than smtpd is
> willing to wait (default: "smtpd_proxy_timeout = 100s")?

The timestamps show that postfix gives up after 100s, but I wasn't sure
if that was during a real conversation (amavis taking too long), or just
waiting for a connection (maybe too few processes).

I can increase the timeouts to 120s or 180s and let it run for a while.

Re: Queue file write errors with before-queue amavis

[Michael Orlitzky]

On 07/13/12 12:22, Noel Jones wrote:
>>
>> $max_servers  = 100;
>> $max_requests = 25;
>> $child_timeout = 180;
>> $smtpd_timeout = 120;
>>
> 
> 
> I suspect 100 smtpd/amavisd processes is way too many for your
> hardware, preventing amavisd from responding before a timeout occurs.
> 
> Reduce smtpd process count and amavisd $max_servers until you stop
> having timeouts.
> 
> Typical values are 3 to 10 times the number of CPUs you have, and
> enough RAM to support them with no swapping.
> 

I should have mentioned this, but the first time this happened, I
assumed it was because we had too few amavis processes. I think I raised
it from 25 -> 50 -> 100 to see if it made any difference (it hasn't).

I'll lower it back to 40 (this is a decent-sized server) to limit the
number of variables.

Queue file write errors with before-queue amavis

[Michael Orlitzky]

We got hit by an iContact run last night and I woke up with several
hundred postmaster messages reporting a queue file write error. We run a
before-queue amavis.

Here are the logs of one of these transactions:

  Jul 13 10:39:10 mx1 postfix/smtpd[14918]: connect from
  drone074.ral.icpbounce.com[216.27.86.131]

  Jul 13 10:39:10 mx1 postfix/smtpd[14918]: discarding EHLO keywords:
  DSN

  Jul 13 10:39:10 mx1 postfix/smtpd[14918]: NOQUEUE:
  client=drone074.ral.icpbounce.com[216.27.86.131]

  Jul 13 10:40:51 mx1 postfix/smtpd[14918]: warning: timeout talking to
  proxy localhost:10024

  Jul 13 10:40:51 mx1 postfix/smtpd[14918]: proxy-reject: END-OF-
  MESSAGE: 451 4.3.0 Error: queue file write error;
  from=
  to= proto=ESMTP
  helo=

  Jul 13 10:40:51 mx1 postfix/smtpd[14918]: disconnect from
  drone074.ral.icpbounce.com[216.27.86.131]

Now, I understand (I think) what happened: amavis was hung up scanning
the other ninety gabillion junk messages that they spammed us with, so
it didn't respond in time. But, I think my configuration should have the
same number of amavis and smtpd processes available so postfix shouldn't
even answer the door if amavis isn't available.

Anything else I should be doing?



#
# master.cf
#

smtp  inet  n   -   n   -   1   postscreen
smtpd pass  -   -   n   -   100 smtpd
dnsblog   unix  -   -   n   -   0   dnsblog
tlsproxy  unix  -   -   n   -   0   tlsproxy
pickupfifo  n   -   n   60  1   pickup
cleanup   unix  n   -   n   -   0   cleanup
qmgr  fifo  n   -   n   300 1   qmgr
tlsmgrunix  -   -   n   1000?   1   tlsmgr
rewrite   unix  -   -   n   -   -   trivial-rewrite
bounceunix  -   -   n   -   0   bounce
defer unix  -   -   n   -   0   bounce
trace unix  -   -   n   -   0   bounce
verifyunix  -   -   n   -   1   verify
flush unix  n   -   n   1000?   0   flush
proxymap  unix  -   -   n   -   -   proxymap
smtp  unix  -   -   n   -   -   smtp
relay unix  -   -   n   -   -   smtp
-o fallback_relay=
showq unix  n   -   n   -   -   showq
error unix  -   -   n   -   -   error
retry unix  -   -   n   -   -   error
discard   unix  -   -   n   -   -   discard

anvil unix  -   -   n   -   1   anvil
scacheunix  -   -   n   -   1   scache

127.0.0.1:10025 inetn   -   n   -   -   smtpd
-o smtpd_proxy_filter=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o smtpd_restriction_classes=
-o mynetworks=127.0.0.0/8
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
-o local_header_rewrite_clients=

policyd-spf  unix  -   n   n   -   0   spawn
 user=policyd-spf argv=/usr/bin/policyd-spf

proxywrite unix -   -   n   -   1   proxymap





#
# postconf -n
#

address_verify_positive_expire_time = 7d
address_verify_positive_refresh_time = 3h
address_verify_sender = postmas...@viabit.com
append_dot_mydomain = no
config_directory = /etc/postfix
default_database_type = cdb
disable_vrfy_command = yes
error_notice_recipient = postmas...@viabit.com
fast_flush_domains =
inet_interfaces = 127.0.0.1, 65.246.80.15
local_recipient_maps =
local_transport = error:local mail delivery is disabled.
message_size_limit = 1
mydestination =
mydomain = viabit.com
myhostname = mx1.viabit.com
mynetworks_style = host
postscreen_bare_newline_action = enforce
postscreen_bare_newline_enable = yes
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = psbl.surriel.com*2,bl.spamcop.net*2,
 zen.spamhaus.org*2,b.barracudacentral.org*2,
bl.spameatingmonkey.net,spamtrap.trblspam.com,  dnsbl.sorbs.net,
dnsbl.njabl.org,dnsbl.ahbl.org, bl.mailspike.net
postscreen_dnsbl_threshold = 2
postscreen_greet_action = enforce
postscreen_non_smtp_command_action = enforce
postscreen_non_smtp_command_enable = yes
postscreen_pipelining_action = enforce
postscreen_pipelining_enable = yes
relay_domains = cdb:/etc/postfix/maps/relay_domains,
c

Re: Stress docs update

[Michael Orlitzky]

On 05/03/12 05:14, Rob Sterenborg wrote:
>>
>>   Credits 
> 
> According to the POSTSCREEN_README, postscreen doesn't do greylisting at
> all: postscreen and greylisting are different things. The below is your
> patch adapted with a partial copy-paste from the POSTSCREEN_README.
> 

When a client passes the deep protocol tests, postscreen sends it a 4xx;
that's essentially greylisting. But, there's no need to mention that on
STRESS_README: it can be inferred from POSTSCREEN_README.

Re: postgrey vs postscreen

[Michael Orlitzky]

On 05/01/2012 03:42 PM, Postfix Support Mail wrote:
> Sorry about that. 
> 
> Reading the postscreen readme is what spawned the question.
> 

If you enable the deep protocol tests, postscreen works pretty much like
greylisting since it will 4xx any client that passes. When they
reconnect, they skip postscreen entirely; in effect, they've passed
greylisting.

Postgrey is a little more configurable (re: greylisting), and its
introduction is less intrusive than switching will be. If you have to
support older versions of postfix (sans postscreen), it also allows you
to consolidate your configurations.

On the other hand, I trust the postscreen code to be of the same
quality as the rest of postfix. Postscreen does provide some additional
anti-spam measures and reduces the load on your system. Finally, when
all's  said and done, you've got one less[1] moving part to worry about.

Perhaps my favorite benefit is that with postscreen, we can afford the
resources to use a pre-queue content filter. Now senders get a rejection
if we e.g. detect a virus in their message. This greatly reduces the
amount of time I have to spend on the phone.

I would recommend switching eventually.


[1] Technically there are probably more, but let's say "logical" moving
parts.

Stress docs update

[Michael Orlitzky]

At the bottom of the stress readme,

  http://www.postfix.org/STRESS_README.html#other

there is an allusion to what would eventually become postscreen. Might
as well update it with a sentence and a link to POSTSCREEN_README.html?

Re: Running Postfix on a hosted service?

[Michael Orlitzky]

On 04/06/2012 12:53 PM, vr wrote:
> I'm exploring moving my small, non-SQL Postfix installation from a SOHO 
> type server to an ISP... Cloud... or whatever marketing term you fancy.
> 
> I ask here because my own personal experience with Web companies has 
> been dismal when trying to send legitimate email from forum topics or 
> end-user subscriptions due to blacklisting, etc. My searches in the 
> archives and on the web turn up few Postfix-centric results. Ideally I 
> would like to find something in the Chicago U.S. area but would consider 
> others.
> 
> I'm looking personal experience, off list is OK too, as to a provider 
> that's been more favorable for a Postfix deployment?

Most important is probably to make sure that you get your own IP address
at the hosting company. Mistakes happen and you don't want to get
blacklisted because someone's old PHP forum is compromised on your
shared host.

Second-most important would be to find an ISP who doesn't tolerate spam
and has a responsive abuse department. Try to contact the abuse
department -- does your message go to a real person, or is it
automatically printed out and fed into a shredder?

Most of the big blacklists only list /32s, so you'll be fine if you have
your own IP address. Smaller guys block /24 and up, but I myself won't
block anyone who acts on complaints.

Re: New default settings for "submission" service?

[Michael Orlitzky]

On 03/14/2012 04:03 PM, Patrick Ben Koetter wrote:

* Charles Marcus:

On 2012-03-14 2:39 PM, Ed W  wrote:

I see no reason to *require* encryption on the submission port (RFC
aside).


Unless you prefer that sniffers not be able to see your passwords
crossing the wire in plaintext?


I think "may" is a more appropriate default?


Disagree vehemently.


The RFC on submission is clear about that. It says SHOULD and not MUST. It is
safe to AUTH if you use cram-md5, digest-md5, ntlm or any other non-plaintext
mechanism. Forcing TLS by default is safer, but it pushes a policy on people
the SHOULD decide themselves, I think.


I agree with Charles: the defaults should be as safe as possible, but 
adjustable in the rare case that the administrator has some idea what 
he's doing.

[OT] Re: found a "bug" on postfix 2.9.1

[Michael Orlitzky]

On 03/06/12 14:10, Wietse Venema wrote:
> Eray Aslan:
>> On Tue, Mar 06, 2012 at 11:48:35AM -0500, Wietse Venema wrote:
>>> I think that making everyone wait would be another example of
>>> well-meaning people doing things that give Postfix a bad reputation.
>>
>> postfix start exits successfully but postfix doesn't work, resulting in a
>> WTF moment for the user.  I am not sure if this is a recommended way to
>> start a daemon.  It surprises them - hence the original email.
> 
> According to the original complaint, no error was logged, and the
> system claimed that the mail system was running.
> 
> If they had looked in the right logfile, and if they had used the
> "postfix status" command, all this WTF would have been unnecessary.
> 
> They also claimed they had to to reboot their system to clear up
> the problem.
> 
> All this indicates that they have no clue. Going for the lowest
> common denominator is not sufficient moditivation to make changes
> that cause everyone else to suffer.

It's not really his fault. This is what the startup message looks like:

  backup2 ~ # /etc/init.d/postfix start
   * Starting postfix (/etc/postfix)...  [ ok ]

If postfix has failed to actually start, you get the same message. Moreover,

  backup2 ~ # killall -9 /usr/lib64/postfix/master
  backup2 ~ # /etc/init.d/postfix start
   * WARNING: postfix has already been started
  backup2 ~ # /etc/init.d/postfix status
   * status: started

This is not ideal, but I wouldn't say it should necessarily be fixed,
either. Right now the problem is easy to understand: half of the time on
Gentoo, the startup "OK" is meaningless. Everyone knows this, and
figures out how to deal with it quickly:

  backup2 ~ # /etc/init.d/postfix stop
   * Stopping postfix (/etc/postfix)...  [ !! ]
   * ERROR: postfix failed to stop
  backup2 ~ # /etc/init.d/postfix zap
   * Manually resetting postfix to stopped state
  backup2 ~ # /etc/init.d/postfix start
   * Starting postfix (/etc/postfix)...  [ ok ]

If we try to fix it with magic (e.g. wrapping 'postfix status'),

  a) We require more developer time
  b) Some easy failure modes get nicer
  c) Many tricky failures get worse

So the benefit is not clear-cut.

Re: forcing MX lookups

[Michael Orlitzky]

On 02/16/2012 12:13 PM, Dipl.-Ing. Juergen Ladstaetter wrote:


yet. Is there any way to configure postfix to always make MX record DNS
lookups, or is the only way through a second postfix instance that has no
localdomains specified?


Even with two instances you could have problems.

For example, your users might have aliases that get expanded on the 
incoming instance, where the maps are controlled by customers. If one of 
your customers sets up example.com, and has u...@example.com aliased to 
u...@example.net hosted elsewhere, they could be open to another 
customer stealing the example.net mail.


One instance per customer is /probably/ safe, but I wouldn't swear to it 
without some more thought.

Re: Dual instance problem with mysql

[Michael Orlitzky]

On 02/03/12 03:24, Laurent RAYSSIGUIER wrote:
> 
> I need to have a postfix relay which is able to separate customers
> who have an antispam service provided by another company, and the
> other who don't have antispam service.
> 

We do something similar. We have two final mailbox destinations at the
moment (mail1 and mail2), so we set the default relay to mail1, and
override for those recipients on mail2.

The recipients on mail1 are provided by an import/export routine.
Everything on mail2 is stored in a postgres database.


  # Default, overridden for accounts on mail2.
  relayhost = mail1.example.com


  # relay_domains are imported from mail1
  #
  # relay_domains-permanent are entries I don't want to be clobbered
  # by the import routine.
  #
  # The postgres map checks for the existence of a domain on mail2.
  # If a domain exists, it's a relay domain.
  relay_domains =
cdb:/etc/postfix/maps/relay_domains,
cdb:/etc/postfix/maps/relay_domains-permanent,
proxy:pgsql:/etc/postfix/maps/relay_domains.pgsql


  # Works exactly the same as relay_domains.
  relay_recipient_maps =
cdb:/etc/postfix/maps/relay_recipient_maps,
cdb:/etc/postfix/maps/relay_recipient_maps-permanent,
proxy:pgsql:/etc/postfix/maps/relay_recipient_maps.pgsql


  # The postgres map checks to see if a domain exists on mail2.
  # If it does, we relay it to mail2 instead of the default.
  #
  # The text file contains special stuff, manually entered.
  transport_maps =
cdb:/etc/postfix/maps/transport_maps,
proxy:pgsql:/etc/postfix/maps/transport_maps.pgsql

Re: Switching to 587 submission

[Michael Orlitzky]

On 12/08/2011 05:18 PM, Grant wrote:


I've boiled my config down to this.  It is functional and I think it
is secure and that it rejects any attempt to send messages from
outside mynetworks unless authenticated.  Am I correct?  Please
consider all other directives to be default.


You're fine.

If you want to be better than fine, you can implement Noel's suggestion: 
it forces STARTTLS and auth only when the client is not localhost. Since 
SquirrelMail is localhost, it can send without STARTTLS/auth.


The result is that all of your outgoing mail can arrive on 587, which is 
nice when you have a lot of different restrictions for incoming/outgoing 
mail.

Re: Switching to 587 submission

[Michael Orlitzky]

On 12/08/2011 03:24 PM, Grant wrote:


So I should specify smtpd_client_restrictions or
smtpd_recipient_restrictions, but not both?



I think most people find it easier to put all of the restrictions under 
smtpd_recipient_restrictions, since you can just read them top-to-bottom 
with smtpd_delay_reject = yes (the default).


But no, you probably wouldn't need it in both places unless you had some 
default restrictions you wanted to override in both places.




Squirrelmail and postfix are on the same machine.  I've changed
Squirrelmail to send to port 25 with no authentication and no TLS and
it works!  It must have been failing before because it was trying to
authenticate?

So this is working because Squirrelmail is part of $mynetworks
(localhost) and there are no security implications or any need to
enable authentication or TLS as long as Squirrelmail remains on the
same machine as postfix?  That's a nice way around the Squirrelmail
STARTTLS problem.


It's a lot simpler with SquirrelMail on the same machine. Your localhost 
should be in $mynetworks, so it can send on port 25 thanks to 
permit_mynetworks.


There's no need to encrypt anything, since the traffic travels over the 
loopback interface.

Re: Switching to 587 submission

[Michael Orlitzky]

On 12/08/2011 02:21 PM, Gary Smith wrote:


Wouldn't it be smarter to just tell SquirrelMail to use port 587 and
pass through authentication?  This way if the server is compromised
or has another exploit there isn't a simple internal email server to
send all that spam from.

This is exactly what we do for both horde and roundcube.



That was my first suggestion, but the stable version of SquirrelMail 
(and the one supplied by Gentoo) doesn't support STARTTLS.

Re: Switching to 587 submission

[Michael Orlitzky]

On 12/08/2011 11:24 AM, Grant wrote:


You don't really need the permit_sasl_authenticated, since you shouldn't be
trying to auth on port 25. It doesn't hurt, though.


I just noticed that I can't send mail from Thunderbird unless I
include permit_sasl_authenticated in the above
smtpd_recipient_restrictions block.  I get relay access denied
otherwise.


Oh, sorry. You have this in master.cf:


submission inet n   -   n   -   -   smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject


The -o smtpd_foo_restrictions here is supposed to override the 
restrictions in main.cf:



smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination,
permit


So you should change 'client' to 'recipient' in master.cf before you 
remove the 'permit_sasl_authenticated' in main.cf.


At that point, SquirrelMail (or anything else) won't be able to send 
mail unless it authenticates on port 587, sends to one of your domains 
on port 25, or is in $mynetworks and sends on port 25.


The path of least resistance is probably to add the SquirrelMail box to 
$mynetworks, and have it send to port 25. If someone can gain control of 
the SquirrelMail box, you're screwed mail-wise anyway, so I don't think 
you lose any security that way.


The alternative that you had working was letting SquirrelMail auth in 
plain text on port 25, which is, should someone compromise the 
SquirrelMail box, not going to save you.

Re: Switching to 587 submission

[Michael Orlitzky]

On 12/07/2011 10:13 PM, Grant wrote:

You've probably got permit_mynetworks near the top of your
smtpd_foo_restrictions, which are inherited by default. The "-o


The only smtpd_foo_restrictions I have in main.cf are:

smtpd_recipient_restrictions =
 permit_sasl_authenticated,
 permit_mynetworks,
 reject_unauth_destination,
 permit


You don't really need the permit_sasl_authenticated, since you shouldn't 
be trying to auth on port 25. It doesn't hurt, though.




smtpd_client_restrictions" line would have overridden that (if it was a
client restriction) and forced your users to authenticate.


I'm now running submission like this:

submission inet n   -   n   -   -   smtpd
   -o smtpd_tls_security_level=encrypt
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_client_restrictions=permit_sasl_authenticated,reject


Looks good.




SASL must be working since Thunderbird can send mail over 587,
correct?


Right.



I don't see why local Squirrelmail won't send mail over 587,
but remote Thunderbird will.  Squirrelmail also won't send mail over
port 25, but it will send mail over 465.


Do you have a new-enough SquirrelMail? From the looks of it, the only 
version >= 1.5.1 is the development snapshot. (Do you know about Roundcube?)

Re: Switching to 587 submission

[Michael Orlitzky]

On 12/07/2011 09:10 PM, Grant wrote:


I'm trying to figure out why I can't connect to 587 in Squirrelmail.
I can in Thunderbird.



You did select STARTTLS in the SquirrelMail config, right? The postfix 
logs might give you an idea what it's trying to do.


The docs say that you need PHP with the stream_socket_enable_crypto() 
function. If you're like me, you may have casually disabled some 
critical PHP feature via USE flags =)


If you have that function, this page will complain that the function 
expects 2 parameters and was given zero:


$ cat test.php


$ php test.php
PHP Warning:  stream_socket_enable_crypto() expects at least 2 
parameters, 0 given in /home/mjo/test.php on line 1


Warning: stream_socket_enable_crypto() expects at least 2 parameters, 0 
given in /home/mjo/test.php on line 1

Re: Switching to 587 submission

[Michael Orlitzky]

On 12/07/2011 09:48 PM, /dev/rob0 wrote:

On Wednesday 07 December 2011 19:58:18 Michael Orlitzky wrote:

On 12/07/2011 08:09 PM, Grant wrote:

Is IMAP over SSL on 993 deprecated in favor of using STARTTLS on
143?


Nope. I personally prefer the dedicated port for POP3/IMAP.


Preferences aside, the fact remains that SSL has been deprecated by
TLS. STARTTLS is the new standard.


For POP3 and IMAP? By whom?

Re: Switching to 587 submission

[Michael Orlitzky]

On 12/07/2011 07:49 PM, Grant wrote:

I've been using smtps on port 465 for sending mail but I read it's
deprecated so I'm trying to switch to submission port 587.

With 465 I was using the "Connection security: SSL/TLS" setting in
Thunderbird, but after switching to 587 I can't send mail unless I
change it to STARTTLS.  Can anyone explain this?  Should I be using
STARTTLS instead of SSL/TLS for courier 993?


All of the "secure connection" types are rather loosely defined in mail 
clients. The dovecot wiki has a decent, although still (necessarily) 
confusing explanation:


  http://wiki2.dovecot.org/SSL

In Thunderbird's case, "STARTTLS" means "connect first, and then 
negotiate TLS via the STARTTLS command," which is now the way to do 
things even if you're going to require everyone to use TLS.




Whether using 465 or 587, I noticed I can't log in to send mail from
my mail clients unless the password is sent unencrypted.  Is that OK
since I'm using STARTTLS or should I also enable encryption of the
password?


That's fine, the entire connection is encrypted.



Previously in master.cf I was running smtps like this:

smtps inet  n   -   n   -   -   smtpd
   -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

Should I enable all of this for submission:

submission inet n   -   n   -   -   smtpd
   -o smtpd_tls_security_level=encrypt
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
   -o milter_macro_daemon_name=ORIGINATING

I don't think I need milter_macro_daemon_name since I'm not using a
mail filter.  I am running saslauthd but it looks like I didn't have
it enabled for smtps previously.  I'm surprised because I thought I
required authentication in order to use smtps.



You've probably got permit_mynetworks near the top of your 
smtpd_foo_restrictions, which are inherited by default. The "-o 
smtpd_client_restrictions" line would have overridden that (if it was a 
client restriction) and forced your users to authenticate.


The same thing would work for the submission port after the switch, but 
you should first check that your SASL is really working since it wasn't 
being exercised.

Re: Switching to 587 submission

[Michael Orlitzky]

On 12/07/2011 08:09 PM, Grant wrote:


Is IMAP over SSL on 993 deprecated in favor of using STARTTLS on 143?


Nope. I personally prefer the dedicated port for POP3/IMAP.



I just read that Squirrelmail doesn't support STARTTLS, so I must
continue to use smtps 465 in order to use Squirrelmail?


I think it should work. From 
http://squirrelmail.org/docs/admin/admin-5.html,


  SquirrelMail is able to connect to IMAP and SMTP servers that use
  TLS. Since 1.5.1 version SquirrelMail is able to connect to IMAP and
  SMTP servers that use STARTTLS (which is different from TLS).

Re: Catching emails with date in the past

[Michael Orlitzky]

On 09/29/11 20:38, James Lay wrote:
> Hey All!
> 
> Topic says it….I consistently get email from one source that has the
> date in the paste….say almost a month.  Is there functionality within
> Postfix to deal with these, or should I work on a daily script that will
> modify my head_checks file or something like that?  Thank you.
>

If they're spam and you want to block them, use SpamAssassin.

If it's legitimate mail, tell the sender to fix his clock.

In either case, you should probably configure your mail client to ignore
the "Date" header in favor of the time the message was received.

Re: possible compromised system

[Michael Orlitzky]

On 07/27/11 17:41, Reindl Harald wrote:
> 
> 
> Am 27.07.2011 23:22, schrieb Wietse Venema:
>>
>> Is this machine running a webserver? Look in the access logs
> 
> if this is the reason consider disable smtp on 127.0.0.1
> because most of dumb injected scripts are trying this instead
> the network address!
> 
> disable php's mail()-function and every function
> which can excecute shell commands is mandatory
> (shell_exec, exec, popen...)

You can't really disable mail() on a web host, but PHP recently made it
not-impossible to monitor its use:

  http://www.php.net/manual/en/mail.configuration.php#ini.mail.log

Re: With soft_bounce set to no, we are seeing a lot of send failures that look like they should be permanent 554's being handled as temporary.

[Michael Orlitzky]

On 07/19/2011 09:39 PM, Wietse Venema wrote:
>>
>> I think it would be useful to maintain a list of the parameters with
>> non-standard default values. I for one still notice and fix things like
>> this every few months.
>>
>> I'd be willing to look through the main.cf documentation for settings
>> labeled as such if it's for the greater good, but probably not just for
>> my own benefit.
> 
> A web page for 100% compliance expectations (passive) or for 100%
> compliance enforcement expectations (active)?
> 
>   Wietse

I think the first, but I'm not too clear on the distinction. I want my
systems to act compliant where it makes sense, and allow only as much
non-compliant behavior as is necessary from other hosts. But, I was only
referring to the settings that make my own machines behave incorrectly.

An easy example:

  * resolve_dequoted_address (default: yes)

Resolve a recipient address safely instead of correctly, by looking
inside quotes.
...

And a trickier one:

  * smtp_dns_resolver_options = res_defnames, in postfix <= 2.8

Append the current domain name to single-component names (those
that do not contain a "." character). This can produce incorrect
results, and is the hard-coded behavior prior to Postfix 2.8.

Re: With soft_bounce set to no, we are seeing a lot of send failures that look like they should be permanent 554's being handled as temporary.

[Michael Orlitzky]

On 07/19/2011 05:44 PM, Wietse Venema wrote:
> 
> smtp_skip_5xx_greeting (default: yes)
>Skip  SMTP  servers  that greet with a 5XX status code (go away, do not
>try again later).
> 
>By default, the Postfix SMTP client moves on the next  mail  exchanger.
>Specify "smtp_skip_5xx_greeting = no" if Postfix should bounce the mail
>immediately. The default setting is incorrect, but it is what a lot  of
>people expect to happen.
> 
> 
>   Wietse

I think it would be useful to maintain a list of the parameters with
non-standard default values. I for one still notice and fix things like
this every few months.

I'd be willing to look through the main.cf documentation for settings
labeled as such if it's for the greater good, but probably not just for
my own benefit.

Re: Anyone solely using SMTP Auth for outbound mail?

[Michael Orlitzky]

On 07/18/2011 06:35 PM, mouss wrote:
> Le 18/07/2011 19:40, Søren Schrøder a écrit :
>> I'm doing a 1.5M accounts setup with smtp-auth (submission tcp/587 using
>> postfix with dovecot-auth) and a plain smtp/25 for an allowed range of IP's
>> for our fixed IP customers
>>
>> The backend is openldap/postfix/dovecot
>>
>>
> 
> are you a (relatively) large ISP? if so, how did you move to the
> submission part? I am not asking about the tech part, but about the
> customer relationship part. your experience may be helpful to others.
>

Whenever you get a support call, mention that you have a new, faster,
server with more space and you're willing to upgrade them for free; all
they'll have to do is change a few settings.

Re: Date: header - Received instead of sent?

[Michael Orlitzky]

On 07/18/11 17:38, Pablo Chamorro wrote:
> Could somebody please tell me if it's possible to setup Postfix in
> order to make the reception date is shown instead of the
> email-messages sent-date?

Postfix doesn't show the date, your email client does. In Thunderbird, I
just right-click the little column header, uncheck "Date," and check
"Received."

It will probably be different in other clients, but still possible.

If it's *not* possible for some reason, you may still be able to strip
the date header and have it replaced upon receipt, but I won't speak to
the feasibility or advisability of that.

Re: Blocking mail supposedly from my domain

[Michael Orlitzky]

On 05/08/2011 01:01 AM, Dennis Carr wrote:
> On Sat, 7 May 2011, Michael Orlitzky wrote:
> 
>> If he wants to reject hosts that HELO as his own, he can check his own
>> SPF record, and reject anything that softfails.
> 
> ...spf does that?
> 
> -Dennis
> 

Yeah, it can. You can set your local policy to whatever you want.

*If* it's already configured and you're going to create the records
anyway, you might as well use that information rather than duplicate it
in the MTA.

If you're not already checking records though, you're probably better
off just creating the access map for now.

Re: Blocking mail supposedly from my domain

[Michael Orlitzky]

On 05/07/2011 06:31 PM, Duane Hill wrote:
> Saturday, May 7, 2011, 4:34:03 PM, you wrote:
> 
>> On 05/07/2011 01:13 PM, Dennis Carr wrote:
>>> Over the past couple days I'm noticing mail coming in from outside that is 
>>> supposedly from users of mine - but apparently isn't.  HELO message comes 
>>> from chez-vrolet.net which is in my $mynetworks setting, but the IP 
>>> address for the incoming machine does not match DNS.
>>>
>>> What adjustment in main.cf should I look at?  On the surface, 
>>> permit_mynetworks in strategic locations can be eliminated, but last time 
>>> I did that, I couldn't send mail from localhost.
>>>
>>> -Dennis
>>>
> 
>> $ dig +short chez-vrolet.net txt
>> "v=spf1 ip4:206.225.171.23 a mx  ~all"
> 
>> The merits of SPF aside, this is like, what it was designed for. Why
>> don't you check your own record?
> 
> What does that prove?
> 
> Depending upon your local policies:
> '~all' merits a possibility for a reject. '-all' merits a reject.
> 
> I don't use SPF here.
> 
> I assume the OP was looking for a way to reject HELO/EHLO from hosts
> making connections falsifying domains on the OP's server.

If he wants to reject hosts that HELO as his own, he can check his own
SPF record, and reject anything that softfails.

Re: Blocking mail supposedly from my domain

[Michael Orlitzky]

On 05/07/2011 01:13 PM, Dennis Carr wrote:
> Over the past couple days I'm noticing mail coming in from outside that is 
> supposedly from users of mine - but apparently isn't.  HELO message comes 
> from chez-vrolet.net which is in my $mynetworks setting, but the IP 
> address for the incoming machine does not match DNS.
> 
> What adjustment in main.cf should I look at?  On the surface, 
> permit_mynetworks in strategic locations can be eliminated, but last time 
> I did that, I couldn't send mail from localhost.
> 
> -Dennis
> 

$ dig +short chez-vrolet.net txt
"v=spf1 ip4:206.225.171.23 a mx  ~all"

The merits of SPF aside, this is like, what it was designed for. Why
don't you check your own record?

Re: postgrey vs targrey

[Michael Orlitzky]

On 04/28/2011 07:45 PM, Troy Piggins wrote:
> Might not be the right place to post this, so just let me know to
> move on if so...
> 
> I've been using the wonderful postgrey on my server and it seems to
> do a wonderful job of cutting down spam.  I am now curious about the
> targrey patch and whether it would be worthwhile addition, or do you
> find that just postgrey alone is sufficient?  What would it catch
> that postgrey doesn't?
> 

My brain would need an upgrade to understand that website. What does
targrey do exactly?

If your definition of tarpit is the same as mine, then fail2ban works
much easier.

Re: Re-write Received Header to Exclude Home Dynamic IP?

[Michael Orlitzky]

On 04/27/2011 10:27 PM, Michael Orlitzky wrote:
> 
> There is a setting on some Barracuda appliances called "deep header
> inspection" or "deep header parsing" that does this. Nobody who
> understood it would ever turn it on. Nevertheless, it sounds good,
> right? If you put the box there, somebody will check it.

I should clarify a little: the setting itself doesn't do anything bad.
However, when combined with certain blacklists (Barracuda's, the
PBL...), that setting essentially means "reject anything sent from a house."

>From what I understand, the appliance makes it a little too easy to
create this situation.

Re: Re-write Received Header to Exclude Home Dynamic IP?

[Michael Orlitzky]

On 04/27/2011 10:16 PM, Michael B Allen wrote:
> Hi,
> 
> When I send email from home through my Postfix server my home dynamic
> IP is included in the Received header:
> 
>   Received: from nano.foo.net
> (pool-98-190-153-84.nwrknj.fios.verizon.net [98.190.153.84])
> (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
> (No client certificate requested)
> (Authenticated sender: whomever)
> by mail.ioplex.com (Postfix) with ESMTP id 13CC658010;
> Wed, 27 Apr 2011 20:25:20 -0400 (EDT)
> 
> Someone actually just outright rejected a message because of this.
> Meaning even though the message was sent from a squeaky clean fixed IP
> server on the Internet (mail.ioplex.com), their filter walked back
> through the Received hosts and totally rejected the message because it
> originated from a dynamic IP.
> 
> Is there any way to configure my mail.ioplex.com postfix install to
> leave out this part of the Received header or rewrite it so that it
> looks like the message is simply coming from mail.ioplex.com such as
> if I used webmail?
> 
> Also, how common is this level of filtering? It seems excessive to me
> but I have to wonder how much of my emails sent from home are ending
> up at the very least flagged as SPAM.
> 
> Mike

There is a setting on some Barracuda appliances called "deep header
inspection" or "deep header parsing" that does this. Nobody who
understood it would ever turn it on. Nevertheless, it sounds good,
right? If you put the box there, somebody will check it.

Re: Postmaster Account Getting Spam

[Michael Orlitzky]

On 04/18/11 10:07, Carlos Mennens wrote:
> My  default account is getting hammered with spam. I've
> got SA / Amavisd-new working and tagging the messages as ***spam***
> however I've just re-configured SA to be a little more aggressive on
> scoring the messages. My question to the Postfix group is if I can
> configure a restriction in /etc/postfix directory to prevent repeat
> offenders from sending email to me. Someone a few years ago on this
> mailing list assisted me on configuring Postfix to use a
> 'client_access' & 'client_access.db' file to block IP's as shown
> below:
> 
> 95.98.160.248  REJECT
> 190.64.194.12  REJECT
> 
> I've noticed that I am now getting spam emails from several different
> hosts on one single network rather than from a particular host. Can I
> block the entire network as follows:
> 
> 95.98.*REJECT
> 
> I'm sure many on the list wouldn't do this on their personal mail
> server but I'm looking for a simple method that will stop the junk
> mail. I know the 'client_access' flat file works fine but it's very
> tedious to continuously add several IP's from the same network in when
> I can simply blanket the entire network. If legit mail is blocked due
> to this, I can review the rule at that time and see if it's safe to
> lift the block or white-list that one particular client I.P.

If you prevent anyone on that network from sending to postmaster, how
are they going to let you know that there's a false positive?

Re: How to manage 2 banners/greetings through postscreen, content filter, and after-filter SMTP on 1 server?

[Michael Orlitzky]

On 04/11/11 15:29, Rod Dorman wrote:
> On Monday, April 11, 2011, 14:02:37, jeremy.als...@imap-mail.com wrote:
>>   ...
>> There's no wisdom here, just what I've been told -- use a minimum of 2.
>> All of the examples that I see have at least two MX records.
>> One of the fellas at the user group who told us about PostFix wast
>> talking about best -practices and put up a slide about this
>> Symantec Brightmail Gateway (SBG) - Best Practices: New Deployments.
>> http://www.symantec.com/business/support/index?page=content&id=TECH122730&key=53991&actp=LIST
>> that says " You must have at least two MX records and then proper A and
>> PTR record for each host that will handle email."
> 
> The  intent  behind  this  suggestion  is redundancy so when one is down
> because  of  hardware/network  issues  or  you're performing maintenance
> there will be another box that can accept the mail.
> 
> If you only have one physical box you've severely limited that concept.
> 

Our one MX can never be "down," only "interactive greylisting."

Re: How to manage 2 banners/greetings through postscreen, content filter, and after-filter SMTP on 1 server?

[Michael Orlitzky]

On 04/11/11 14:02, jeremy.als...@imap-mail.com wrote:
> Hi Michael
> 
> On Mon, 11 Apr 2011 13:41 -0400, "Michael Orlitzky"
>  wrote:
>> On 04/11/11 12:49, jeremy.als...@imap-mail.com wrote:
>>>
>>> I learned that we really should have both a primary and a backup MX
>>> assigned, and that they should be different IPs.
>>>
>>
>> I'm going question this wisdom with the hope that it might save you some
>> pain. Why would it be better to have two MXes, especially if they're the
>> same box?
> 
> There's no wisdom here, just what I've been told -- use a minimum of 2.
> 
> All of the examples that I see have at least two MX records.
> 
> One of the fellas at the user group who told us about PostFix wast
> talking about best -practices and put up a slide about this
> 
> Symantec Brightmail Gateway (SBG) - Best Practices: New Deployments.
> http://www.symantec.com/business/support/index?page=content&id=TECH122730&key=53991&actp=LIST
> 
> that says " You must have at least two MX records and then proper A and
> PTR record for each host that will handle email."
> 
> If that's wrong, then like you said that saves me some pain.
> 
> Now that you mentioned it, I'm just looking at the SMTP RFC I found to
> see if it says anything about it.

Unless anyone here would like to contradict me, ignore all that and just
use one.

The SBG document doesn't provide any rationale for me to argue against,
but I can't think of any reason why two would be better than one if they
both point to the same place.

Re: How to manage 2 banners/greetings through postscreen, content filter, and after-filter SMTP on 1 server?

[Michael Orlitzky]

On 04/11/11 12:49, jeremy.als...@imap-mail.com wrote:
> 
> I learned that we really should have both a primary and a backup MX
> assigned, and that they should be different IPs.
> 

I'm going question this wisdom with the hope that it might save you some
pain. Why would it be better to have two MXes, especially if they're the
same box?

Re: Local delivery & Mailman

[Michael Orlitzky]

On 01/31/11 14:49, /dev/rob0 wrote:
> On Fri, Jan 28, 2011 at 05:34:20PM -0500, Michael Orlitzky wrote:
>> On 01/28/2011 03:28 PM, Ralf Hildebrandt wrote:
>>> * Michael Orlitzky :
>>>
>>>> I tried with transport_maps:
>>>>
>>>>   example.com  local:
>>>>
>>>> and local_transport = error:... and got this (http3.viabit.com 
>>>> is myorigin):
>>>>
>>>>   Jan 28 15:05:25 http3 postfix/error[20737]: 24944A302DF:
>>>>   to=, orig_to=,
> ---
> 
> This domain, your $myorigin, is the transport used, not the one you 
> have set for example.com.
> 
> Do not use unqualified addresses as lookup results unless you are 
> certain where they are going. Apparently mydestination includes 
> $myorigin, and your virtual_alias_maps rewrote memb...@example.com to 
> "members". With example.com in transport_maps, leave it alone.
> 
> This whole thing could be simpler with "mydestination = example.com" 
> and remove the local_transport and transport_maps settings.
> 

This worked and did greatly simplify things. I removed all of the
virtual stuff, went to local-users only, and reverted
local_recipient_maps to $alias_maps in which Mailman will list all valid
recipients. I didn't use the default for local_recipient_maps because I
wanted to reject apa...@example.com per my original message.


> 
> This isn't a good idea in this case. Leave local_recipient_maps at 
> default and let Mailman manage your alias_maps.
> 
>> local_transport = error:Local delivery is disabled.
> 
> As per above, might not be needed.
> 
>> mydomain = viabit.com
>> myhostname = http3.viabit.com
>> mynetworks_style = host
> 
> You have not set mydestination, thus getting the default. Why?
> 

I didn't know any better when I set it up.


> 
> If the list domain is in mydestination, there is no need for any 
> virtual aliasing of Mailman addresses.

Re: Local delivery & Mailman

[Michael Orlitzky]

On 01/28/2011 03:28 PM, Ralf Hildebrandt wrote:
> * Michael Orlitzky :
> 
>> I tried with transport_maps:
>>
>>   example.com  local:
>>
>> and local_transport = error:... and got this (http3.viabit.com is myorigin):
>>
>>   Jan 28 15:05:25 http3 postfix/error[20737]: 24944A302DF:
>>   to=, orig_to=,
>>   relay=none, delay=2.7, delays=2.7/0/0/0, dsn=5.0.0,
>>   status=bounced(Local delivery is disabled.)
>>
>> The more I think about it, the more I think it should have worked. I'll
>> try again once things slow down a bit (5pm).
> 
> postconf transport_maps 
> is showing what?

# postconf transport_maps
transport_maps = hash:/etc/postfix/maps/transport_maps

# cat /etc/postfix/maps/transport_maps
example.com local:

# ls /etc/postfix/maps/transport_maps.db
-rw-r--r-- 1 root root 12K 2011-01-28 15:02
/etc/postfix/maps/transport_maps.db

Same error:

  Jan 28 17:31:43 http3 postfix/error[4847]: C998730C669:
  to=, orig_to=
  , relay=none,
  delay=0.02, delays=0/0.01/0/0.01, dsn=5.0.0, status=bounced (Local
  delivery is disabled.)


Full postconf -n:

alias_database = hash:/etc/mail/aliases
alias_maps = hash:/var/lib/mailman/data/aliases
append_dot_mydomain = no
bounce_queue_lifetime = 1d
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
default_recipient_limit = 2
disable_vrfy_command = yes
home_mailbox = .maildir/
html_directory = /usr/share/doc/postfix-2.7.1/html
inet_interfaces = all
local_recipient_maps =
local_transport = error:Local delivery is disabled.
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maximal_queue_lifetime = 1d
mydomain = viabit.com
myhostname = http3.viabit.com
mynetworks_style = host
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.7.1/readme
relay_domains =
relayhost =
sample_directory = /etc/postfix
sender_dependent_default_transport_maps =
hash:/etc/postfix/maps/sender_dependent_default_transport_maps
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
show_user_unknown_table_name = no
smtpd_banner = $myhostname
smtpd_client_restrictions = reject_rbl_client jerks.viabit.com,
reject_rbl_client psbl.surriel.com, reject_rbl_client bl.spamcop.net,
reject_rbl_client zen.spamhaus.org,permit
smtpd_data_restrictions = reject_unauth_pipelining, permit
smtpd_delay_reject = yes
smtpd_error_sleep_time = 10
smtpd_etrn_restrictions = reject
smtpd_hard_error_limit = 5
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,permit
smtpd_junk_command_limit = 3
smtpd_recipient_limit = 2
smtpd_recipient_restrictions = permit_mynetworks,
reject_non_fqdn_recipient,  reject_unknown_recipient_domain,
reject_unauth_destination,  permit
smtpd_sender_restrictions = reject_non_fqdn_sender,
reject_unknown_sender_domain,   permit
smtpd_soft_error_limit = 2
strict_rfc821_envelopes = yes
transport_maps = hash:/etc/postfix/maps/transport_maps
unknown_local_recipient_reject_code = 550
virtual_alias_domains = hash:/etc/postfix/maps/virtual_alias_domains
virtual_alias_expansion_limit = 1
virtual_alias_maps = hash:/etc/postfix/maps/virtual_alias_maps,
hash:/var/lib/mailman/data/virtual-mailman
virtual_gid_maps = static:207
virtual_minimum_uid = 207
virtual_transport = virtual
virtual_uid_maps = static:207

Re: Local delivery & Mailman

[Michael Orlitzky]

On 01/28/2011 03:06 PM, Noel Jones wrote:
> On 1/28/2011 1:53 PM, Michael Orlitzky wrote:
>> On 01/28/2011 02:09 PM, Ralf Hildebrandt wrote:
>>> * Michael Orlitzky:
>>>
>>>> but one web server is running Mailman and can't do that (I think?)
>>> If it has a seperate domain for lists, you can use:
>>>
>>> lists.domain.com  local:
>>>
>>> in transport_maps and thus route that one domain to local:
>>>
>>
>> Wouldn't that override the default virtual transport, though? I do have
>> lists.example.com, but right now, everything comes in virtual and gets
>> mapped to local addresses which are then aliased to pipes. So,
>>
>>(virtual)   (local) (Mailman magic)
>>memb...@lists.example.com ->  members ->  |/usr/bin...
>>
> 
> Not quite.
> 
> Your virtual table rewrites it to "members".  Within postfix 
> all addresses have a domain, so "members" is rewritten to 
> "members@$myorigin".  Postfix then discovers the domain 
> $myorigin resolves to is listed in mydestination, and the 
> message is passed to the local transport for delivery.  Local 
> then drops the domain name for processing since local names 
> have no domain.
> 
> You can skip that process by directly writing an address 
> (either a whole domain or a specific address) to local with 
> the transport map.
> 
> # transport
> memb...@list.example.com   local:


I tried with transport_maps:

  example.com  local:

and local_transport = error:... and got this (http3.viabit.com is myorigin):

  Jan 28 15:05:25 http3 postfix/error[20737]: 24944A302DF:
  to=, orig_to=,
  relay=none, delay=2.7, delays=2.7/0/0/0, dsn=5.0.0,
  status=bounced(Local delivery is disabled.)

The more I think about it, the more I think it should have worked. I'll
try again once things slow down a bit (5pm).

Re: Local delivery & Mailman

[Michael Orlitzky]

On 01/28/2011 02:09 PM, Ralf Hildebrandt wrote:
> * Michael Orlitzky :
> 
>> but one web server is running Mailman and can't do that (I think?)
> If it has a seperate domain for lists, you can use:
> 
> lists.domain.com  local:
> 
> in transport_maps and thus route that one domain to local:
> 

Wouldn't that override the default virtual transport, though? I do have
lists.example.com, but right now, everything comes in virtual and gets
mapped to local addresses which are then aliased to pipes. So,

  (virtual)   (local) (Mailman magic)
  memb...@lists.example.com -> members -> |/usr/bin...

If I override the transport for lists.example.com, how will
'memb...@lists.example.com' get rewritten to 'members'?

Local delivery & Mailman

[Michael Orlitzky]

Most of our Postfices disable local delivery with,

  local_transport = error:...

but one web server is running Mailman and can't do that (I think?)
because it needs to support alias_maps like,

  members: "|/usr/lib/mailman/mail/mailman post members"

The result is that some mail gets through to root and I get mailed a few
warnings every day (mail to apache):

  Jan 28 11:07:09 http3 postfix/local[20920]: warning: maildir access
  problem for UID/GID=81/81: create maildir file /var/www/.maildir
  /tmp/1296230829.P20920.http3: Permission denied

  Jan 28 11:07:09 http3 postfix/local[20920]: warning: perhaps you need
  to create the maildirs in advance

I really don't want to create the maildir because I don't want the
messages in the first place. These aren't a big deal, but if there's an
easy way to disable all non-Mailman local deliveries, I'd like to do it.

Re: Reliably distinguishing authorized vs unauthorized users

[Michael Orlitzky]

On 01/19/11 15:03, Ron Garret wrote:
> I am working on a spam filter.  I want both incoming and outgoing
> messages to go through the filter, not because the outgoing messages
> need to be filtered, but because I want the filter to know who my
> authorized users have sent messages to because that is a very
> reliable indicator of non-spam.

amavisd-new can do this for you; the feature is called "pen pals." From
the homepage:

  pen pals soft-whitelisting feature (since 2.4.2) reduces spam score
  on replies to previous correspondence sent from a local user
  (requires logging to SQL to be enabled);

Re: Backup Mailserver

[Michael Orlitzky]

On 12/02/2010 11:15 PM, Ramesh wrote:
> 
> Hi All,
> 
> I have configured backup server, which is working as expected when
> ever primary not reachable mail are queued in back Mail server, later
> pushes to primary mail server.
> 
> I would like to know, how to make backup to primary mail server, in
> case primary is down due to major issues. so that all mail clients
> send and receive from backup mail server.
> 
> appreciate suggestion.

"Primary" and "backup" are a fiction. What makes your primary server
"primary?" You can probably come up with a list:

  * It's listening on the IP addresses to which your MX records point
  * It isn't configured to forward anywhere
  * It allows SASL authentication
  * ...

You should make such a list; when you're done, title it, "things I need
to do to the backup server to make it the primary."

Default certificate authorities

[Michael Orlitzky]

Where does Postfix get its list of "system-supplied default certificate
authority certificates" [1]? If it's an OpenSSL thing, is there some way
I can make it spit the list out?


[1] http://www.postfix.org/postconf.5.html#tls_append_default_CA

Re: master.cf question

[Michael Orlitzky]

On 11/16/2010 10:30 PM, Grant wrote:
> I use Gentoo and their etc-update script to update my config files.
> After updating to postfix-2.7.1 I noticed that etc-update wanted to
> change the following entry in master.cf:
> 
> smtps inet  n   -   n   -   -   smtpd
>   -o smtpd_tls_wrappermode=yes
> 
> to the following:
> 
> smtps inet  n   -   n   -   -   smtp
>   -o smtpd_tls_wrappermode=yes


The ebuild for postfix-2.7.1 simply takes master.cf from the Postfix
tarball, runs

  sed -i -e "s:/usr/local/:/usr/:g" conf/master.cf || die "sed failed"

and then copies it to /etc/postfix/._cfg_master.cf.

If something changed the smtps line too, you've got ghosts.

Re: RBL Spam question

[Michael Orlitzky]

On 11/05/10 03:01, Stan Hoeppner wrote:
>>
>> http://svn.apache.org/repos/asf/spamassassin/rules/branches/3.2/20_dynrdns.cf
> 
> Did you happen to notice the absolutely tiny number of expressions in
> the SA file, as compared to the ~1600 in the file whose use I promote
> here?  Maybe I should get in contact with someone in the project.  If
> only half were deemed usable by them it would be a huge improvement over
> what they have.
> 

Some guy named Stan Hoeppner suggested that the OP might want to use the
list for scoring in SpamAssassin. My point was that if he wants to do
that, he could just add them to the existing 20_dynrdns.cf file =)

Re: RBL Spam question

[Michael Orlitzky]

On 11/05/10 00:11, Stan Hoeppner wrote:
> Michael Orlitzky put forth on 11/4/2010 8:06 PM:
>> On 11/04/2010 12:39 AM, Stan Hoeppner wrote:
>>> Ned Slider put forth on 11/3/2010 6:33 PM:
>>>
>>>> My other thought was to simply comment (or document) ranges known to
>>>> contain FPs and then the user can make a judgement call whether they
>>>> want to comment out that particular regex based on their circumstances.
>>>> Not a very elegant solution.
>>>
>>> I'm starting to wonder, considering your thoughts on FPs, if this might
>>> be better implemented, for OPs concerned with potential FPs, via a
>>> policy daemon, or integrated into SA somehow and used for scoring
>>> instead of outright blocking.  I don't have the programmatic skill to
>>> implement such a thing.
>>
>>
>> http://wiki.apache.org/spamassassin/Rules/RDNS_DYNAMIC
> 
> Any idea where I can get a look that the regexes they use in this rule?
> 

I think this is the latest:

http://svn.apache.org/repos/asf/spamassassin/rules/branches/3.2/20_dynrdns.cf

Re: RBL Spam question

[Michael Orlitzky]

On 11/04/2010 12:39 AM, Stan Hoeppner wrote:
> Ned Slider put forth on 11/3/2010 6:33 PM:
> 
>> My other thought was to simply comment (or document) ranges known to
>> contain FPs and then the user can make a judgement call whether they
>> want to comment out that particular regex based on their circumstances.
>> Not a very elegant solution.
> 
> I'm starting to wonder, considering your thoughts on FPs, if this might
> be better implemented, for OPs concerned with potential FPs, via a
> policy daemon, or integrated into SA somehow and used for scoring
> instead of outright blocking.  I don't have the programmatic skill to
> implement such a thing.


http://wiki.apache.org/spamassassin/Rules/RDNS_DYNAMIC

Re: F/P with "reject_unknown_client_hostname"

[Michael Orlitzky]

On 11/03/10 08:17, Noel Jones wrote:
> On 11/3/2010 5:04 AM, Jerry wrote:
>> I noticed this posted on another forum:
>>
>> 
>> It should be noted that reject_unknown_client_hostname will check only
>> the first PTR record returned for a host. So, you might reject
>> well-configured (i.e. RFC-compliant) clients whose matching PTR record
>> unfortunately isn't the first one in the list.
>> 
>>
>> Is this factually correct? If so, what are the statistical chances of it
>> occurring? If correct, other than not using that option, what other
>> options should be used to prevent such an occurrence?
>>
> 
> While this is essentially correct, it's really FUD.
> 

I posted this in response to someone suggesting the scorched-earth
approach via reject_unknown_client_hostname using the rationale that you
won't block any RFC-compliant hosts.

In context, I wanted to point out that reject_unknown_client_hostname
might not be your weapon of choice even if you're on a crusade to purge
the net of all non-RFC-compliant hosts.

Re: Persistent mails being received

[Michael Orlitzky]

On 10/31/2010 10:21 AM, sunhux G wrote:
> 
> I'll need the exact commands in a Shell script to send email
>  to x...@yahoo.com  & y...@gmail.com
>  with a log file attached
> to it.

I believe you're looking for the 'sendmail' command.

Re: SMTP relay and greylisting

[Michael Orlitzky]

On 10/25/10 23:35, utahnix wrote:
> On 10/25/2010 9:05 PM, Michael Orlitzky wrote:
>> On 10/25/2010 10:38 PM, utahnix wrote:
>>> Hello all,
>>>
>>> Anyway, I've set up greylisting with Postgrey to help cut down on the
>>> junk mail that I get. I've set it up with default values (deferral of
>>> 300 seconds, etc). Well all seems good and fair except some of my
>>> regular senders can't seem to get their email through. I've checked my
>>> server logs and I don't even see their email address mentioned (it
>>> doesn't appear to even reach my machine). Several of the emails in
>>> question are Yahoo or Gmail. What's odd is that I have both a Yahoo
>>> account and a Gmail account, and I can send myself mail with no problems.
>>>
>>> I disabled Postgrey temporarily and had these senders re-send test
>>> messages from their addresses, and it worked (I got their messages). So
>>> something was certainly hanging things up. I just wish I knew what that was.
>>
>> Do you have "smtpd_delay_reject = yes" set? If so, you should be able to
>> see the senders' addresses in your logs even if they were greylisted.
> 
> Yes I do, actually.
> 

The blacklisting is a separate issue (haven't had time to look through
the postconf yet), but if you have this set and aren't seeing the
senders' addresses in your logs, they're screwing something up. A typo
in your domain name, maybe?

Re: SMTP relay and greylisting

[Michael Orlitzky]

On 10/25/2010 10:38 PM, utahnix wrote:
> Hello all,
> 
> This question has probably been asked on this list before, but maybe not 
> quite with these circumstances. I'm hoping one of you can give me some 
> direction.
> 
> I've got a fairly typical Postfix setup... Postfix, Cyrus IMAP, ClamAV, 
> SpamAssassin... all on Linux.
> 
> Anyway, I've set up greylisting with Postgrey to help cut down on the 
> junk mail that I get. I've set it up with default values (deferral of 
> 300 seconds, etc). Well all seems good and fair except some of my 
> regular senders can't seem to get their email through. I've checked my 
> server logs and I don't even see their email address mentioned (it 
> doesn't appear to even reach my machine). Several of the emails in 
> question are Yahoo or Gmail. What's odd is that I have both a Yahoo 
> account and a Gmail account, and I can send myself mail with no problems.
> 
> I disabled Postgrey temporarily and had these senders re-send test 
> messages from their addresses, and it worked (I got their messages). So 
> something was certainly hanging things up. I just wish I knew what that was.

Do you have "smtpd_delay_reject = yes" set? If so, you should be able to
see the senders' addresses in your logs even if they were greylisted.


> This got me thinking... my ISP requires that I forward all outbound 
> email through their SMTP server. Because their mail server (the SMTP 
> relay I'm required to relay mail to) has suddenly been added to various 
> RBLs for repeated "deferrals", is it possible that my greylisting is 
> what is getting them on those RBLs?

Added to RBLs for deferrals? Doesn't make sense, or I'm missing something.


> The Postgrey does cut down on the spam significantly, particularly when 
> used in conjunction with SpamAssassin and RBLs like SpamCop and 
> SpamHaus. I'd like to keep Postgrey if I can, assuming that my delivery 
> problems are not directly associated with Postgrey... but if my 
> circumstances with my ISP won't allow me to greylist, then disabling 
> Postgrey might save me a headache.
> 
> I guess I'm looking for some advice as to whether Postgrey could cause 
> problems with my ISP (they run Exim on FreeBSD and firewall outgoing tcp 
> port 25 everywhere but on their one mail server) but I don't know much 
> more than that), or if there are some settings I should change to 
> improve my greylisting setup.

It's highly unlikely, but concentrate on one problem at a time.

When these people send to you and the messages don't make it through, do
they get a rejection or anything that might suggest that delivery failed?

If not -- while you should still be seeing their email address in the
logs -- I would guess that SpamAssassin or ClamAV snatched the message.

Now might be a good time to post your `postconf -n`.

Re: reverse greylist

[Michael Orlitzky]

On 10/13/2010 05:53 PM, Dan Lannom wrote:
> At many Universities there is a continual problem with accounts being
> phished and used to send spam.  We have a number of measures that
> catch stolen accounts but they take a little bit of time to block
> outgoing email.
> 
> Ideally I'd like to hold email to either a new address or a new
> address,sender,sender ip triplet like greylisting uses.  Even holding
> for a minute would give us enough time to lock the account and remove
> all incentives to phish our accounts (I hope).
> 
> Is anyone  aware of of a greylisting type policy server that can use
> a specific header, containing the sender ip, or one that just uses
> the destination address?

You could modify Postgrey to return HOLD instead of DEFER_IF_PERMIT.
Then, subject your submission service to the modified Postgrey.

Held messages can be released with a cron job.

(You may want to test that the auto-whitelist still works properly under
this scheme.)

Re: Log reporting by cidr

[Michael Orlitzky]

On 10/05/2010 11:14 AM, pf at alt-ctrl-del.org wrote:
> 
> Great!
> By saving one version with:
> if ($line =~ ' connect from .*\[([\d\.]+?)\]') {
> 
> And another with:
> if ($line =~ 'smtpd.*client=.*\[([\d\.]+?)\]') {
> 
> I can compare attempts vs success, from specific networks.
> 

Rather than use an array of programs, here's a program of arrays. It
will print the CIDR, followed by successes/attempts.


#!/usr/bin/perl
use strict;
use warnings;

use Net::CIDR::Lite;

if ($#ARGV < 1) {
  print("Usage: parse.pl  \n");
  exit
}

my $logfile  = $ARGV[0];
my $cidrfile = $ARGV[1];

open(my $cidrh, '<', $cidrfile) or die "Can't open $cidrfile: $!";

# The list of CIDR objects.
my @cidrs  = ();

# A hash, of CIDR => (successes, attempts)
my %counts = ();

while (my $line = <$cidrh>) {
  # Add each line in the CIDR file to the hash, with default
  # counts of (0, 0).
  my $cidr = Net::CIDR::Lite->new;
  $cidr->add($line);
  push(@cidrs, $cidr);
  $counts{$cidr} = [0,0];
}

close($cidrh);
open(my $logh,  '<', $logfile) or die "Can't open $logfile: $!";

# Loop through the log file, looking for connections. When one is
# found, we go through the list of CIDRs to see if the IP address
# belongs to any. If it does, increase the attempt count for that
# CIDR.
while (my $line = <$logh>) {
  # The leading space rules out "DISconnect from..."
  if ($line =~ ' connect from .*\[([\d\.]+?)\]') {
my $ip = $1;
foreach my $cidr (@cidrs) {
  if ($cidr->find($ip)) {
$counts{$cidr}->[1] += 1;
  }
}
  }
  elsif ($line =~ 'smtpd.*client=.*\[([\d\.]+?)\]') {
# Likewise for the successes, except we increase a different
# variable.
my $ip = $1;
foreach my $cidr (@cidrs) {
  if ($cidr->find($ip)) {
$counts{$cidr}->[0] += 1;
  }
}
  }
}

close($cidrh);

# And finally, print the tally.
foreach my $cidr (@cidrs) {
  my @list = $cidr->list();
  my $attempts  = $counts{$cidr}->[1];
  my $successes = $counts{$cidr}->[0];
  print("@list: $successes/$attempts\n");
}

Re: Log reporting by cidr

[Michael Orlitzky]

On 10/04/2010 06:25 PM, pf at alt-ctrl-del.org wrote:
> 
>> On 10/04/2010 02:48 PM, pf at alt-ctrl-del.org wrote:
>>> Are there any existing scripts out there, that report connection counts by 
>>> cidr network?
>>>
>>> Input:?
>>> parse.pl   /var/log/mail   cidr_list.zone
>>>
>>> Output:?
>>> network count
>>> 10.10.128.0/19  983
>>> 10.144.48.0/20  121
>>>
>>
> On 10/04/2010 4:52 PM, Michael Orlitzky wrote:
>> What's in that cidr_list.zone file?
> 
> Simple list of cidr format networks, one per line.
> Either a hand crafted list, or a full country .zone file from 
> http://ipdeny.com/ipblocks/
> 
> 

This should work, although the standard disclaimers apply:

1. There's no error checking.
2. The regular expression for connections might not be correct.
3. It's slow.
4. I don't actually know Perl.

You'll also need Net::CIDR::Lite. It currently prints out a full tally
including ranges which had zero matches. That's bad for e.g. China with
1822 CIDRs, most of which are zero for me.


#!/usr/bin/perl
use strict;
use warnings;

use Net::CIDR::Lite;

if ($#ARGV < 1) {
  print("Usage: parse.pl  \n");
  exit
}

my $logfile  = $ARGV[0];
my $cidrfile = $ARGV[1];

open(my $cidrh, '<', $cidrfile) or die "Can't open $cidrfile: $!";

# The list of CIDR objects.
my @cidrs  = ();

# A hash, of CIDR => 
my %counts = ();

while (my $line = <$cidrh>) {
  # Add each line in the CIDR file to the hash, with a default
  # count of zero.
  my $cidr = Net::CIDR::Lite->new;
  $cidr->add($line);
  push(@cidrs, $cidr);
  $counts{$cidr} = 0;
}

close($cidrh);
open(my $logh,  '<', $logfile) or die "Can't open $logfile: $!";

# Loop through the log file, looking for connections. When one is
# found, we go through the list of CIDRs to see if the IP address
# belongs to any. If it does, increase the count for that CIDR.
while (my $line = <$logh>) {
  # The leading space rules out "DISconnect from..."
  if ($line =~ ' connect from .*\[([\d\.]+?)\]') {
my $ip = $1;
foreach my $cidr (@cidrs) {
  if ($cidr->find($ip)) {
   $counts{$cidr} += 1;
  }
}
  }
}

close($cidrh);

# And finally, print the tally.
foreach my $cidr (@cidrs) {
  my @list = $cidr->list();
  print("@list: $counts{$cidr}\n");
}