Re: Outbound opportunistic TLS by default?

2018-12-20 Thread Andrey Repin
Greetings, Viktor Dukhovni! >> >> This is easy enough to implement, the only complication is >> >> that the documentation would need to explain the variable >> >> default. >> >> >> >>> If it is compiled without TLS, the default should be 'no'. >> >> >> >> This is certainly possible. >> > >> > It s

Re: Outbound opportunistic TLS by default?

2018-12-20 Thread Eray Aslan
On Wed, Dec 19, 2018 at 02:36:50PM -0500, Viktor Dukhovni wrote: > If there are no objections, I can change the default to "may" when > TLS is compiled in. No objections for setting smtp_tls_security_level. Thanks for your effort. -- Eray

Re: Postscreen concurrency limits

2018-12-20 Thread @lbutlr
On 20 Dec 2018, at 11:08, Viktor Dukhovni wrote: > Viruses can come from any source. OK, But I am pretty sure I’ve never seen a virus from mail chimp. I don’t have a large enough load to worry about not scanning, but if I did the first thing I would stop scanning is gmail incoming and the larg

Re: detect fake mx, tls security encrypt

2018-12-20 Thread Stefan Bauer
thats a nice approach! thank you. will test. Am Donnerstag, 20. Dezember 2018 schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: >> On Dec 20, 2018, at 1:25 PM, Stefan Bauer wrote: >> >> I'm aware of such exceptions but I don't like to set them. Our policy is safe or not at all via mail. > >

Re: explore/test pipemap?

2018-12-20 Thread Todd C. Olson
Thank you Viktor That was the issue. Regards, Todd From: owner-postfix-us...@postfix.org on behalf of Viktor Dukhovni Sent: Thursday, December 20, 2018 11:52 To: Postfix users Subject: Re: explore/test pipemap? > On Dec 20, 2018, at 10:17 AM, Todd C. Olson

Re: detect fake mx, tls security encrypt

2018-12-20 Thread Viktor Dukhovni
> On Dec 20, 2018, at 1:25 PM, Stefan Bauer wrote: > > I'm aware of such exceptions but I don't like to set them. Our policy is > safe or not at all via mail. That policy has a cost. You don't like the cost, but there it is... > I would like to have a setting like do not try next mx, > if fi

Re: detect fake mx, tls security encrypt

2018-12-20 Thread Stefan Bauer
I'm aware of this exeptions but i dont like to set them. our policy is safe or not at all via mail. i would like to have a setting like do not try next mx, if first mx lacks tls support. it assumes that if tls is not avail on primary it will for sure also not be avail on second and third. Am Donn

Re: dnsbl postscreen - not blocking

2018-12-20 Thread @lbutlr
On 20 Dec 2018, at 06:46, Kai Schaetzl wrote: > Using Sorbs is dangerous, anyway, we abandoned it years ago. If you want > to use it then use it in the way it is intended for weighted RBLs. e.g. do > not use it as the sole source of blocking. I keep parring down my list and am considering going

Re: detect fake mx, tls security encrypt

2018-12-20 Thread Viktor Dukhovni
> On Dec 20, 2018, at 12:42 PM, Stefan Bauer wrote: > > I use smtp_tls_security_level = encrypt The cost of that choice is that you must also have: main.cf: indexed = ${default_database_type}:${config_directory}/ smtp_tls_policy_maps = ${indexed}tls-policy and be prepared to watch yo

Re: Postscreen concurrency limits

2018-12-20 Thread Viktor Dukhovni
> On Dec 20, 2018, at 1:04 PM, @lbutlr wrote: > > Am I wrong in thinking that doing an A/V scan on mail from Mailchimp and/or > cosntantcontact is a waste of time? > > They are not sending viruses. Hell, they are not even sending spam. Viruses can come from any source. And message origin auth

Re: Postscreen concurrency limits

2018-12-20 Thread @lbutlr
On 18 Dec 2018, at 16:58, Viktor Dukhovni wrote: > The solution is perhaps in part to throw some more CPU at the > problem, but alternatively, assuming that mailchimp et. al. > are not abusing reasonable concurrency limits, you can reduce > the impedance mismatch by increasing the input latency, b

Re: detect fake mx, tls security encrypt

