[PATCH] unionmap error handling
Hi,
while investigation unexpected bounces, I noticed that the unionmap did not
handle errors of submaps properly. If a submap generated an error, the
unionmap would not.
I tested this with an LDAP map, where the LDAP server was *not* reachable.
Configuring virtual_alias_maps as:
virtual_alias_maps = ldap:/etc/postfix/ldap-virtual.cf
would result in '451 Temporary lookup failure', while configuring it as
virtual_alias_maps = unionmap:{ldap:/etc/postfix/ldap-virtual.cf}
would result in '550 Recipient address rejected: User unknown in virtual
alias table'.
The attached patch fixes that, by making the unionmap return the first
error it gets from one of the submaps.
Thanks,
Roel
diff -pruN a/src/util/dict_union.c b/src/util/dict_union.c
--- a/src/util/dict_union.c 2014-10-21 01:53:04.0 +0200
+++ b/src/util/dict_union.c 2016-09-15 11:35:47.669767063 +0200
@@ -81,8 +81,11 @@ static const char *dict_union_lookup(DIC
for (cpp = dict_union->map_union->argv; (dict_type_name = *cpp) != 0;
cpp++) {
if ((map = dict_handle(dict_type_name)) == 0)
msg_panic("%s: dictionary \"%s\" not found", myname,
dict_type_name);
- if ((result = dict_get(map, query)) == 0)
- continue;
+ result = dict_get(map, query);
+ if (map->error < 0)
+ DICT_ERR_VAL_RETURN(dict, map->error, 0);
+ if (result == 0)
+ return;
if (VSTRING_LEN(dict_union->re_buf) > 0)
VSTRING_ADDCH(dict_union->re_buf, ',');
vstring_strcat(dict_union->re_buf, result);
Re: [PATCH] unionmap error handling
Roel van Meer:
> Hi,
>
> while investigation unexpected bounces, I noticed that the unionmap did not
> handle errors of submaps properly. If a submap generated an error, the
> unionmap would not.
Cool. Can you also check how pipemap handles this case?
Wietse
> I tested this with an LDAP map, where the LDAP server was *not* reachable.
> Configuring virtual_alias_maps as:
>
> virtual_alias_maps = ldap:/etc/postfix/ldap-virtual.cf
>
> would result in '451 Temporary lookup failure', while configuring it as
>
> virtual_alias_maps = unionmap:{ldap:/etc/postfix/ldap-virtual.cf}
>
> would result in '550 Recipient address rejected: User unknown in virtual
> alias table'.
>
> The attached patch fixes that, by making the unionmap return the first
> error it gets from one of the submaps.
>
> Thanks,
>
> Roel
Content-Description: unionmap-error.patch
[ Attachment, skipping... ]
Re: mysql lookup table and utf8
Phil Stracchino: [ Charset windows-1252 converted... ] > On 09/14/16 19:29, Wietse Venema wrote: > Perhaps Postfix needs to try to explicitly load the default config > location when no override is set. > >>> > >>> How do we do that, without hard-coding '/etc/my.cnf' into Postfix? > >>> That pathname is almost certainly incorrect on systems like *BSD > >>> that install ports configuration files outside the base system > >>> directory tree. > >> > >> It will even be incorrect on many Linux distributions (Ubuntu for > >> example), many of which default to /etc/mysql/ instead of /etc/. > > > > Isn't this pathname defined in some #include file? How do other > > client programs find out where the default location is? > > Well, it's supposed to Just Work if they're using libmysqlclient. I'm > not sure where to get the information of NOT using libmysqlclient, other > than just searching likely locations. FYI, Postfix uses libmysqlclient. So what's up with not reading the default config file? Wietse
Re: [PATCH] unionmap error handling
Wietse Venema writes: > while investigation unexpected bounces, I noticed that the unionmap did not > handle errors of submaps properly. If a submap generated an error, the > unionmap would not. Cool. Can you also check how pipemap handles this case? I checked and pipemap shows correct behaviour (e.g. if one of the submaps is an LDAP map that returns an error then the map itself also returns that error). Thanks, Roel
Re: mysql lookup table and utf8
On Thu, Sep 15, 2016 at 06:49:08AM -0400, Wietse Venema wrote: FYI, Postfix uses libmysqlclient. So what's up with not reading the default config file? Can it be the usual chroot problem? Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH V2] unionmap error handling
Hi Wietse,
I noticed an error in the patch. Attached you'll find the corrected version.
Thanks,
Roel
diff -pruN a/src/util/dict_union.c b/src/util/dict_union.c
--- a/src/util/dict_union.c 2014-10-21 01:53:04.0 +0200
+++ b/src/util/dict_union.c 2016-09-15 13:14:54.961550046 +0200
@@ -81,7 +81,10 @@ static const char *dict_union_lookup(DIC
for (cpp = dict_union->map_union->argv; (dict_type_name = *cpp) != 0;
cpp++) {
if ((map = dict_handle(dict_type_name)) == 0)
msg_panic("%s: dictionary \"%s\" not found", myname,
dict_type_name);
- if ((result = dict_get(map, query)) == 0)
+ result = dict_get(map, query);
+ if (map->error < 0)
+ DICT_ERR_VAL_RETURN(dict, map->error, 0);
+ if (result == 0)
continue;
if (VSTRING_LEN(dict_union->re_buf) > 0)
VSTRING_ADDCH(dict_union->re_buf, ',');
Cannot start TLS: handshake failure when relaying through Exchange 2007
After two years of successful emails sent by postfix through our exchange 2007 server i have started having problems. I did update debian 7 to debian 8, so i don't know what postfix/openssl version i had back then. Postfix itself gives out these errors: Sep 14 11:52:52 mar-zabbix postfix/pickup[3886]: 0891F5006D1: uid=33 from= Sep 14 11:52:52 mar-zabbix postfix/cleanup[10371]: 0891F5006D1: message-id= Sep 14 11:52:52 mar-zabbix postfix/qmgr[1454]: 0891F5006D1: from=, size=2779, nrcpt=1 (queue active) Sep 14 11:52:53 mar-zabbix postfix/pickup[10376]: 32D975004EE: uid=33 from= Sep 14 11:52:53 mar-zabbix postfix/cleanup[10371]: 32D975004EE: message-id= Sep 14 11:52:53 mar-zabbix postfix/qmgr[1454]: 32D975004EE: from=, size=3019549, nrcpt=1 (queue active) Sep 14 11:52:53 mar-zabbix postfix/pickup[10376]: A4DA150056C: uid=33 from= Sep 14 11:52:53 mar-zabbix postfix/cleanup[10371]: A4DA150056C: message-id= Sep 14 11:52:54 mar-zabbix postfix/qmgr[1454]: A4DA150056C: from=, size=3017969, nrcpt=1 (queue active) Sep 14 11:52:54 mar-zabbix postfix/smtp[10382]: SSL_connect error to mar-exch01.mydomain.com[192.168.100.223]:25: lost connection Sep 14 11:52:54 mar-zabbix postfix/smtp[10382]: 32D975004EE: Cannot start TLS: handshake failure Sep 14 11:52:54 mar-zabbix postfix/smtp[10375]: SSL_connect error to mar-exch01.mydomain.com[192.168.100.223]:25: lost connection Sep 14 11:52:54 mar-zabbix postfix/smtp[10375]: 0891F5006D1: Cannot start TLS: handshake failure Sep 14 11:52:54 mar-zabbix postfix/smtp[10382]: SSL_connect error to mar-exch01.mydomain.com[192.168.100.222]:25: lost connection Sep 14 11:52:54 mar-zabbix postfix/smtp[10375]: SSL_connect error to mar-exch01.mydomain.com[192.168.100.222]:25: lost connection Sep 14 11:52:54 mar-zabbix postfix/smtp[10383]: SSL_connect error to mar-exch01.mydomain.com[192.168.100.222]:25: lost connection Sep 14 11:52:54 mar-zabbix postfix/smtp[10383]: A4DA150056C: Cannot start TLS: handshake failure Sep 14 11:52:54 mar-zabbix postfix/smtp[10383]: SSL_connect error to mar-exch01.mydomain.com[192.168.100.223]:25: lost connection Sep 14 11:52:54 mar-zabbix postfix/smtp[10375]: 0891F5006D1: to=, relay=mar-exch01.mydomain.com[192.168.100.222]:25, delay=2.5, delays=0.9/1.3/0.31/0, dsn=4.7.5, status=deferred (Cannot start TLS: handshake failure) Sep 14 11:52:54 mar-zabbix postfix/smtp[10383]: A4DA150056C: to=, relay=mar-exch01.mydomain.com[192.168.100.223]:25, delay=0.94, delays=0.83/0.05/0.05/0, dsn=4.7.5, status=deferred (Cannot start TLS: handshake failure) Sep 14 11:52:54 mar-zabbix postfix/smtp[10382]: 32D975004EE: to=, relay=mar-exch01.mydomain.com[192.168.100.222]:25, delay=2.2, delays=1.7/0.23/0.26/0, dsn=4.7.5, status=deferred (Cannot start TLS: handshake failure) I try to connect through openssl and i get the following (never mind our self signed certificate): openssl s_client -starttls smtp -crlf -connect mar-exch01.mydomain.com:25 CONNECTED(0003) depth=0 CN = mar-exch01.mydomain.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = mar-exch01.mydomain.com verify error:num=27:certificate not trusted verify return:1 depth=0 CN = mar-exch01.mydomain.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=mar-exch01.mydomain.com i:/DC=com/DC=mydomain/CN=seguros --- Server certificate -BEGIN CERTIFICATE- [OMITTED] -END CERTIFICATE- subject=/CN=mar-exch01.mydomain.com issuer=/DC=com/DC=mydomain/CN=seguros --- No client certificate CA names sent --- SSL handshake has read 2073 bytes and written 506 bytes --- New, TLSv1/SSLv3, Cipher is RC4-MD5 Server public key is 1024 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: RC4-MD5 Session-ID: 88047C4AC8A71A35AB320EBEADAFF6A58AE184D2A17B675A2B42254E03E9 Session-ID-ctx: Master-Key: 8FF1A6884F0E831516914A94CB678BAF011CA2E2078472E9286713404C078484967AAF3CB66607058D4218EBCC26EE0E Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1473881827 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- 250 XRDST EHLO 250-mar-exch01.mydomain.com Hello [192.168.3.11] 250-SIZE 10485760 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-AUTH NTLM LOGIN 250-X-EXPS GSSAPI NTLM 250-8BITMIME 250-BINARYMIME 250-CHUNKING 250-XEXCH50 250 XRDST AUTH LOGIN [user in base64] 334 UGFzc3dvcmQ6 [password in base 64] RENEGOTIATING 3073844924:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:637: Postfix is 2.11.3 and openssl 1.0.1t. Is this an openssl bug? Here's the postfix configuration that used to work: main.cf: smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) biff = no append_dot_mydomain = no readme_directory = no smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file = /etc/ssl/private/ssl-cer
Re: Cannot start TLS: handshake failure when relaying through Exchange 2007
For additional clarification, i was able to telnet to our exhange server and authenticate to it just fine: telnet mar-exch01 25 Connected to mar-exch01.mydomain.com. Escape character is '^]'. 220 mar-exch01.mydomain.com Microsoft ESMTP MAIL Service ready at Thu, 15 Sep 2016 08:21:03 -0400 EHLO 250-mar-exch01.mydomain.com Hello [192.168.3.11] 250-SIZE 10485760 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-STARTTLS 250-X-ANONYMOUSTLS 250-AUTH NTLM LOGIN 250-X-EXPS GSSAPI NTLM 250-8BITMIME 250-BINARYMIME 250-CHUNKING 250-XEXCH50 250 XRDST AUTH LOGIN 334 Username: [base64 username] 334 Password: [base64 password] 235 2.7.0 Authentication successful mail from:u...@mydomain.com 250 2.1.0 Sender OK rcpt to:otheru...@mydomain.com 250 2.1.5 Recipient OK data 354 Start mail input; end with . test . 250 2.6.0 <5cea5ff8-146e-417a-8749-28ba35015...@mar-exch01.mydomain.com> Queued mail for delivery. I want the helpdesk software to use postfix to send emails to users in our domain through exchange; at the same time i want exchange to send emails to postfix users when the domain is linuxhost.mydomain.com, which i did through exchange's smtp connector feature. The helpdesk software has a special alias that forwards email from the specified destination account to a perl script that creates/updates a ticket -- View this message in context: http://postfix.1071664.n5.nabble.com/Cannot-start-TLS-handshake-failure-when-relaying-through-Exchange-2007-tp86243p86245.html Sent from the Postfix Users mailing list archive at Nabble.com.
Processing order of canonical maps
Hi, I need some help configuring canonical maps. Suppose you have two lookup tables listed in canonical_maps and each of these tables uses all three pattern types (user@domain, user, @domain). Now from what I see Postfix looks for a match when rewriting addresses in the following order: Look for a match of: - user@domain in the first table - user@domain in the second table - user in the first table - user in the second table - @domain in the first table - @domain in the second table Is there a way to make Postfix do the lookup in the following order instead? Look for a match of: - user@domain in the first table - user in the first table - @domain in the first table - user@domain in the second table - user in the second table - @domain in the second table Thanks. Ondra
Re: Processing order of canonical maps
Ond?ej Lyson?k: > Hi, > > I need some help configuring canonical maps. > > Suppose you have two lookup tables listed in canonical_maps and each of > these tables uses all three pattern types (user@domain, user, @domain). > Now from what I see Postfix looks for a match when rewriting addresses > in the following order: > > Look for a match of: >- user@domain in the first table >- user@domain in the second table >- user in the first table >- user in the second table >- @domain in the first table >- @domain in the second table > > Is there a way to make Postfix do the lookup in the following order instead? > > Look for a match of: >- user@domain in the first table >- user in the first table >- @domain in the first table >- user@domain in the second table >- user in the second table >- @domain in the second table That is not implemented. The code that generates partial queries is separate from the code that searches lookup tables (the same comes up with partial access(5) queries, or even header/body checks. Asking for this to be changed will not automatically make it happen. In the case of LDAP/SQL queries, you can enable the domain filter to avoid the domain-less queries. Wietse
Re: mysql lookup table and utf8
Stephan Seitz: > On Thu, Sep 15, 2016 at 06:49:08AM -0400, Wietse Venema wrote: > >FYI, Postfix uses libmysqlclient. So what's up with not reading > >the default config file? > > Can it be the usual chroot problem? Postfix normally opens tables before chroot() and before dropping root privileges. I would expect that libmysqlclient reads my.cnf during intialization, not at the time of the first query, but this can be verified by running a Postfix process under strace or equivalent (see http://www.postfix.org/DEBUG_README.html). Wietse
Re: Cannot start TLS: handshake failure when relaying through Exchange 2007
On Thu, Sep 15, 2016 at 04:37:47AM -0700, fleon wrote: > After two years of successful emails sent by postfix through our exchange > 2007 server i have started having problems. I did update debian 7 to debian > 8, so i don't know what postfix/openssl version i had back then. In Debian 8 you have a newer version of OpenSSL which supports TLS ciphers. And is patched with various recent security fixes. > Sep 14 11:52:54 mar-zabbix postfix/smtp[10382]: SSL_connect error to > mar-exch01.mydomain.com[192.168.100.223]:25: lost connection > Sep 14 11:52:54 mar-zabbix postfix/smtp[10382]: 32D975004EE: Cannot start > TLS: handshake failure > [ ... start of server connection details ... ] > New, TLSv1/SSLv3, Cipher is RC4-MD5 > Secure Renegotiation IS NOT supported > Protocol : TLSv1 > Cipher: RC4-MD5 Note that your server's idea of "optimal" TLS security is TLSv1 with RC4-MD5. This server is likely of the same vintage that only looks at the topmost 64 ciphers offered by the STARTTLS client, and fails if RC4 is not in one of those top 54 slots. This is exceedingly dated software. it probably does not support AES at all. You *will* need to upgrade in the relatively near future, start planning that now. > Postfix is 2.11.3 and openssl 1.0.1t. Is this an openssl bug? No, just time marching on. In OpenSSL 1.1.0 both RC4 and 3DES TLS cipher support no longer compiled into the library by default. You can temporarily hold back the tide with: smtp_tls_exclude_ciphers = MD5, aDSS, kECDH, kDH, SEED, IDEA, RC2, RC5 smtp_tls_protocols = !SSLv2:!SSLv3 smtp_tls_mandatory_protocols = !SSLv2:!SSLv3 See: https://www.ietf.org/mail-archive/web/tls/current/msg10471.html http://postfix.1071664.n5.nabble.com/What-is-a-good-and-very-secure-configuration-for-public-postfix-server-nowadays-tt76918.html#a76996 > debug_peer_level = 5 Way overkill. The usual "2" is quite enough. > debug_peer_list = [192.168.100.222] No need for that, revert to empty. -- Viktor.
Re: mysql lookup table and utf8
On Thu, Sep 15, 2016 at 09:51:11AM -0400, Wietse Venema wrote: > Stephan Seitz: > > On Thu, Sep 15, 2016 at 06:49:08AM -0400, Wietse Venema wrote: > > >FYI, Postfix uses libmysqlclient. So what's up with not reading > > >the default config file? > > > > Can it be the usual chroot problem? > > Postfix normally opens tables before chroot() and before dropping > root privileges. I would expect that libmysqlclient reads my.cnf > during intialization, not at the time of the first query, but this > can be verified by running a Postfix process under strace or > equivalent (see http://www.postfix.org/DEBUG_README.html). With both LDAP and MySQL (and likely also Postgres), Postfix does not open connections at table initialization time. Connection start is delayed until the first lookup. This gets the associated latency out of the critical path (as does using proxymap). So there are no pre-jail calls into the MySQL libraries, all that happens with the first query. So chroot can be a problem, but in this case the OP had reproducible issues on the command-line with "postmap -q", no chroot there. -- Viktor.
Re: Postfix transport - master_service_disable
On Wed, Sep 14, 2016 at 12:23:17PM -0500, postadmin wrote: > Hoping to clarify if remote transport mappings can be restricted. This sentence employes unusual terminology. It is unlikely to be understood here. Please explain yourself more clearly, avoiding dense jargon. Nobody on this list will know what "restricting remote transport mappings" means. > ... it appears that master_service_disable allows for specific > listeners to be disabled. As does commenting out entries in master.cf, but the ability to easily turn them back on when needed makes "master_service_disable" useful in some cases. > However the type of listener/service specific to transport mappings "587 > submission" is unclear. What is "transport mapping 587 submission". Do you mean the optional (commented out in the stock master.cf file from postfix.org) submission service entry in master.cf? > Essentially transport mappings are currently bypassing the unix spamc. No idea what that means. > If possible please clarify if transport mappings can be restricted or > "forwarded" to the unix spamc. Or this. You'll to explain your goals more clearly. Most importantly explain what you're really trying to achieve, rather than difficulties with a particular, possibly less than ideal approach to getting there. -- Viktor.
Re: mysql lookup table and utf8
On 09/15/16 06:49, Wietse Venema wrote: > Phil Stracchino: >> Well, it's supposed to Just Work if they're using libmysqlclient. I'm >> not sure where to get the information of NOT using libmysqlclient, other >> than just searching likely locations. > > FYI, Postfix uses libmysqlclient. So what's up with not reading > the default config file? In that case, I have no idea why it's not picking up the default config. To the best of my understanding, it should. But having never worked with libmysqlclient directly myself, my understanding may very well be incomplete or wrong, and it's likely there are details I don't know. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: 603.293.8485
RE: Postfix transport - master_service_disable
Viktor I apologize for the confusion. An overview of the smtp connection/transaction is as follows: Remote Server/Client with public IP is configured with the following transport: "domainofserver.org smtp:domainofserver.org:587" Mail from Remote Server/Client is accepted by domainofserver.org & bypasses the postfix spamassassin. The mail server accepting the mail is configured with a the following master.cf filter. "smtp inet n - n - - smtpd -o content_filter=spamassassin" At this point it appears that all mail from "Remote Server/Client" is passed directly without being filtered by the spamassassin. However mail from the internet that is sent via smtp without transport mapping is filtered as anticipated. Hoping to clarify if possible how to reject the Remote Server/Client "transport" mail and if so how what configuration etc are needed. The question specfic to "master_service_disable" was an attempt to determine if the mail is being passed is due to it not being considered "inet" and perhaps due to the transport being considered a postdrop queue. Perhaps an smtpd_command_filter is an option however it is unknown what smtp commands are allowing the mail to be accepted as a "postrdrop queue" localhost.localdomain email instead of an smtp inet mail that is normally processed by spamassassin. Regards Patrick -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Viktor Dukhovni Sent: Thursday, September 15, 2016 9:56 AM To: postfix-users@postfix.org Subject: Re: Postfix transport - master_service_disable On Wed, Sep 14, 2016 at 12:23:17PM -0500, postadmin wrote: > Hoping to clarify if remote transport mappings can be restricted. This sentence employes unusual terminology. It is unlikely to be understood here. Please explain yourself more clearly, avoiding dense jargon. Nobody on this list will know what "restricting remote transport mappings" means. > ... it appears that master_service_disable allows for specific > listeners to be disabled. As does commenting out entries in master.cf, but the ability to easily turn them back on when needed makes "master_service_disable" useful in some cases. > However the type of listener/service specific to transport mappings "587 > submission" is unclear. What is "transport mapping 587 submission". Do you mean the optional (commented out in the stock master.cf file from postfix.org) submission service entry in master.cf? > Essentially transport mappings are currently bypassing the unix spamc. No idea what that means. > If possible please clarify if transport mappings can be restricted or > "forwarded" to the unix spamc. Or this. You'll to explain your goals more clearly. Most importantly explain what you're really trying to achieve, rather than difficulties with a particular, possibly less than ideal approach to getting there. -- Viktor.
Re: Postfix transport - master_service_disable
On Thu, Sep 15, 2016 at 10:36:43AM -0500, postadmin wrote: > Remote Server/Client with public IP is configured with the following > transport: > > "domainofserver.org smtp:domainofserver.org:587" You're providing submission service to suitably authorized clients. Presumably via SASL, client certs or a list of IP addresses in mynetworks. > Mail from Remote Server/Client is accepted by domainofserver.org & bypasses > the postfix spamassassin. That's a choice you make. Should authorized submission mail be spam-filtered or not? > The mail server accepting the mail is configured with a the following > master.cf filter. > > "smtp inet n - n - - smtpd -o > content_filter=spamassassin" That's port 25 non-submission traffic, it get spam-filtered. > At this point it appears that all mail from "Remote Server/Client" is passed > directly without being filtered by the spamassassin. Of course, because the content_filter is defined just for the port 25 inbound MX service via master.cf. You can, if you wish, set content_filter in main.cf to apply to all email, including submission. > However mail from the internet that is sent via smtp without transport > mapping is filtered as anticipated. That is, non-submission mail for your domain from remote domains is filtered, while (at least potentially) outbound mail from authorized submission clients is not. If your trusted users don't send spam, you're fine. > Hoping to clarify if possible how to reject the Remote Server/Client > "transport" mail and if so how what configuration etc are needed. The default Postfix master.cf file has no port 587 submission service. If you do not wish to offer that service, feel free to remove it from master.cf, or # Use *verbatim* service name/type from master.cf # master_service_disable = submission/inet or just change access controls to limit it's use: master.cf: submission .. smtpd ... -o smtpd_relay_restrictions=$mua_relay_restrictions -o smtpd_recipient_restrictions=$mua_recipient_restrictions main.cf: mua_relay_restrictions = permit_mynetworks, reject mua_recipient_restrictions = permit_mynetworks, reject > The question specfic to "master_service_disable" was an attempt to determine > if the mail is being passed is due to it not being considered "inet" and > perhaps due to the transport being > considered a postdrop queue. You're back to meaningless jargon. Seems most likely you don't really understand what you're saying here. > Perhaps an smtpd_command_filter is an option however it is unknown what smtp > commands are allowing the mail to be accepted as a "postrdrop queue" > localhost.localdomain > email instead of an smtp inet mail that is normally processed by > spamassassin. If your unfiltered mail is really coming in via "postdrop" (thus the pickup service), then it is sent locally via the sendmail(1) CLI, and not coming in from the network at all. Perhaps you have a compromised PHP web service on your machine. In which case, submission/587 has nothing to do with it. You're still not describing your real problem. Good luck. -- Viktor.
Re: Effects of very large message_size_limit?
On 2016-09-15 07:19, mro...@insiberia.net wrote: Hi, I'm wondering what the downside of setting a large message_size_limit are? By "large" I mean 30MB, 40MB, 50MB I think sendmail has a default of no restriction for message size - that seems crazy, but maybe I don't understand the risks well enough. accept and bounce imho use multipart mime instead, or cloud storages for fileshareing thunderbird can do this with a plugin dont know if others can make it simple
Re: Cannot start TLS: handshake failure when relaying through Exchange 2007
Thank you Viktor, with your configuration changes now it works again! Indeed, Exchange is running on Windows Server 2003 R2 and an upgrade is overdue. After two years of delay, finally it will get upgraded in two months. -- View this message in context: http://postfix.1071664.n5.nabble.com/Cannot-start-TLS-handshake-failure-when-relaying-through-Exchange-2007-tp86243p86258.html Sent from the Postfix Users mailing list archive at Nabble.com.
RE: Postfix transport - master_service_disable
>Of course, because the content_filter is defined just for the port Ok, Thanks understood. Regards Patrick
Re: Effects of very large message_size_limit?
On 2016-09-14 23:34, Robert Schetterer wrote: Am 15.09.2016 um 07:19 schrieb mro...@insiberia.net: Hi, I'm wondering what the downside of setting a large message_size_limit are? By "large" I mean 30MB, 40MB, 50MB I think sendmail has a default of no restriction for message size - that seems crazy, but maybe I don't understand the risks well enough. some freemailers have a limit of 10 MB, so its perhaps a good choice to set it for outgoing external mail, for inside a higher amount up to 50 sometimes makes sense I'm aware of the range of limits, for example: https://www.outlook-apps.com/maximum-email-size/ But can anyone answer my question - what factors should I consider when increasing the limit in the 30-50MB range (or higher)? Are there drawbacks to doing this?
Re: Effects of very large message_size_limit?
mro...@insiberia.net: > On 2016-09-14 23:34, Robert Schetterer wrote: > > Am 15.09.2016 um 07:19 schrieb mro...@insiberia.net: > >> Hi, I'm wondering what the downside of setting a large > >> message_size_limit are? > >> > >> By "large" I mean 30MB, 40MB, 50MB > >> > >> I think sendmail has a default of no restriction for message size - > >> that > >> seems crazy, but maybe I don't understand the risks well enough. > > > > some freemailers have a limit of 10 MB, so its perhaps a good choice to > > set it for outgoing external mail, for inside a higher amount up to 50 > > sometimes makes sense > > I'm aware of the range of limits, for example: > > https://www.outlook-apps.com/maximum-email-size/ > > But can anyone answer my question - what factors should I consider when > increasing the limit in the 30-50MB range (or higher)? Are there > drawbacks to doing this? Obviously, the size of the file system determines how large your email messages can be. Postfix will stop accepting mail delivery transactions when the free space in the queue directory is less than 1.5 times the message size limit. Wietse
Re: Effects of very large message_size_limit?
On 2016-09-15 13:55, wie...@porcupine.org wrote: mro...@insiberia.net: On 2016-09-14 23:34, Robert Schetterer wrote: > Am 15.09.2016 um 07:19 schrieb mro...@insiberia.net: >> Hi, I'm wondering what the downside of setting a large >> message_size_limit are? >> >> By "large" I mean 30MB, 40MB, 50MB >> >> I think sendmail has a default of no restriction for message size - >> that >> seems crazy, but maybe I don't understand the risks well enough. > > some freemailers have a limit of 10 MB, so its perhaps a good choice to > set it for outgoing external mail, for inside a higher amount up to 50 > sometimes makes sense I'm aware of the range of limits, for example: https://www.outlook-apps.com/maximum-email-size/ But can anyone answer my question - what factors should I consider when increasing the limit in the 30-50MB range (or higher)? Are there drawbacks to doing this? Obviously, the size of the file system determines how large your email messages can be. Postfix will stop accepting mail delivery transactions when the free space in the queue directory is less than 1.5 times the message size limit. I see, so Postfix doesn't experience any bottlenecks or congestion in other ways with 50MB+ attachments? If size of filesystem is the main concern, quotas are easy way to keep it under control. In that case, is there argument against a limit of say 100MB?
Re: Effects of very large message_size_limit?
mro...@insiberia.net: > On 2016-09-15 13:55, wie...@porcupine.org wrote: > > mro...@insiberia.net: > >> On 2016-09-14 23:34, Robert Schetterer wrote: > >> > Am 15.09.2016 um 07:19 schrieb mro...@insiberia.net: > >> >> Hi, I'm wondering what the downside of setting a large > >> >> message_size_limit are? > >> >> > >> >> By "large" I mean 30MB, 40MB, 50MB > >> >> > >> >> I think sendmail has a default of no restriction for message size - > >> >> that > >> >> seems crazy, but maybe I don't understand the risks well enough. > >> > > >> > some freemailers have a limit of 10 MB, so its perhaps a good choice to > >> > set it for outgoing external mail, for inside a higher amount up to 50 > >> > sometimes makes sense > >> > >> I'm aware of the range of limits, for example: > >> > >> https://www.outlook-apps.com/maximum-email-size/ > >> > >> But can anyone answer my question - what factors should I consider > >> when > >> increasing the limit in the 30-50MB range (or higher)? Are there > >> drawbacks to doing this? > > > > Obviously, the size of the file system determines how large your > > email messages can be. Postfix will stop accepting mail delivery > > transactions when the free space in the queue directory is less > > than 1.5 times the message size limit. > > I see, so Postfix doesn't experience any bottlenecks or congestion in > other ways with 50MB+ attachments? If size of filesystem is the main > concern, quotas are easy way to keep it under control. In that case, is > there argument against a limit of say 100MB? The answer depends on how fast your network is, how fast your file system is, whether recently accessed files can be cached in main memory, and what kinds of deep content inspection you're doing. A matchbox-size firewall appliance will struggle with email messages that a beefier box will handle without a sweat. Wietse
test
test -- Atenciosamente, Rodrigo da Silva Cunha
teste
teste -- Atenciosamente, Rodrigo da Silva Cunha
