On 29-5-19 19:21, Jos Chrispijn wrote:
Interesting that you ask, as I just checked postfix after a restart
and it all goes well again.
Decided to restart from cron every 12 hours, but I guess that is just
symptom suppression
A friend advised me to run /postfix/update and it looks as if this di
On 29 May 2019, at 08:52, Benny Pedersen wrote:
> /var/tmp must not be cleaned after boots, /tmp will be cleaned on boot
I've never heard that. Is that a real thing or just your own 'rule'?
--
Lobotomy means never having to say you're sorry -- or anything else.
On Thu, May 30, 2019 at 04:44:13AM -0600, @lbutlr wrote:
> On 29 May 2019, at 08:52, Benny Pedersen wrote:
> > /var/tmp must not be cleaned after boots, /tmp will be cleaned on boot
> I've never heard that. Is that a real thing or just your own 'rule'?
https://refspecs.linuxfoundation.org/FHS_3.0
On 30 May 2019, at 02:39, Jos Chrispijn wrote:
> A friend advised me to run /postfix/update and it looks as if this did the
> trick. Part of that file contains:
>
> newaliases
> postalias hash:/etc/aliases
> postfix reload
> postfix flush
Wher
e did that come from? (It doesn't exist on my syst
On 30-5-19 12:52, @lbutlr wrote:
On 30 May 2019, at 02:39, Jos Chrispijn wrote:
Where did that come from? (It doesn't exist on my system).
Amongst others (updating tables), this is now standard on my Postfix
upgrade batch.
I don't know about you, but new aliases and postalias and postmap are t
Jos Chrispijn:
> Wietse, does this match the cause you expected it to be?
On a sane system (LINUX included), Postfix can run without ever
needing a baby sitter cronjob.
What I suspected was an effed-up system; your need to run a baby
sitter cronjob confirms my suspicion.
Are you running Postfix
On 30-5-19 13:50, Wietse Venema wrote:
On a sane system (LINUX included), Postfix can run without ever
needing a baby sitter cronjob.
OK - never experienced this issue but only for the last few weeks.
What I suspected was an effed-up system; your need to run a baby
sitter cronjob confirms my su
Jos Chrispijn:
> On 30-5-19 13:50, Wietse Venema wrote:
> > On a sane system (LINUX included), Postfix can run without ever
> > needing a baby sitter cronjob.
> OK - never experienced this issue but only for the last few weeks.
What has changed? Not Postfix as far as I can tell.
> > What I suspe
On 29 May 2019, at 08:52, Benny Pedersen wrote:
/var/tmp must not be cleaned after boots, /tmp will be cleaned on boot
On 30.05.19 04:44, @lbutlr wrote:
I've never heard that. Is that a real thing or just your own 'rule'?
it's standard FHS:
https://en.wikipedia.org/wiki/Filesystem_Hierarch
On 30-5-19 14:25, Wietse Venema wrote:
Again, this confirms my suspicion that the system has gotten messed
up. Postfix has been around for decennia and it does not require
restarts to stay functional.
Ok, thanks y'all for helping out. Everything is fine now.
/jos
-- With both feet on the grou
On 30/05/2019 14:41, Jos Chrispijn wrote:
> On 30-5-19 14:25, Wietse Venema wrote:
>> Again, this confirms my suspicion that the system has gotten messed
>> up. Postfix has been around for decennia and it does not require
>> restarts to stay functional.
>
> Ok, thanks y'all for helping out. Everyth
On 30 May 2019, at 06:32, Matus UHLAR - fantomas wrote:
>> On 29 May 2019, at 08:52, Benny Pedersen wrote:
>>> /var/tmp must not be cleaned after boots, /tmp will be cleaned on boot
>
> On 30.05.19 04:44, @lbutlr wrote:
>> I've never heard that. Is that a real thing or just your own 'rule'?
>
>
On 30 May 2019, at 07:24, @lbutlr wrote:
> But can still be deleted at any time, just "less frequently than /tmp";
> certainly not a place to store necessary files. I don't see this anywhere for
> *BSD, thankfully, so I can safely ignore it.
Goops, forgot to past this:
/var/tmp/ Temporary fil
On 30.05.19 07:27, @lbutlr wrote:
On 30 May 2019, at 07:24, @lbutlr wrote:
But can still be deleted at any time, just "less frequently than /tmp";
certainly not a place to store necessary files. I don't see this anywhere for *BSD,
thankfully, so I can safely ignore it.
Goops, forgot to past
> On 30 May 2019, at 07:37, Matus UHLAR - fantomas wrote:
>
> On 30.05.19 07:27, @lbutlr wrote:
>> On 30 May 2019, at 07:24, @lbutlr wrote:
>>> But can still be deleted at any time, just "less frequently than /tmp";
>>> certainly not a place to store necessary files. I don't see this anywher
Hi David (and re-adding the list in case we say something interesting),
“Snowshoe spam”, as I understand it is basically a spammer sending batches from
a list of “clean” IPs - not too many emails per IP, but lots of hosts to send
from. By the time an IP is blacklisted, it’s already done spammin
There is an RBL, zz.countries.nerd.dk, which will return a code based on country
of origin - or if you substitute a country code (eg uk.countries.nerd.dk) it
will return 127.0.0.1 if the host "belongs" to that country; it can be used to
load the final RBL score for an individual country. I don't
On 30/05/2019 22:21, Allen Coates wrote:
> Currently, I am using a CIDR access-control-list to block (in PostScreen)
> hosts
> from certain "nuisance" countries. A weekly script derives the netblocks from
> the zone lists published by http://www.ipdeny.com
A similar script could derive a DNS z
I am getting mail delivery status reports for every bcc email (that is, every
email, since I use a bcc map to create a backup of all the mail).
I've looked through all the postfix files for any instance of sendmail -v, and
have only found it as a comment in bounce.cf.default
/usr/local/etc/post
On Fri, May 31, 2019 at 12:03:37AM -0600, @lbutlr wrote:
> I am getting mail delivery status reports for every bcc email (that is, every
> email, since I use a bcc map to create a backup of all the mail).
Then you missconfigured something. Mails duplicated by bcc maps are
sent with NOTIFY=NONE,
Hi,
I'm running a pair of postfix-servers in different data-centers (different
ip networks) for outgoing-only delivery. once in a while my providers /22
appear on public blacklists, so mails from my nodes also gets rejected.
For this, i have now a third backup-instance in another data center that
21 matches
Mail list logo
