Re: Memcache table ttl vs postscreen _ttl and verify expire/refresh

2021-09-03 Thread Noel Jones 



On 9/3/2021 5:38 AM, Kristian wrote:

Hi,

I have a setup of two MX servers sharing postscreen and verify cache 
using a memcached service.


At the moment, my config for this is (on both servers):

/etc/postfix/main.cf:

   postscreen_cache_map = memcache:/etc/postfix/postscreen_cache.cf
   postscreen_cache_cleanup_interval = 0

   address_verify_map = memcache:/etc/postfix/verify_cache.cf
   address_verify_cache_cleanup_interval = 0

/etc/postfix/postscreen_cache.cf:

   memcache = inet:1.2.3.4:11211
   key_format = postscreen:%s

/etc/postfix/verify_cache.cf:

   memcache = inet:1.2.3.4:11211
   ttl = 86400
   key_format = verify:%s

What I haven't been able to grasp, is how exactly the memcache 
table's ttl value affects the postscreen_*_ttl values and verify's 
expire/refresh times, or vice versa.


For example, I have postscreen_bare_newline_ttl = 30d, but with a 
memcache ttl of (default) 3600, which one is the true value?


Settings for postscreen and verify that possibly are affected by the 
memcache table's ttl could be:


postscreen_bare_newline_ttl = 30d
postscreen_greet_ttl = 1d
postscreen_non_smtp_command_ttl = 30d
postscreen_pipelining_ttl = 30d
postscreen_cache_retention_time = 7d
postscreen_dnsbl_max_ttl = 
${postscreen_dnsbl_ttl?{$postscreen_dnsbl_ttl}:{1}}h

postscreen_dnsbl_min_ttl = 60s

address_verify_negative_expire_time = 3d
address_verify_negative_refresh_time = 10m
address_verify_positive_expire_time = 31d
address_verify_positive_refresh_time = 7d

Are some of these settings unused with a cleanup of 0, or is that a 
completely different operation?






Generally, the smallest TTL is what will be used. Memcache will 
remove entries that have not been accessed for $TTL. Postscreen and 
address verify will not use records that have not been refreshed for 
their respective $TTL. So they are similar, but not exactly the same.


The expire time marks records as "old" but does not remove them.
The cleanup function removes/deletes expired records.

See http://www.postfix.org/memcache_table.5.html and especially the 
notes under the "backup" and "ttl" options.



  -- Noel Jones

Memcache table ttl vs postscreen _ttl and verify expire/refresh

2021-09-03 Thread Kristian 

Hi,

I have a setup of two MX servers sharing postscreen and verify cache 
using a memcached service.


At the moment, my config for this is (on both servers):

/etc/postfix/main.cf:

  postscreen_cache_map = memcache:/etc/postfix/postscreen_cache.cf
  postscreen_cache_cleanup_interval = 0

  address_verify_map = memcache:/etc/postfix/verify_cache.cf
  address_verify_cache_cleanup_interval = 0

/etc/postfix/postscreen_cache.cf:

  memcache = inet:1.2.3.4:11211
  key_format = postscreen:%s

/etc/postfix/verify_cache.cf:

  memcache = inet:1.2.3.4:11211
  ttl = 86400
  key_format = verify:%s

What I haven't been able to grasp, is how exactly the memcache table's 
ttl value affects the postscreen_*_ttl values and verify's 
expire/refresh times, or vice versa.


For example, I have postscreen_bare_newline_ttl = 30d, but with a 
memcache ttl of (default) 3600, which one is the true value?


Settings for postscreen and verify that possibly are affected by the 
memcache table's ttl could be:


postscreen_bare_newline_ttl = 30d
postscreen_greet_ttl = 1d
postscreen_non_smtp_command_ttl = 30d
postscreen_pipelining_ttl = 30d
postscreen_cache_retention_time = 7d
postscreen_dnsbl_max_ttl = 
${postscreen_dnsbl_ttl?{$postscreen_dnsbl_ttl}:{1}}h

postscreen_dnsbl_min_ttl = 60s

address_verify_negative_expire_time = 3d
address_verify_negative_refresh_time = 10m
address_verify_positive_expire_time = 31d
address_verify_positive_refresh_time = 7d

Are some of these settings unused with a cleanup of 0, or is that a 
completely different operation?



--
Kristian

Re: why outlook Mail has no DKIM setup?

2021-09-03 Thread raf 
On Fri, Sep 03, 2021 at 04:14:55AM +, w...@purpleemail.com wrote:

> Greetings,
> 
> It seems my outlook.hu email doesn't setup a DKIM for outgoing messages.
> The result showed in gmail header:
> 
> SPF:  PASS with IP 40.92.18.14 Learn more
> DMARC:'PASS' 
> 
> It has only spf setup, no DKIM. if the message was forwarded by the third 
> party, the DMARC will fail.
> 
> Can you help explaining this?
> 
> Thanks.

That's probably a question for Microsoft to answer. :-)

There is a _dmarc.outlook.hu TXT record:

  "v=DMARC1; p=none; 
rua=mailto:d...@rua.agari.com;ruf=mailto:d...@ruf.agari.com;fo=1:s:d;

but the policy is "none", so it doesn't matter if DMARC
fails. A DMARC failure shouldn't result in any email
being quarantined or rejected.

A wierd thing is that their _dmarc record has
"fo=1:s:d" which means that they want to receive
reports for any DKIM failure. That would be every email
that comes out of there. Maybe they are conducting a
study on DMARC checkers.

cheers,
raf