Re: Disabling TLSv1
> On 5 March 2020, at 17:15, Viktor Dukhovni wrote: > > On Thu, Mar 05, 2020 at 03:57:59PM -0800, Doug Hardie wrote: > >> Small mail server with 3 weeks of logs: >> >> 1761 TLSv1 >> 18 TLSv1.1 >> 20414 TLSv1.2 >> 6343 TLSv1.3 >> >> That's not what I expected. I thought v1 and v1.1 would be reversed. >> There is a complete spectrum of ciphers being used with v1 including >> some of the most recent. I am using the defaults for the protocols >> and ciphers. > > The reversal is expected, the most widely used TLS implementations that > support TLSv1.1 also support TLSv1.2, and so you see very little use of > TLSv1.1. The ancient stacks that haven't yet adopted TLS1.2, mostly > never got to TLSv1.1 either. > > An interesting question in your case is what fraction of the TLSv1 > connections are non-spam. Perhaps you're able to correlate the TLSv1 > connections with legitimate vs. junk email. The code to scan the logs is a bit convoluted. I have it running, but there are 44K connections to check so it will undoubtly run all night. It has completed 1200 so far in about 11 minutes. So it will take over 6.5 hours to complete. -- Doug
Re: Disabling TLSv1
On Fri, Mar 06, 2020 at 02:16:42AM +, Allen Coates wrote: > Virtually all my TLSv1 connections come from this mailing list... > > Would there be any mileage in disabling OUTBOUND TLSv1 connections while > accepting inbound for a little while longer? You can certainly configure each direction as appropriate. In the outbound direction you also have the choice of per-destination policy. So yes, it is not unreasonable (though not that compelling, or worth much effort) to disable TLSv1 by default, and then perhaps enable it for just any sites where TLS handshakes start to fail. -- Viktor.
Re: Disabling TLSv1
Virtually all my TLSv1 connections come from this mailing list...
Would there be any mileage in disabling OUTBOUND TLSv1 connections while
accepting inbound for a little while longer?
Allen C
On 05/03/2020 20:08, ratatouille wrote:
> Hello!
>
> Don't know why TLSv1 is still offered on our servers running
>
> mail_version = 2.11.3
> smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
>
> but a scan by ssllabs.com or with testssl.sh shows TLSv1 is still supported.
>
> I am not sure what's wrong. What do I miss?
>
> Other parameters I set:
> smtpd_tls_CApath = /var/lib/ca-certificates/pem
> smtpd_tls_ask_ccert = yes
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/letsencrypt/live/bitcorner.de/fullchain.pem
> smtpd_tls_ciphers = high
> smtpd_tls_dh1024_param_file = ${config_directory}/dhparams.pem
> smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH,
> EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA, secp224r1,
> ECDHE-RSA-DES-CBC3-SHA
> smtpd_tls_key_file = /etc/letsencrypt/live/bitcorner.de/privkey.pem
> smtpd_tls_loglevel = 1
> smtpd_tls_mandatory_ciphers = high
> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1
> smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
> smtpd_tls_received_header = yes
> smtpd_tls_req_ccert = no
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_database =
> btree:/var/lib/postfix/smtpd_tls_session_cache
> smtpd_tls_session_cache_timeout = 3600s
>
> Regards
>
> Andreas
>
Re: Disabling TLSv1
On Thu, Mar 05, 2020 at 03:57:59PM -0800, Doug Hardie wrote: > Small mail server with 3 weeks of logs: > >1761 TLSv1 > 18 TLSv1.1 > 20414 TLSv1.2 >6343 TLSv1.3 > > That's not what I expected. I thought v1 and v1.1 would be reversed. > There is a complete spectrum of ciphers being used with v1 including > some of the most recent. I am using the defaults for the protocols > and ciphers. The reversal is expected, the most widely used TLS implementations that support TLSv1.1 also support TLSv1.2, and so you see very little use of TLSv1.1. The ancient stacks that haven't yet adopted TLS1.2, mostly never got to TLSv1.1 either. An interesting question in your case is what fraction of the TLSv1 connections are non-spam. Perhaps you're able to correlate the TLSv1 connections with legitimate vs. junk email. -- Viktor.
Re: Disabling TLSv1
> On 5 March 2020, at 15:26, ratatouille wrote: > > Viktor Dukhovni schrieb am 05.03.20 um 16:44:14 > Uhr: > >> On Thu, Mar 05, 2020 at 09:08:43PM +0100, ratatouille wrote: >> >>> Don't know why TLSv1 is still offered on our servers running >> >> Probably because you're not changing the configuration in the right >> place. Double-check that you're configuring the correct Postfix >> instance (if using multiple instances) and that there are no >> master.cf overrides that trump the main.cf settings. >> >>> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1 >>> smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1 > > Found out if I want to disable TLSv1.1 too I just have to do so. > smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 > and suddenly it works ;) > >> Other than test TLS connections, do you still legitimate inbound email >> in your logs (looking over a week or more of logs) delivered with TLSv1? > > I have just too TLSv1 connections this month: > ... > 11 TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits) > 9 TLSv1.2 with cipher CAMELLIA256-SHA (256/256 bits) > 9 TLSv1.2 with cipher CAMELLIA128-SHA (128/128 bits) > 9 TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits) > 8 TLSv1.1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits) > 8 TLSv1.1 with cipher AES256-SHA (256/256 bits) > 8 TLSv1.1 with cipher AES128-SHA (128/128 bits) > 7 TLSv1.1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits) > 7 TLSv1.1 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits) > 7 TLSv1.1 with cipher DHE-RSA-AES128-SHA (128/128 bits) > 7 TLSv1.1 with cipher CAMELLIA256-SHA (256/256 bits) > 7 TLSv1.1 with cipher CAMELLIA128-SHA (128/128 bits) > 4 TLSv1.2 with cipher ECDHE-RSA-DES-CBC3-SHA (112/168 bits) > 2 TLSv1.2 with cipher DES-CBC3-SHA (112/168 bits) > 1 TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) > 1 TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits) Small mail server with 3 weeks of logs: 1761 TLSv1 18 TLSv1.1 20414 TLSv1.2 6343 TLSv1.3 0 SSL That's not what I expected. I thought v1 and v1.1 would be reversed. There is a complete spectrum of ciphers being used with v1 including some of the most recent. I am using the defaults for the protocols and ciphers. -- Doug >
Re: Disabling TLSv1
On Fri, Mar 06, 2020 at 12:26:06AM +0100, ratatouille wrote:
> I have just too TLSv1 connections this month:
> ...
> 11 TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)
> 9 TLSv1.2 with cipher CAMELLIA256-SHA (256/256 bits)
> 9 TLSv1.2 with cipher CAMELLIA128-SHA (128/128 bits)
> 9 TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
> 8 TLSv1.1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
> 8 TLSv1.1 with cipher AES256-SHA (256/256 bits)
> 8 TLSv1.1 with cipher AES128-SHA (128/128 bits)
> 7 TLSv1.1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)
> 7 TLSv1.1 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits)
> 7 TLSv1.1 with cipher DHE-RSA-AES128-SHA (128/128 bits)
> 7 TLSv1.1 with cipher CAMELLIA256-SHA (256/256 bits)
> 7 TLSv1.1 with cipher CAMELLIA128-SHA (128/128 bits)
> 4 TLSv1.2 with cipher ECDHE-RSA-DES-CBC3-SHA (112/168 bits)
> 2 TLSv1.2 with cipher DES-CBC3-SHA (112/168 bits)
> 1 TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
> 1 TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
That's two out of not very many total, are these actual message
deliveries, or just probes (tests)?
> > If not, then perhaps disabling TLSv1 will be harmless, but if you do,
> > perhaps prod the senders to upgrade first, before you prevent them
> > from establishing TLS connections to your MTA.
>
> internet.nl says TLS 1.1 should be phased out and criticises this.
Just because they say it, doesn't mean it is actually the wise thing to do.
> It also critcises the key exchange paramert DH-4096 as insufficient
See above.
> I just created that key and made it available with
> smtpd_tls_dh1024_param_file = ${config_directory}/dh_4096.pem
Frankly, 2048-bit DH is quite sufficient, and 4096 is slow, and not be
supported in some client stacks.
> Ok, thank you very much! Competent as always. I'll keep TLSv1 enabled
> for now.
You can keep an eye on your logs and decide when it is time to drop
support. The most important thing is supporting stronger options that
most clients will negotiate. Removing weaker options is less of a
priority except when they enable a downgrade attack.
In the case of TLSv1 there's no known (to me anyway) downgrade attack
from TLSv1.2. SMTP MTAs don't do TLS version fallback, like browsers
used to do. There's no urgent need to drop support TLSv1 inbound.
Just make sure that you support at least TLSv1.2, and ignore the
checklists that try to shame you for leaving TLSv1 enabled.
--
Viktor.
Re: Disabling TLSv1
Viktor Dukhovni schrieb am 05.03.20 um 16:44:14
Uhr:
> On Thu, Mar 05, 2020 at 09:08:43PM +0100, ratatouille wrote:
>
> > Don't know why TLSv1 is still offered on our servers running
>
> Probably because you're not changing the configuration in the right
> place. Double-check that you're configuring the correct Postfix
> instance (if using multiple instances) and that there are no
> master.cf overrides that trump the main.cf settings.
>
> > smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1
> > smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
Found out if I want to disable TLSv1.1 too I just have to do so.
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
and suddenly it works ;)
> It is not yet a good idea to disable TLSv1 in SMTP. But if you must
> degrade[1] your SMTP security for some clients to make sure that all the
> check boxes come out green, then the above should be enough, provided it
> is set in the right place. I can confirm that bitclusive.de still
> supports TLSv1:
>
> $ posttls-finger -c -Lsummary -p TLSv1 bitclusive.de
> posttls-finger: Verified TLS connection established to
> smtp.bitclusive.de[2a03:4000:33:430:d423:c2ff:fe3d:b540]:25: TLSv1 with
> cipher ECDHE-RSA-AES256-SHA (256/256 bits)
>
> $ posttls-finger -c -Lsummary -o inet_protocols=ipv4 -p TLSv1
> bitclusive.de
> posttls-finger: Verified TLS connection established to
> smtp.bitclusive.de[92.60.38.182]:25: TLSv1 with cipher ECDHE-RSA-AES256-SHA
> (256/256 bits)
>
> Other than test TLS connections, do you still legitimate inbound email
> in your logs (looking over a week or more of logs) delivered with TLSv1?
I have just too TLSv1 connections this month:
...
11 TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)
9 TLSv1.2 with cipher CAMELLIA256-SHA (256/256 bits)
9 TLSv1.2 with cipher CAMELLIA128-SHA (128/128 bits)
9 TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
8 TLSv1.1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
8 TLSv1.1 with cipher AES256-SHA (256/256 bits)
8 TLSv1.1 with cipher AES128-SHA (128/128 bits)
7 TLSv1.1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)
7 TLSv1.1 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits)
7 TLSv1.1 with cipher DHE-RSA-AES128-SHA (128/128 bits)
7 TLSv1.1 with cipher CAMELLIA256-SHA (256/256 bits)
7 TLSv1.1 with cipher CAMELLIA128-SHA (128/128 bits)
4 TLSv1.2 with cipher ECDHE-RSA-DES-CBC3-SHA (112/168 bits)
2 TLSv1.2 with cipher DES-CBC3-SHA (112/168 bits)
1 TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
1 TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
> If not, then perhaps disabling TLSv1 will be harmless, but if you do,
> perhaps prod the senders to upgrade first, before you prevent them
> from establishing TLS connections to your MTA.
internet.nl says TLS 1.1 should be phased out and criticises this.
It also critcises the key exchange paramert DH-4096 as insufficient
I just created that key and made it available with
smtpd_tls_dh1024_param_file = ${config_directory}/dh_4096.pem
Ok, thank you very much! Competent as always. I'll keep TLSv1 enabled
for now.
--
Regards
Andreas
Re: Disabling TLSv1
Hello,
I tried disabling TLSv1.0 and TLSv1.1 on our Postfix mailservers at the
beginning of the year (since there were advisories that anything older
than 1.2 is considered weak and broken), and it did not end well, there
were numerous complaints from what turned out to be still supported LTS
version of Windows 8 that is supported till 2023 whose Outlooks still
uses the obsolete versions of TLS and their handshakes will fail.
--
S pozdravem,
Daniel Ryšlink
On 05-Mar-20 21:08, ratatouille wrote:
Hello!
Don't know why TLSv1 is still offered on our servers running
mail_version = 2.11.3
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
but a scan by ssllabs.com or with testssl.sh shows TLSv1 is still supported.
I am not sure what's wrong. What do I miss?
Other parameters I set:
smtpd_tls_CApath = /var/lib/ca-certificates/pem
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/bitcorner.de/fullchain.pem
smtpd_tls_ciphers = high
smtpd_tls_dh1024_param_file = ${config_directory}/dhparams.pem
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH,
EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA, secp224r1,
ECDHE-RSA-DES-CBC3-SHA
smtpd_tls_key_file = /etc/letsencrypt/live/bitcorner.de/privkey.pem
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
smtpd_tls_received_header = yes
smtpd_tls_req_ccert = no
smtpd_tls_security_level = may
smtpd_tls_session_cache_database =
btree:/var/lib/postfix/smtpd_tls_session_cache
smtpd_tls_session_cache_timeout = 3600s
Regards
Andreas
Re: Disabling TLSv1
On Thu, Mar 05, 2020 at 09:08:43PM +0100, ratatouille wrote: > Don't know why TLSv1 is still offered on our servers running Probably because you're not changing the configuration in the right place. Double-check that you're configuring the correct Postfix instance (if using multiple instances) and that there are no master.cf overrides that trump the main.cf settings. > smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1 > smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1 It is not yet a good idea to disable TLSv1 in SMTP. But if you must degrade[1] your SMTP security for some clients to make sure that all the check boxes come out green, then the above should be enough, provided it is set in the right place. I can confirm that bitclusive.de still supports TLSv1: $ posttls-finger -c -Lsummary -p TLSv1 bitclusive.de posttls-finger: Verified TLS connection established to smtp.bitclusive.de[2a03:4000:33:430:d423:c2ff:fe3d:b540]:25: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) $ posttls-finger -c -Lsummary -o inet_protocols=ipv4 -p TLSv1 bitclusive.de posttls-finger: Verified TLS connection established to smtp.bitclusive.de[92.60.38.182]:25: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) Other than test TLS connections, do you still legitimate inbound email in your logs (looking over a week or more of logs) delivered with TLSv1? If not, then perhaps disabling TLSv1 will be harmless, but if you do, perhaps prod the senders to upgrade first, before you prevent them from establishing TLS connections to your MTA. -- Viktor. [1] Some clients forced to send in clear text, because they don't do TLSv1.2.
Disabling TLSv1
Hello!
Don't know why TLSv1 is still offered on our servers running
mail_version = 2.11.3
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
but a scan by ssllabs.com or with testssl.sh shows TLSv1 is still supported.
I am not sure what's wrong. What do I miss?
Other parameters I set:
smtpd_tls_CApath = /var/lib/ca-certificates/pem
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/bitcorner.de/fullchain.pem
smtpd_tls_ciphers = high
smtpd_tls_dh1024_param_file = ${config_directory}/dhparams.pem
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH,
EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA, secp224r1,
ECDHE-RSA-DES-CBC3-SHA
smtpd_tls_key_file = /etc/letsencrypt/live/bitcorner.de/privkey.pem
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
smtpd_tls_received_header = yes
smtpd_tls_req_ccert = no
smtpd_tls_security_level = may
smtpd_tls_session_cache_database =
btree:/var/lib/postfix/smtpd_tls_session_cache
smtpd_tls_session_cache_timeout = 3600s
Regards
Andreas
Re: round robin sender_dependent_relayhost_maps
Emanuel Gonzalez: > Hello, > > I have a mail server with one domain and two servers i use to send email > transactional. > > My question is, it's possible configure the parameter > sender_dependent_relayhost_maps with round robin? Generally, Postfix does not support nested tables, so it cannot do selection by sender and then invoke a sender-dependent randmap. Wietse
round robin sender_dependent_relayhost_maps
Hello, I have a mail server with one domain and two servers i use to send email transactional. My question is, it's possible configure the parameter sender_dependent_relayhost_maps with round robin? sender_dependent_default_transport_maps = hash:/etc/postfix/sender_dependant_default_transport.map # sender_dependant_default_transport.map * 192.168.1.1 * 192.168.1.2 relayhost=mydomain:587 Regards,
Re: Install Postfix SHLIBS in Install Directory - how ?
Wietse Venema: > zahn: > > I do not want: /usr/lib/postfix! for the SHLIBS - it MUST be in the > > Installation Directory: /usr/local/postfix > > Then you need to specify that at BUILD time not INSTALL time. > See section 4.3.3 in the INSTALL file. > > Begin quote > To override the default location of Postfix dynamically-linked libraries and > database plugins specify, for example: > > $ make makefiles shared=yes shlib_directory=/usr/local/lib/postfix ... > End quote If you change shlib_directory at install time use one of make install shlib_directory=/some/where ... make upgrade shlib_directory=/some/where ... (editing main.cf is not sufficient; the install/upgrade commands must create the directory with proper permissions). As documented changing shlib_directory at install time may require some ldconfig confuration. Wietse
Re: Install Postfix SHLIBS in Install Directory - how ?
zahn: > I do not want: /usr/lib/postfix! for the SHLIBS - it MUST be in the > Installation Directory: /usr/local/postfix Then you need to specify that at BUILD time not INSTALL time. See section 4.3.3 in the INSTALL file. Begin quote To override the default location of Postfix dynamically-linked libraries and database plugins specify, for example: $ make makefiles shared=yes shlib_directory=/usr/local/lib/postfix ... End quote Wietse
Re: Smtp delivery status filter - not working
Rainer Ruprechtsberger: > Hi, > > I tried to adopt smtp dsn like dokumented here: > http://www.postfix.org/postconf.5.html#default_delivery_status_filter > > Since the example is exactly what I want (so my users get Non delivery > notifications for domains where we refuse to send without transport > encryption but won't offer it earlier) I just c'd. > > However - it does not seem to do anything. Any mail sent to such a > destination still gets a 4.. status. > > Any help debugging whats going on would be appreciated. TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html Thank you for using Postfix. Wietse
Re: problem with transport
Hi Thenx for replay :) You have right I forget add a "-o smtpd_milters" in smtp smtp inet n - n - - smtpd -o content_filter=spamassassin -o smtpd_milters= But Your solution is better On 05.03.2020 12:19, Jaroslaw Rafa wrote: > Dnia 5.03.2020 o godz. 12:06:43 natan maciej milaszewski pisze: >> I use DKIM (added like documentations) >> >> In log i found double added DKIM - because the mail goes back to the >> queue and smtpd_milters tags it again ... >> >> Probably I must create a returns transport with "-o smtpd_milters=" >> But I dont have idea - maby I thing wrong ... > Instead of using spamassassin as a content filter, as in your example, > you have to use spamass-milter, it's a Milter interface to spamassassin. > Then you will avoid double DKIM.
Re: problem with transport
Dnia 5.03.2020 o godz. 12:06:43 natan maciej milaszewski pisze: > > I use DKIM (added like documentations) > > In log i found double added DKIM - because the mail goes back to the > queue and smtpd_milters tags it again ... > > Probably I must create a returns transport with "-o smtpd_milters=" > But I dont have idea - maby I thing wrong ... Instead of using spamassassin as a content filter, as in your example, you have to use spamass-milter, it's a Milter interface to spamassassin. Then you will avoid double DKIM. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
problem with transport
Hi
Sorry about my probably stupid and easy question.
I have one server for outgoing smtp and I added a spamassassin to
filtered outgoing e-mial
This is trivial like
cut master.cf:
start -
smtp inet n - n - - smtpd -o
content_filter=spamassassin
submission inet n - - - - smtpd
-o content_filter=spamassassin
-o smtpd_milters=
-o syslog_name=postfix/submission
spamassassin unix - n n - - pipe
user=filter argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f
${sender} ${recipient}
- end
I use DKIM (added like documentations)
In log i found double added DKIM - because the mail goes back to the
queue and smtpd_milters tags it again ...
Probably I must create a returns transport with "-o smtpd_milters="
But I dont have idea - maby I thing wrong ...
works fine for 587,465 but not 25
log:
http://paste.debian.net/1133556/
I have many vdomain and I don't want to use amavis
Smtp delivery status filter - not working
Hi, I tried to adopt smtp dsn like dokumented here: http://www.postfix.org/postconf.5.html#default_delivery_status_filter Since the example is exactly what I want (so my users get Non delivery notifications for domains where we refuse to send without transport encryption but won't offer it earlier) I just c'd. However - it does not seem to do anything. Any mail sent to such a destination still gets a 4.. status. Any help debugging whats going on would be appreciated. /r -- Rainer Ruprechtsberger Volkshilfe Oberösterreich IT 4020 Linz, Glimpfingerstrasse 48 Tel.: +43 732 3405 123 Mobil.: +43 676 8734 1123 ZVR Zahl: 064371505 Volkshilfe. Wir sind für die Menschen da.
Install Postfix SHLIBS in Install Directory - how ?
Hello All I installed Postfix 3.4.9 with SHLIB support in /usr/local/postfix. In main.cf I set: shlib_directory = /usr/local/postfix/lib On make install: I get the following error: postfix/postfix-script[40500]: fatal: no Postfix shared-library directory /usr/local/postfix/lib! Can I not install the SHLIBS in the Installation Directory? An error in postfix-script ? I do not want: /usr/lib/postfix! for the SHLIBS - it MUST be in the Installation Directory: /usr/local/postfix -- Schöne Grüsse aus Oberdiessbach Martin Zahn Akadia AG Martin Zahn Software Ing. HTL Oracle Certificate Professional Information Technology Fichtenweg 10 CH-3672 Oberdiessbach Tel: +41 79 410 27 87 Web: www.akadia.com E-Mail: martin.z...@akadia.com
