Re: dnsblog lifetime

[Doug Hardie]

> On 24 April 2018, at 13:48, Wietse Venema  wrote:
> 
> Doug Hardie:
>>> On 22 April 2018, at 05:50, Wietse Venema  wrote:
>>> 
>>> Doug Hardie:
 I understood from the dnsblog man page that each dnsblog process
 only lives for a "limited amount of time".  I noticed this because
 I have over 50 dnsblog processes running on a fairly light duty
 postfix server.  Some of them are over a week old.  At first I
 thought they must have been orphaned, but looking through maillog,
 I find entries in the last few minutes from the oldest and the
 newest.  I didn't check all of them, but it appears they are all
 in use.  Looking at the source for postfix-3.3-20180114 (on web),
 it appears dnsblog checks one IP address and then exits.  I believe
 I can limit the number of dnsblog processes in master.cf (currently
 set to 0), but I am not sure that is a good idea.  How long are
 these processes supposed to live?
>>> 
>>> According to source, dnsblog processes exclude themselves from the
>>> max_use limit (max_idle remains in effect). I suppose I turned off
>>> max_use because these processes are postscreen helpers. Postscreen
>>> was designed to handle a much larger client load than to the rest
>>> of Postfix. Under extreme loads like 1+ connections/second,
>>> one does not want to be creating 100+ processes/second, as that
>>> would limit scalability.
>>> 
>>> The dnsblog processes still terminate after 100s idle time. On my
>>> lightly-loaded server, there currently is no dnsblog process running.
> 
> I think that we can avoid the need for warnings in documentation,
> by making the dnsblog service act according to the spirit of the
> max_idle and max_use settings, even if it cannot act by the letter.
> 
> With a given max_idle and max_use setting, a process is expected
> to terminate within approximately (max_idle * max_use) seconds.
> That is, on a low-volume (but not too low) server, a process may
> hang around for a few hours (100*100 = 1 seconds).
> 
> Even if the dnsblog process cannot enforce max_use literally (because
> dbsnlog may have to handle a huge number of requests during peak
> load), the process could still retire voluntarily after (max_idle
> * max_use) seconds, without any negative performance impact.
> 
> I'll look into implementing that.

Either way works for me.  I just got confused when I saw the durations of the 
processes and then read the man page.  I thought I had configured something 
incorrectly as they didn't match.  If I had your first response in the man page 
I would have said ahhh, now I understand.  

-- Doug

Re: dnsblog lifetime

[Wietse Venema]

Doug Hardie:
> > On 22 April 2018, at 05:50, Wietse Venema  wrote:
> > 
> > Doug Hardie:
> >> I understood from the dnsblog man page that each dnsblog process
> >> only lives for a "limited amount of time".  I noticed this because
> >> I have over 50 dnsblog processes running on a fairly light duty
> >> postfix server.  Some of them are over a week old.  At first I
> >> thought they must have been orphaned, but looking through maillog,
> >> I find entries in the last few minutes from the oldest and the
> >> newest.  I didn't check all of them, but it appears they are all
> >> in use.  Looking at the source for postfix-3.3-20180114 (on web),
> >> it appears dnsblog checks one IP address and then exits.  I believe
> >> I can limit the number of dnsblog processes in master.cf (currently
> >> set to 0), but I am not sure that is a good idea.  How long are
> >> these processes supposed to live?
> > 
> > According to source, dnsblog processes exclude themselves from the
> > max_use limit (max_idle remains in effect). I suppose I turned off
> > max_use because these processes are postscreen helpers. Postscreen
> > was designed to handle a much larger client load than to the rest
> > of Postfix. Under extreme loads like 1+ connections/second,
> > one does not want to be creating 100+ processes/second, as that
> > would limit scalability.
> > 
> > The dnsblog processes still terminate after 100s idle time. On my
> > lightly-loaded server, there currently is no dnsblog process running.