2018-12-20 Thread Noel Jones
On 12/20/2018 11:42 AM, Stefan Bauer wrote: > Hi, > > i use smtp_tls_security_level = encrypt - if remote site have mx like > > mx 10 mail1 without tls > mx 100 mail2 fake-mx with no open port > > postfix detects lack of tls on mx10goes to mx100 and waits > maximal_queue_lifetime. > > i don't l

detect fake mx, tls security encrypt

2018-12-20 Thread Stefan Bauer
Hi, i use smtp_tls_security_level = encrypt - if remote site have mx like mx 10 mail1 without tls mx 100 mail2 fake-mx with no open port postfix detects lack of tls on mx10goes to mx100 and waits maximal_queue_lifetime. i don't like fake mx as they create a long delay. i could reduce queue lif

Re: explore/test pipemap?

2018-12-20 Thread Viktor Dukhovni
> On Dec 20, 2018, at 10:17 AM, Todd C. Olson wrote: > > However postmap reports > postmap: fatal: unsupported dictionary type: pipemap > > Cornell University Your version of Postfix is likely too old. $ postconf mail_version mail_release_date mail_version = 3.3.1 mail_release_date = 201

Re: capture information for internal generated mails

2018-12-20 Thread d tbsky
Matus UHLAR - fantomas > archiving one copy of a mail is enough. If you need information about how > the mail was sent, you need archive logs, not another copy of e-mail. yes one copy of mail is enough. other redundant mails are just for extra information and will be abandoned after extract th

explore/test pipemap?

2018-12-20 Thread Todd C. Olson
Hi How does one test/explore pipemap? I was hoping to use something like postmap -q - 'pipemap:{ldap:./adlookup.cf pcre:./smtpstrip.pcre}' in analogy to postmap -q - ldap:./adlookup.cf and postmap -q - pcre:./smtpstrip.pcre However postmap reports postmap: fatal: unsupported dictiona

Re: capture information for internal generated mails

2018-12-20 Thread d tbsky
Dominic Raferd > I never heard of such requirement before. But the QueueID can be found in the > first Received: header in each archived email and you can match this with the > relevant smtp line for the outgoing delivery in the log file. You could > extract the relevant data from this line and

Re: capture information for internal generated mails

2018-12-20 Thread Dominic Raferd
On Thu, 20 Dec 2018 at 14:23, d tbsky wrote: > Matus UHLAR - fantomas > >> On 20.12.18 21:50, d tbsky wrote: > >>I don't know if it is easier. but what I want is three information: > >>the mail content, who send the mail, the mail send to whom. > > > >the latter 2 information is not available in

Re: capture information for internal generated mails

2018-12-20 Thread Matus UHLAR - fantomas
On 20.12.18 21:50, d tbsky wrote: I don't know if it is easier. but what I want is three information: the mail content, who send the mail, the mail send to whom. the latter 2 information is not available in mail header, unless you use dirty hacks. yes I think I already use some dirty hacks.

Re: capture information for internal generated mails

2018-12-20 Thread d tbsky
Matus UHLAR - fantomas >> On 20.12.18 21:50, d tbsky wrote: >>I don't know if it is easier. but what I want is three information: >>the mail content, who send the mail, the mail send to whom. > >the latter 2 information is not available in mail header, unless you use >dirty hacks. yes I think

Re: capture information for internal generated mails

2018-12-20 Thread Matus UHLAR - fantomas
Matus UHLAR - fantomas isn;t it easier to save one copy of mail with the logs, instead of two copied of mail, without logs? Note that logs will show e.g. when mail was refused by destination server, mail won't. On 20.12.18 21:50, d tbsky wrote: I don't know if it is easier. but what I want i

Re: capture information for internal generated mails

2018-12-20 Thread d tbsky
Matus UHLAR - fantomas > isn;t it easier to save one copy of mail with the logs, instead of two > copied of mail, without logs? > Note that logs will show e.g. when mail was refused by destination server, > mail won't. I don't know if it is easier. but what I want is three information: the mail

Re: dnsbl postscreen - not blocking

