add data from XFORWARD to policy delegation protocol
Hi, there is XFORWARD command (http://www.postfix.org/XFORWARD_README.html) that smtpd and smtp can do. It may be useful to prodvide XFORWARD data to external policy server (http://www.postfix.org/SMTPD_POLICY_README.html) via additional attributes to allow to implement MTA1->MTA2<->policy_server scenarios. Best, Deniss
Re: prioritization in qmgr scheduler
On 2017.08.28. 17:36, Viktor Dukhovni wrote: >>> but only when the destination domain is not a "relay" domain or >>> similar, that is, only if mail for the destination in questin just >>> goes whereever the MX records point with no transport overrides >>> beyond (sender_dependent_default_transport_maps) which selects a >>> sender dependent *default* transport. >> >> I'm using permit_auth_destination and it does not play without >> relay_domains. > > If the destination domain is yours and the senders are remote > untrusted clients, then indeed "default_transport" won't do > unless you're a backup MX host (in that case it is possible > to allow relaying for the domain via "check_recipient_access", > and the default transport will find the right primary MX host). I have domain + list of emails in the domain. with relay_domains recipient's check stops just after foreign domain name found as destination. with check_recipient_access full email list scanned to reject foreign domain. Is this correct ? > >> well, looks like I found few solutions: >> >> 1. change transport using FILTER via check_sender_access in >> smtpd_sender_restrictions - fine until there is no other filter action > > This would be wrong for multi-recipient email when some recipients > are local, or in any case should not be sent to the same destination. not the case for relay box > >> IMO it may be useful to allow alter transport in >> sender_dependent_relayhost_maps as well in future releases of postfix > > No, that would not be a good idea, since transport selection needs to > be recipient based. what is the difference to default_transport /sender_dependent_default_transport_maps ? Why relayhost/sender_dependent_relayhost_maps do not work same way - not include transport as well ?
Re: prioritization in qmgr scheduler
On 2017.08.25. 18:20, Viktor Dukhovni wrote:
>
> Yes, but ...
>
>> relay_transport = smtp:backend
>
> On MX gateway hosts that receive inbound mail, use "relay:..." not
> "smtp:..." for your relay transport, and let outbound mail from
> your system use "smtp". This reduces contention between inbound
> and outbound traffic, in particular slow outbound mail will not
> delay inbound mail.
>
>> relay_domains = mydomain.com
>> sender_dependent_relayhost_maps =
>> inline:{prioritysender.com=smtpfast:backend }
>
> No, because sender_dependent_relayhost_maps (unsurprisingly) only
> changes the relayhost, not the transport. If your priority is by
> origin, and not by destination, you may have to use three Postfix
> instances, with low priority traffic shunted to the default slow
> instance, and high priority traffic to the fast instance, with the
> front end instance acting as a switch to separate the two flows.
>
> Ultimately Postfix transport selection and concurrency limits are
> (correctly) destination based, so to implement sender-dependent
> behaviour you need to split the flow by sender, which can only be
> done by handling off to another MTA (instance) with sender-dependent
> relay settings.
>
> You could use:
>
>
> http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
>
> but only when the destination domain is not a "relay" domain or
> similar, that is, only if mail for the destination in questin just
> goes whereever the MX records point with no transport overrides
> beyond (sender_dependent_default_transport_maps) which selects a
> sender dependent *default* transport.
>
I'm using permit_auth_destination and it does not play without
relay_domains.
well, looks like I found few solutions:
1. change transport using FILTER via check_sender_access in
smtpd_sender_restrictions - fine until there is no other filter action
2. alter nexthop with sender_dependent_relayhost_maps - require
additional address on the backend
As I understand concurrency limits will differ from ones on default
route in both cases.
IMO it may be useful to allow alter transport in
sender_dependent_relayhost_maps as well in future releases of postfix
Re: prioritization in qmgr scheduler
On 2017.08.25. 14:45, Wietse Venema wrote:
> If you must use a single queue, then you will have to increase the
> active queue size so that it can absorb the full content of a peak.
> This will increase the memory usage by the queue manager.
>
> The default is:
> qmgr_message_active_limit = 2
>
> How large you can go is system-dependent. Try 10x.
>
> Second, adding a dedicated master.cf transport for the domain will
> reduce scheduling competition.
>
Thanx, this looks useful
Should config looks like following ?
smtpfast unix - - n - - smtp
-o default_destination_concurrency_limit = 20
qmgr_message_active_limit = 20
relay_domains = mydomain.com
relay_transport = smtp:backendsender_dependent_relayhost_maps = inline:{
prioritysender.com=smtpfast:backend }
Re: prioritization in qmgr scheduler
On 2017.08.23. 15:28, Wietse Venema wrote: > Deniss: >> Hello, >> >> I looking for a way to speed up delivery for specified sender's domain >> when incoming queue is overloaded. > > When the road to the airport is clogged, everyone has to wait. > Yes, using a different queue is like building a different road. > Then, one road will hopefully not be congested. > well, I want fast lane for certain domain indeed. I looking for a way to implement this with no dedicated postfix instance. I feel there is a way with restriction classes + dedicated qmgr or smtp service(s) let me explain my setup: I have postfix as frontend to absorb incoming messages as fast as possible. Then I have slow smtp backend. Postfix limits delivery to backend with smtp_destination_concurrency_limit = 2 This works pretty fine allowing to not oveload backend on peaks - messages become queued at frontend and delivered with some delay to backend. But now I want to deliver certain domain with no delay. Is it possible to catch the sender's domain with restriction classes of postfix and pass a message to dedicated smtp process where smtp_destination_concurrency_limit is not limited ? May be there is way to force qmgr to select messages from the domain in first place when it takes messages from queue for delivery ? Best, Deniss
prioritization in qmgr scheduler
Hello, I looking for a way to speed up delivery for specified sender's domain when incoming queue is overloaded. I have idea how to achieve this by using another postfix instance and looping messages through it. May be it is possible to configure qmgr scheduler to prioritize messages by senders domain or run another qmgr for specific domain to pass messages in first place on same postfix instance ? Deniss
Re: TLS1.2 issue with postfix and windows
On 2013.10.21. 23:31, Viktor Dukhovni wrote: Once again after the handshake completes. When I try: $ posttls-finger -t30 -T 180 -c -Ldebug [mail.co.inbox.lv] posttls-finger: initializing the client-side TLS engine posttls-finger: Connected to mail.co.inbox.lv[195.13.218.205]:25 posttls-finger: setting up TLS connection to mail.co.inbox.lv[195.13.218.205]:25 posttls-finger: mail.co.inbox.lv[195.13.218.205]:25: TLS cipher list aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL posttls-finger: SSL_connect:before/connect initialization posttls-finger: SSL_connect:SSLv2/v3 write client hello A posttls-finger: SSL_connect:SSLv3 read server hello A posttls-finger: mail.co.inbox.lv[195.13.218.205]:25: depth=0 verify=0 subject=/C=LV/ST=VIDZEME/L=RIGA/O=SIA INBOKSS/CN=office.co.inbox.lv/emailAddress=adm...@co.inbox.lv posttls-finger: mail.co.inbox.lv[195.13.218.205]:25: depth=0 verify=0 subject=/C=LV/ST=VIDZEME/L=RIGA/O=SIA INBOKSS/CN=office.co.inbox.lv/emailAddress=adm...@co.inbox.lv posttls-finger: mail.co.inbox.lv[195.13.218.205]:25: depth=0 verify=0 subject=/C=LV/ST=VIDZEME/L=RIGA/O=SIA INBOKSS/CN=office.co.inbox.lv/emailAddress=adm...@co.inbox.lv posttls-finger: SSL_connect:SSLv3 read server certificate A posttls-finger: SSL_connect:SSLv3 read server done A posttls-finger: SSL_connect:SSLv3 write client key exchange A posttls-finger: SSL_connect:SSLv3 write change cipher spec A posttls-finger: SSL_connect:SSLv3 write finished A posttls-finger: SSL_connect:SSLv3 flush data posttls-finger: SSL_connect:SSLv3 read finished A posttls-finger: certificate verification failed for mail.co.inbox.lv[195.13.218.205]:25: untrusted issuer /C=LV/ST=VIDZEME/O=SIA INBOKSS/CN=*.inbox.lv/emailAddress=adm...@co.inbox.lv posttls-finger: mail.co.inbox.lv[195.13.218.205]:25: subject_CN=office.co.inbox.lv, issuer_CN=*.inbox.lv, fingerprint=F6:57:C5:1E:51:82:15:E6:2B:E5:D7:A2:2C:1E:91:27:C5:B5:40:02, pkey_fingerprint=C4:B4:12:4B:0F:1A:53:35:6B:27:70:D5:60:19:16:0B:66:48:B4:DD posttls-finger: Untrusted TLS connection established to mail.co.inbox.lv[195.13.218.205]:25: TLSv1.1 with cipher RC4-MD5 (128/128 bits) I get RC4-MD5, which is likely the only working ciphersuite on this server. Make sure your smtp_tls_loglevel=1, and report the TLS connection established log entries. When I set the ciphers to high for this destination, I get: ... posttls-finger: Untrusted TLS connection established to mail.co.inbox.lv[195.13.218.205]:25: TLSv1 with cipher DES-CBC3-SHA (168/168 bits) posttls-finger: SSL3 alert write:fatal:protocol version posttls-finger: warning: TLS library problem: 28603:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:/home/builds/ab/HEAD/src/crypto/external/bsd/openssl/dist/ssl/s3_pkt.c:339: posttls-finger: warning: lost connection while sending QUIT command So this is definitely a version of the broken Windows TLS ciphersuite problem. If you must use TLS with this server, disable TLSv1.2 and 3DES, allow medium grade ciphers (i.e. RC4) and make sure your policy tables, ... are postmapped. it was clear from begining that disabling tls1.2 fixes the issue. the question is if it possible to fix the problem mangling cipher suites list without complete tls1.2 removing ? where tool posttls-finger may be obtained ? Do tell the remote site administrator their server is a mess.
Re: TLS1.2 issue with postfix and windows
Date: From: Subject: [none] On Sun, Oct 20, 2013 at 08:55:33PM +0300, Deniss wrote: I have an issue with postfix-2.10.2 and latest MS windows/exchange/outlook: SSL connection cannot be negotiated with default settings, there is an error in postfix log: Oct 20 20:13:41 box postfix/smtp[21730]: warning: TLS library problem: 21730:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337: Please DO NOT omit critical related information. What was the final error logged by the Postfix SMTP client for this delivery? This generally records the SMTP protocol stage at which the error occurred. In particular, whether the handshake completed and the error happend during data transfer or not. Show all related logging from process 21730. well, full log shows: Oct 21 21:35:01 box postfix/smtp[19887]: warning: TLS library problem: 19887:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337: Oct 21 21:35:01 box postfix/smtp[19887]: 9057812402F: to=s...@co.inbox.lv, relay=mail.co.inbox.lv[195.13.218.205]:25, delay=0.05, delays=0.01/0.01/0.03/0, dsn=4.4.2, status=deferred (lost connection with mail.co.inbox.lv[195.13.218.205] while sending MAIL FROM) By brief investigation looks like schannel drops connection if first tried cipher suite does not work and not try another ciphers Wild guess: http://archives.neohapsis.com/archives/postfix/2013-10/thread.html#289 i tried to make use of smtp_tls_exclude_ciphers = DES-CBC3-SHA and got TLS failure and the message sent in plain wire (i belive): Oct 21 21:43:41 box postfix/smtp[20925]: SSL_connect error to mail.co.inbox.lv[195.13.218.205]:25: lost connection Oct 21 21:43:41 box postfix/smtp[20925]: 7613D12402F: Cannot start TLS: handshake failure Oct 21 21:43:41 box postfix/smtp[20925]: 7613D12402F: to=s...@co.inbox.lv, relay=mail.co.inbox.lv[195.13.218.205]:25, delay=0.38, delays=0.01/0.01/0.02/0.35, dsn=2.6.0, status=sent (250 2.6.0 526575df.8070...@sad.lv Queued mail for delivery) Oct 21 21:43:41 got postfix/qmgr[20393]: 7613D12402F: removed I tried openssl s_client -connect mail.co.inbox.lv:25 -starttls smtp -tls1_2: CONNECTED(0003) 2714154632:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 437 bytes and written 7 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher: Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1382382209 Timeout : 7200 (sec) Verify return code: 0 (ok) --- but it works just fine with -tls1 Protocol : TLSv1 Cipher: DES-CBC3-SHA Moreover i tried smtp_tls_policy_maps = hash:/etc/postfix/tls_map with # cat /etc/postfix/tls_map [mail.co.inbox.lv]:25 secure ciphers=medium exclude=3DES with no lucks Oct 21 22:13:32 box postfix/smtp[24060]: warning: TLS library problem: 24060:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337: Oct 21 22:13:32 box postfix/smtp[24060]: D912212402E: to=s...@co.inbox.lv, relay=mail.co.inbox.lv[195.13.218.205]:25, delay=0.04, delays=0/0.01/0.02/0, dsn=4.4.2, status=deferred (lost connection with mail.co.inbox.lv[195.13.218.205] while sending MAIL FROM) if you provide more context, you'll get better help. BTW Digest of postfix-users list does not allow to reply to the messages :(
TLS1.2 issue with postfix and windows
Hello, I have an issue with postfix-2.10.2 and latest MS windows/exchange/outlook: SSL connection cannot be negotiated with default settings, there is an error in postfix log: Oct 20 20:13:41 box postfix/smtp[21730]: warning: TLS library problem: 21730:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337: When TLS1.2 is disabled in postfix by smtp_tls_protocols = !SSLv2, !TLSv1.2 smtp_tls_mandatory_protocols = !SSLv2, !TLSv1.2 smtpd_tls_protocols = !SSLv2, !TLSv1.2 smtpd_tls_mandatory_protocols = !SSLv2, !TLSv1.2 or in windows by turning off tls1.2 in schannel the problem disappears. By brief investigation looks like schannel drops connection if first tried cipher suite does not work and not try another ciphers any solution ? Best, Deniss