I think that we can avoid the need for warnings in documentation,
by making the dnsblog service act according to the spirit of the
max_idle and max_use settings, even if it cannot act by the letter.

With a given max_idle and max_use setting, a process is expected
to terminate within approximately (max_idle * max_use) seconds.
That is, on a low-volume (but not too low) server, a process may
hang around for a few hours (100*100 = 1 seconds).

Even if the dnsblog process cannot enforce max_use literally (because
dbsnlog may have to handle a huge number of requests during peak
load), the process could still retire voluntarily after (max_idle
* max_use) seconds, without any negative performance impact.

I'll look into implementing that.

Wietse

Re: alternate ways to mark messages with Received SPF : None

[Wietse Venema]

If you need to modify a message depending on the content of some
message header, then that requires a Milter (for example, python
milter) or 'external' content filter.

Wietse

Re: inet_interfaces

[Bill Shirley]

My approach would be to SNAT it with iptables.
-s pub.lic.adr.1 -m policy --pol none --dir out -j SNAT --to-source 
pub.lic.adr.2

Bill

On 4/23/2018 6:38 PM, @lbutlr wrote:

On 2018-04-23 (15:30 MDT), Viktor Dukhovni  wrote:

With separate transports, one can have "-o smtp_bind_address=127.0.0.1" and the stock "smtp" and 
"relay" transports can have "-o smtp_bind_address=192.0.2.1" (or whatever you have for an external 
address). Seems pretty light-weight to me, but you call of course for your systems...

It's not weather it is light weight or not, it's simply finding all the places 
I would need to do this, sleeping track or it, all to try to fix someone else's 
broken server. It's not like this has ever been a problem with anyone else.

Re: inet_interfaces

[Benny Pedersen]

@lbutlr skrev den 2018-04-24 15:02:

On 2018-04-23 (20:33 MDT), Benny Pedersen  wrote:


@lbutlr skrev den 2018-04-23 21:30:


covisp.net. 86400   IN  TXT "v=spf1 mx a
ip4:65.121.55.40/29 -all"


this domain have duplicates ipv4 in spf


? SPF checks out fine at

and that range is my IP block.

I don't see anything duplicated.


https://dmarcian.com/spf-survey/ test it here

we have now duplicated time on it

RE: alternate ways to mark messages with Received SPF : None

[Fazzina, Angelo]

Hi, wouldn’t that break the DKIM sig if the email was signed ?


-ANGELO FAZZINA

ITS Service Manager:
Spam and Virus Prevention
Mass Mailing
G Suite/Gmail

ang...@uconn.edu
University of Connecticut,  ITS, SSG, Server Systems
860-486-9075

From: owner-postfix-us...@postfix.org  On 
Behalf Of Selcuk Yazar
Sent: Tuesday, April 24, 2018 10:05 AM
To: postfix-users@postfix.org
Subject: alternate ways to mark messages with Received SPF : None

Hi,

how can i mark emails (SPAM or something else) with if it has header  "Received 
SPF : None"

we have redhat EL6 server but it spamassassin version 3.3.1. it's la little bit 
risky upgrade to latest version for me :)

nay alternate soltuion ?

regards.

--
Selçuk YAZAR

alternate ways to mark messages with Received SPF : None

[Selcuk Yazar]

Hi,

how can i mark emails (SPAM or something else) with if it has header
"Received SPF : None"

we have redhat EL6 server but it spamassassin version 3.3.1. it's la little
bit risky upgrade to latest version for me :)

nay alternate soltuion ?

regards.

-- 
Selçuk YAZAR

Re: inet_interfaces

[@lbutlr]

On 2018-04-23 (20:33 MDT), Benny Pedersen  wrote:
> 
> @lbutlr skrev den 2018-04-23 21:30:
> 
>> covisp.net. 86400   IN  TXT "v=spf1 mx a
>> ip4:65.121.55.40/29 -all"
> 
> this domain have duplicates ipv4 in spf

? SPF checks out fine at 
 and 
that range is my IP block.

I don't see anything duplicated.