2018-12-20 Thread Kai Schaetzl
Stefan Bauer wrote on Wed, 19 Dec 2018 21:10:10 +0100: > the threshold is at default, so 1. This may not be part of your problem, but using a threshold of 1 and then using this weighting scheme is nonsense: postscreen_dnsbl_sites = zen.spamhaus.org*2 bl.spamcop.net*1 b.barracudacentral.org*1 dn

Re: capture information for internal generated mails

2018-12-20 Thread d tbsky
Wietse Venema > ... and sender_bcc_maps add the BCC recipient when email ARRIVES > (i.e. input) not when mail is DELIVERED (i.e. output). > > Wietse thanks for the clarify. so that's my misunderstanding.

Re: capture information for internal generated mails

2018-12-20 Thread Matus UHLAR - fantomas
Wietse Venema d tbsky: > Dominic Raferd > > The incoming email is saved by always_bcc, why is it important to save it again when it is relayed (still I presume with the same 'To:' header, but different envelope recipient) to gsmtp? You can find some information about the relay transaction i

Re: capture information for internal generated mails

2018-12-20 Thread d tbsky
Wietse Venema > > d tbsky: > > Dominic Raferd > > > The incoming email is saved by always_bcc, why is it important to save it > > > again when it is relayed (still I presume with the same 'To:' header, but > > > different envelope recipient) to gsmtp? You can find some information > > > about

Re: capture information for internal generated mails

2018-12-20 Thread Wietse Venema
d tbsky: > Dominic Raferd > > The incoming email is saved by always_bcc, why is it important to save it > > again when it is relayed (still I presume with the same 'To:' header, but > > different envelope recipient) to gsmtp? You can find some information about > > the relay transaction in the

Re: capture information for internal generated mails

2018-12-20 Thread Wietse Venema
d tbsky: > hi: >I want to bcc all mails for archive purpose. one kind of mail is like > below: > >outside user (a...@gmail.com) mail to -> postfix alias with settings > to forward outside (myal...@example.com) -> forward to outside user > (b...@gmail.com) > >"always_bcc" and "recip

Re: capture information for internal generated mails

2018-12-20 Thread Bastian Blank
On Thu, Dec 20, 2018 at 08:02:12PM +0800, d tbsky wrote: > I understand the information is in the log. but I need to archive this > information for auditing in the future. so I need this information > when postfix bcc the mail. > with other kind of received mails, I can use bcc_recipient_maps and >

Re: capture information for internal generated mails

2018-12-20 Thread d tbsky
Dominic Raferd > The incoming email is saved by always_bcc, why is it important to save it > again when it is relayed (still I presume with the same 'To:' header, but > different envelope recipient) to gsmtp? You can find some information about > the relay transaction in the mail log (smtp). Ex

Re: capture information for internal generated mails

2018-12-20 Thread Dominic Raferd
On Thu, 20 Dec 2018 at 11:19, d tbsky wrote: > Dominic Raferd > > > > On Thu, 20 Dec 2018 at 09:22, d tbsky wrote: > >> > >> hi: > >>I want to bcc all mails for archive purpose. one kind of mail is > like below: > >> > >>outside user (a...@gmail.com) mail to -> postfix alias with setti

Re: capture information for internal generated mails

2018-12-20 Thread d tbsky
Dominic Raferd > > On Thu, 20 Dec 2018 at 09:22, d tbsky wrote: >> >> hi: >>I want to bcc all mails for archive purpose. one kind of mail is like >> below: >> >>outside user (a...@gmail.com) mail to -> postfix alias with settings >> to forward outside (myal...@example.com) -> forward t

Re: capture information for internal generated mails

2018-12-20 Thread Dominic Raferd
On Thu, 20 Dec 2018 at 09:22, d tbsky wrote: > hi: >I want to bcc all mails for archive purpose. one kind of mail is like > below: > >outside user (a...@gmail.com) mail to -> postfix alias with settings > to forward outside (myal...@example.com) -> forward to outside user > (b...@gmail.

capture information for internal generated mails

2018-12-20 Thread d tbsky
hi: I want to bcc all mails for archive purpose. one kind of mail is like below: outside user (a...@gmail.com) mail to -> postfix alias with settings to forward outside (myal...@example.com) -> forward to outside user (b...@gmail.com) "always_bcc" and "recipient_bcc_maps" won't capture