Restricting relay of attachments
Sorry if this is a bit simple, but I can't seem to figure out how the components fit together. Given the following: 1) MX/Relay machine running postfix: relay.domain1.com 2) Client machine: client.domain2.com I'd like to restrict/deny (5xx permanent error) incoming messages from the Internet to client.domain2.com if they contain attachments. But no such restriction should be applied to other clients or to users on relay.domain1.com. I presume this would be done with some type of header check plus some type of restriction class. If that's true, then I need some help with both. If I don't even have that right, I'll need a some more help. ;-) Thanks, Michael
Possible reasons for lost connection after DATA
Hello, some of my users were complaining about losing incoming mail, namely Amazon shipping notifications, newsletters and such things that they were absolutely sure were sent out, but never reached their inbox. After doing some digging, increasing log verbosity and such, I found a lot of this: [... snip ...] Sep 10 00:06:37 mail postfix/smtpd[23095]: lost connection after DATA (17511 bytes) from smtp-out-127-108.amazon.com[176.32.127.108] Sep 10 00:06:48 mail postfix/smtpd[23111]: lost connection after DATA (22788 bytes) from mail18-92.srv2.de[193.169.181.92] Sep 10 00:13:35 mail postfix/smtpd[23348]: lost connection after DATA (17441 bytes) from smtp-out-127-108.amazon.com[176.32.127.108] Sep 10 00:27:49 mail postfix/smtpd[23454]: lost connection after DATA (22788 bytes) from mail18-97.srv2.de[193.169.181.97] Sep 10 00:31:03 mail postfix/smtpd[23103]: lost connection after DATA (49116 bytes) from quinqueunus.psi.cust-cluster.com[195.140.187.51] Sep 10 00:48:46 mail postfix/smtpd[23890]: lost connection after DATA (22788 bytes) from mail18-98.srv2.de[193.169.181.98] Sep 10 00:51:53 mail postfix/smtpd[23564]: lost connection after DATA (49116 bytes) from quattuorocto.psi.cust-cluster.com[195.140.187.48] Sep 10 01:09:16 mail postfix/smtpd[24565]: lost connection after DATA (17511 bytes) from smtp-out-127-108.amazon.com[176.32.127.108] Sep 10 01:09:44 mail postfix/smtpd[24290]: lost connection after DATA (22788 bytes) from mail18-99.srv2.de[193.169.181.99] Sep 10 01:16:14 mail postfix/smtpd[24674]: lost connection after DATA (17441 bytes) from smtp-out-127-107.amazon.com[176.32.127.107] Sep 10 01:30:44 mail postfix/smtpd[24782]: lost connection after DATA (22788 bytes) from mail18-100.srv2.de[193.169.181.100] Sep 10 01:51:42 mail postfix/smtpd[25198]: lost connection after DATA (22788 bytes) from mail18-105.srv2.de[193.169.181.105] Sep 10 01:54:29 mail postfix/smtpd[24966]: lost connection after DATA (49116 bytes) from quattuorocto.psi.cust-cluster.com[195.140.187.48] Sep 10 02:12:21 mail postfix/smtpd[25784]: lost connection after DATA (17511 bytes) from smtp-out-127-107.amazon.com[176.32.127.107] Sep 10 02:12:42 mail postfix/smtpd[25656]: lost connection after DATA (22788 bytes) from mail18-106.srv2.de[193.169.181.106] Sep 10 02:20:11 mail postfix/smtpd[25892]: lost connection after DATA (17441 bytes) from smtp-out-127-108.amazon.com[176.32.127.108] Sep 10 02:33:41 mail postfix/smtpd[26077]: lost connection after DATA (22788 bytes) from mail18-107.srv2.de[193.169.181.107] Sep 10 02:54:22 mail postfix/smtpd[26178]: lost connection after DATA (49116 bytes) from quinquenulla.psi.cust-cluster.com[195.140.187.50] Sep 10 02:54:40 mail postfix/smtpd[26490]: lost connection after DATA (22788 bytes) from mail18-108.srv2.de[193.169.181.108] Sep 10 03:14:16 mail postfix/smtpd[26585]: lost connection after DATA (49116 bytes) from quinquenulla.psi.cust-cluster.com[195.140.187.50] Sep 10 03:15:39 mail postfix/smtpd[26905]: lost connection after DATA (22788 bytes) from mail18-113.srv2.de[193.169.181.113] Sep 10 03:15:52 mail postfix/smtpd[27091]: lost connection after DATA (17511 bytes) from smtp-out-127-106.amazon.com[176.32.127.106] Sep 10 03:23:15 mail postfix/smtpd[27214]: lost connection after DATA (17441 bytes) from smtp-out-127-107.amazon.com[176.32.127.107] [... snip ...] So to me that looks as if either the external SMTP server closes its connection before it is done with the entire message (the transferred size does not match the size passed through MAIL FROM: SIZE=XYZ), or the connection times out. I can see in the logs and looking at the queue directories that these messages are put in the incoming queue by cleanup, are then found but skipped by qmgr (probably since they are not finished); they lurk in the incoming queue for awhile and disappear about the time the lost connection message is put in the logs. So this points to a timeout. The weird thing is that the data sizes are always the same for the same message-id being delivered, even if it is delivered via different servers from a cluster. If it were a timeout, network problem or such, I'd expect a more or less random value for the received data size, not always exactly the same. This seems to be a new problem (meaning I just recently got aware of it; I don't know when it started, but I do know everything was working fine for years before). This does not seem to be a problem of the sepcific hosts above; in between, I've been getting messages from the same hosts successfully. It seems that some messages go through on the first try, other messages from the same hosts are always losing connection, they never are delivered completely, ultimately resulting in the external host giving up; the message is then lost, and the user never knows about it. The first question is: Can I rule out it's my fault? I don't have traffic shaping or ICMP blocking running on that host, which maybe could cause something like
Re: Possible reasons for lost connection after DATA
Am 10.09.2014 um 09:56 schrieb Sean Durkin: The first question is: Can I rule out it's my fault? have you changed anything last days/month upgrades/updates software hardware ? please send you postfix config , search list archive lost connection after DATA Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: blacklist senders to dead addresses?
On Tue, Sep 09, 2014 at 10:52:38PM -0500, Noel Jones wrote: But it's not too hard to make such a feature with either a policy service (eg. postfwd) or a log scraper (eg. fail2ban or just a shell script) to update a blacklist file. I'm currently setting up an project for a policy daemon at http://www.mtpolicyd.org/ I think a Honeypot plugin is a good idea and i'll add one. - Markus
Re: blacklist senders to dead addresses?
LuKreme: I had a user account on my system many years ago (like 12) that continues to get many email attempts. Is it possible to add servers trying to send to this address to a blacklist. The mail is rejected before Postfix accepts the DATA command. If you must, you can configure an access map (or policy server) action with a 421 or 521 (hang up now) response. Wietse NB: I'm not talking about any no such user error, but this specific user who could not possibly be getting legitimate mail. (and yes, email attempts to this user account have shot up dramatically in the last year). -- I DID NOT SEE ELVIS Bart chalkboard Ep. 7G07
Re: Restricting relay of attachments
On 9/10/2014 1:24 AM, Michael Fox wrote: Sorry if this is a bit simple, but I can’t seem to figure out how the components fit together. Given the following: 1) MX/Relay machine running postfix: relay.domain1.com 2) Client machine: client.domain2.com I’d like to restrict/deny (5xx permanent error) incoming messages from the Internet to client.domain2.com if they contain attachments. But no such restriction should be applied to other clients or to users on relay.domain1.com. I presume this would be done with some type of header check plus some type of restriction class. If that’s true, then I need some help with both. If I don’t even have that right, I’ll need a some more help. ;-) Header_checks and/or restriction classes are the wrong tool for this. You'll need some external milter/content_filter/smtpd_proxy_filter with per-destination controls. - header_checks examine one header at a time, so you can't combine destination + attachment tests. - restriction classes (and other smtpd restrictions) deal with envelope information and cannot determine if an attachment is present.
Re: Restricting relay of attachments
On 9/10/2014 1:24 AM, Michael Fox wrote: I'd like to restrict/deny (5xx permanent error) incoming messages from the Internet to client.domain2.com if they contain attachments. But no such restriction should be applied to other clients or to users on relay.domain1.com. Noel Jones: Header_checks and/or restriction classes are the wrong tool for this. You'll need some external milter/content_filter/smtpd_proxy_filter with per-destination controls. Correct. However, if you have separate mail streams for mail clients (TCP port submission/587 or smtps/465) and for MX service (TCP port 25), then you can apply different policies to each stream. /etc/postfix/main.cf: mua_cleanup_service = mua_cleanup mua_header_checks = ... mua_body_checks = ... /etc/postfix/master.cf: smtp inet n - n - - smtpd mua_cleanup unix n - n - 0 cleanup -o header_checks=mua_header_checks -o body_checks=mua_body_checks submission inet n - n - - smtpd -o cleanup_service=$mua_cleanup_service -o syslog_name=postfix/submission ...[see sample master.cf file for more]... smtps inet n - n - - smtpd -o cleanup_service=$mua_cleanup_service -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes ...[see sample master.cf file for more]... By keeping the mua_xxx parameter settings in main.cf, configuration is not as ugly as it would be with settings in master.cf. Wietse
Send raw eml and maildrop queue
Hi, We need to send a lot of raw eml files. I decided to use sendmail as a solution for this process. We have approx 6000 files in maildrop queue, messages are going out from maildrop but i would like to speed up this process. I wonder is there any configuration option in postfix to control maildrop queue? Can you suggest another method how to send raw eml to postfix (thousands of eml files) Thanks. -- *This message was delivered using 100% recycled electrons*.
Re: blacklist senders to dead addresses?
On Wed, Sep 10, 2014 at 10:30:03AM +0200, Markus Benning wrote: On Tue, Sep 09, 2014 at 10:52:38PM -0500, Noel Jones wrote: But it's not too hard to make such a feature with either a policy service (eg. postfwd) or a log scraper (eg. fail2ban or just a shell script) to update a blacklist file. I'm currently setting up an project for a policy daemon at http://www.mtpolicyd.org/ I think a Honeypot plugin is a good idea and i'll add one. I just pushed a basic Honeypot plugin to git. Docs: http://www.mtpolicyd.org/documentation.html#Mail::MtPolicyd::Plugin::Honeypot Code: https://github.com/benningm/mtpolicyd/commit/d49f71c444ffc410eafd353c12896e321dee1fba I'm currently testing it on my mail server. Maybe you want to give it also a try. - Markus
Re: Possible reasons for lost connection after DATA
On Wed, Sep 10, 2014 at 09:56:48AM +0200, Sean Durkin wrote: Some of my users were complaining about losing incoming mail, namely Amazon shipping notifications, newsletters and such things that they were absolutely sure were sent out, but never reached their inbox. After doing some digging, increasing log verbosity and such, I found a lot of this: Have you tried disabling TCP window scaling? It might be confusing some middle-box (firewall, NAT device, ...) on path between the remote systems and your MTA. [... snip ...] Sep 10 00:06:37 mail postfix/smtpd[23095]: lost connection after DATA (17511 bytes) from smtp-out-127-108.amazon.com[176.32.127.108] Post the hostname/IP address of the receving system. Capture and examine a tcpdump recording of mail from one of the problem senders. Any sign of retransmission by the sender? For at least one such session, post all related messages from the postfix/smtpd[pid] that occur between connect from and disconnect from. -- Viktor.
Re: Send raw eml and maildrop queue
Konstantin: Hi, We need to send a lot of raw eml files. I decided to use sendmail as a solution for this process. We have approx 6000 files in maildrop queue, messages are going out from maildrop but i would like to speed up this process. I wonder is there any configuration option in postfix to control maildrop queue? Can you suggest another method how to send raw eml to postfix (thousands of eml files) Use parallel submission via SMTP. Local submissions are proceded by a single process thread. Wietse
pipemap, multiple results
Hi everyone, I have a question about the new pipemap functionality that is in the 2.12 experimental release. If I chain two lookup tables, and the first produces multiple results, it seems the lookup in the second table is done with all of the results at once. That means that the pipemap is only useful for lookups that produce a single result, which is a shame for such a cool feature. Would it be difficult to extend the pipemap functionality so it does a lookup in the second map for each of the results produced by the first map? Thanks! Roel
Re: pipemap, multiple results
On Wed, Sep 10, 2014 at 04:51:31PM +0200, Roel van Meer wrote: Would it be difficult to extend the pipemap functionality so it does a lookup in the second map for each of the results produced by the first map? Unfortunately, yes. The Postfix dictionary abstraction is a simple key-value service, and has no notion of multiple-results. The various *SQL and LDAP tables internally concatenate multiple query results into a single comma-separated string and hope that's useful. The higher layers see a single output string. The dictionary API would have to be redesigned to support a list of results, with LDAP, ... returning a list instead of a single comma separated string. This is a major change. -- Viktor.
Re: pipemap, multiple results
Viktor Dukhovni: On Wed, Sep 10, 2014 at 04:51:31PM +0200, Roel van Meer wrote: Would it be difficult to extend the pipemap functionality so it does a lookup in the second map for each of the results produced by the first map? Unfortunately, yes. The Postfix dictionary abstraction is a simple key-value service, and has no notion of multiple-results. The various *SQL and LDAP tables internally concatenate multiple query results into a single comma-separated string and hope that's useful. The higher layers see a single output string. The dictionary API would have to be redesigned to support a list of results, with LDAP, ... returning a list instead of a single comma separated string. This is a major change. Not only in table APIs, but also in programs that use those tables. What should output from postmap -q - look like when applied to a list of lookup keys? The output already uses newline to separate one lookup result from the next lookup result. JSON objects? Wietse
Re: pipemap, multiple results
Wietse Venema writes: Would it be difficult to extend the pipemap functionality so it does a lookup in the second map for each of the results produced by the first map? Unfortunately, yes. The Postfix dictionary abstraction is a simple key-value service, and has no notion of multiple-results. Ah, I see. The various *SQL and LDAP tables internally concatenate multiple query results into a single comma-separated string and hope that's useful. The higher layers see a single output string. The dictionary API would have to be redesigned to support a list of results, with LDAP, ... returning a list instead of a single comma separated string. This is a major change. Not only in table APIs, but also in programs that use those tables. What should output from postmap -q - look like when applied to a list of lookup keys? The output already uses newline to separate one lookup result from the next lookup result. JSON objects? That would be overkill. I had thought something like: - The first map returns a result; - The second maps splits this result by newline or comma, does a lookup for each of the keys, concats this back together, and passes it on as the new result. I can imagine that using the comma as delimiter is unwanted in such a generic part of postfix, but I had hoped that, since the higher layers are able to make sense of a comma separated string, that it would be possible for pipemap to do so as well. Thanks a lot, Roel
Re: blacklist senders to dead addresses?
Am 10.09.2014 um 16:10 schrieb Markus Benning: On Wed, Sep 10, 2014 at 10:30:03AM +0200, Markus Benning wrote: On Tue, Sep 09, 2014 at 10:52:38PM -0500, Noel Jones wrote: But it's not too hard to make such a feature with either a policy service (eg. postfwd) or a log scraper (eg. fail2ban or just a shell script) to update a blacklist file. I'm currently setting up an project for a policy daemon at http://www.mtpolicyd.org/ looks nice ! I think a Honeypot plugin is a good idea and i'll add one. I just pushed a basic Honeypot plugin to git. Docs: http://www.mtpolicyd.org/documentation.html#Mail::MtPolicyd::Plugin::Honeypot Code: https://github.com/benningm/mtpolicyd/commit/d49f71c444ffc410eafd353c12896e321dee1fba I'm currently testing it on my mail server. Maybe you want to give it also a try. - Markus Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
RE: Restricting relay of attachments
Hmmm. O.K. Thanks to both of you. It will take me some time to think this through. The level of indirection between main.cf and master.cf sure adds flexibility. But, as someone who doesn't work in postfix every day or even every week, it also leaves my head spinning. ;-) Thanks again. Michael -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix- us...@postfix.org] On Behalf Of Wietse Venema Sent: Wednesday, September 10, 2014 6:54 AM To: Postfix users Subject: Re: Restricting relay of attachments On 9/10/2014 1:24 AM, Michael Fox wrote: I'd like to restrict/deny (5xx permanent error) incoming messages from the Internet to client.domain2.com if they contain attachments. But no such restriction should be applied to other clients or to users on relay.domain1.com. Noel Jones: Header_checks and/or restriction classes are the wrong tool for this. You'll need some external milter/content_filter/smtpd_proxy_filter with per-destination controls. Correct. However, if you have separate mail streams for mail clients (TCP port submission/587 or smtps/465) and for MX service (TCP port 25), then you can apply different policies to each stream. /etc/postfix/main.cf: mua_cleanup_service = mua_cleanup mua_header_checks = ... mua_body_checks = ... /etc/postfix/master.cf: smtp inet n - n - - smtpd mua_cleanup unix n - n - 0 cleanup -o header_checks=mua_header_checks -o body_checks=mua_body_checks submission inet n - n - - smtpd -o cleanup_service=$mua_cleanup_service -o syslog_name=postfix/submission ...[see sample master.cf file for more]... smtps inet n - n - - smtpd -o cleanup_service=$mua_cleanup_service -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes ...[see sample master.cf file for more]... By keeping the mua_xxx parameter settings in main.cf, configuration is not as ugly as it would be with settings in master.cf. Wietse
Secondary MX behaviour
This question is actually two questions - neither of which are Postfix-specific but email-generic - but this list is the best resource I have to ask such questions. First - I've been contributing to Project Tarbaby, which means I have a pair of secondary MX records below my primary which accept anything they get - and those get used to build DNS blacklists. Properly configured hosts talk to my primary server without issue. The only question here is - does anyone have an objection to what I'm doing with this? Second - while this has been working for quite some time, recently my fax-to-email service provider has started sending everything to the secondaries. Which means I get no faxes. I can't configure their servers so I can't fix them. I've told them their systems are broken - at the least they need to refresh their MX lookup - but they insist everything is fine on their end. When I said the were in violation of the RFC's, they sent me back something that said the RFC's are ambiguous with how they should treat MX records, order, and failures. Based on the log exerpts they sent me I believe they're using Sendmail. Is the method for working with primary vs secondary MX records clear - at least clear enough that my tarpit setup should work? Or is there enough of a grey area that this setup is doomed to failure regardless? -- Daniel
Re: Restricting relay of attachments
On Wed, Sep 10, 2014 at 09:55:16AM -0700, Michael Fox wrote: Hmmm. O.K. Thanks to both of you. It will take me some time to think this through. The level of indirection between main.cf and master.cf sure adds flexibility. But, as someone who doesn't work in postfix every day or even every week, it also leaves my head spinning. ;-) The easiest way to understand this is that main.cf is just a lookup table that preempts built-in defaults and is loaded at the start of each Postfix daemon process. This lookup table is in turn preempted by -o command-line switches. However, both on the command-line and in main.cf itself, parameters can be recursively defined in terms of other parameters or just ad-hoc made up macros. Since the master.cf file is does not support white-space in argument values, and is not a good place for maintaining complex parameter settings, the best practice approach to master.cf overrides is to define them indirectly in terms of sensibly named macros that are actually defined in main.cf. main.cf: some_override = ... too complex to specify directly in master.cf ... master.cf service type ... daemon-program -o some_parameter=$some_override ... Even if the override value is very simple, it may be better to use indirection via main.cf, so that someone reading just main.cf can infer that there are likely master.cf overrides and it may be wise to look there also. -- Viktor.
Re: pipemap, multiple results
Roel van Meer: That would be overkill. I had thought something like: - The first map returns a result; - The second maps splits this result by newline or comma, does a lookup for each of the keys, concats this back together, and passes it on as the new result. I can imagine that using the comma as delimiter is unwanted in such a generic part of postfix, but I had hoped that, since the higher layers are able to make sense of a comma separated string, that it would be possible for pipemap to do so as well. That would break the vast majority of Postfix lookup tables. Whether or not the lookup result will be split on comma depends on where the result will be used. For example, virtual_alias_maps splits the result on comma; most other Postfix maps don't. If the pipemap table were to always split the lookup result on comma, then it would produce incorrect results for the vast majority of Postfix maps, including canonical_maps, access maps, and so on. That said, we could enable comma splitting via the pipemap syntax, but the pipemap syntax was not meant to be extended: pipemap (read-only) A pipeline of lookup tables. Example: pipemap:!type_1:name_1! ... !type_n:name_n. Each pipemap: query is given to the first table. Each lookup result becomes the query for the next table in the pipeline, and the last table produces the final result. When any table lookup produces no result, the pipeline produces no result. The first ASCII character after pipemap: will be used as the separator between the lookup tables that follow (do not use space, ,, : or non-ASCII). Instead of changing the syntax we could use a different name and call it pipemaps or spipemap (like pipemap, but split on '.'). Wietse
Re: Secondary MX behaviour
On Wed, Sep 10, 2014 at 10:02:30AM -0700, Daniel Miller wrote: This question is actually two questions - neither of which are Postfix-specific but email-generic - but this list is the best resource I have to ask such questions. First - I've been contributing to Project Tarbaby, which means I have a pair of secondary MX records below my primary which accept anything they get - and those get used to build DNS blacklists. Properly configured hosts talk to my primary server without issue. The only question here is - does anyone have an objection to what I'm doing with this? If your system ever responds with a 4XX, retries will hit the secondaries. You need to at least exclude clients that first tried the primary and tempfailed. However, transient connection or DNS problems can also cause a legitimate client to skip the primary now and then. Therefore, such automatic blacklisting needs to be implemented with great care, by excluding clients that have mostly gotten it right in the not too distant past. Second - while this has been working for quite some time, recently my fax-to-email service provider has started sending everything to the secondaries. Which means I get no faxes. I can't configure their servers so I can't fix them. I've told them their systems are broken - at the least they need to refresh their MX lookup - but they insist everything is fine on their end. When I said the were in violation of the RFC's, they sent me back something that said the RFC's are ambiguous with how they should treat MX records, order, and failures. Accusing people of RFC violation is unwise. Especially without a detailed understanding of both the RFC and the observed problem. Based on the log exerpts they sent me I believe they're using Sendmail. Sendmail processes MX records correctly. There may be DNS or network connectivity issues. Is the method for working with primary vs secondary MX records clear - at least clear enough that my tarpit setup should work? Or is there enough of a grey area that this setup is doomed to failure regardless? MTAs MUST try the highest priority (lowest value) MX records first. However, there is no expectation that such an attempt will always be observed by the receiving system. See above. If a sender consistently fails to reach the primary MX, and you're not greylisting or otherwise returning 4XX responses forcing them to the secondaries, perhaps there is a systemic connectivity or DNS problem. Their Sendmail MTA could perhaps be misconfigured, but that seems unlikely at this time. -- Viktor.
Fronting another mail server, best practices?
Hello, I know it’s fairly common for people to use postfix as a spam-eating/tagging gateway in environments where Exchange or some other MTA is mandatory. In my case, I’m fronting an old qmail/vpopmail setup which is probably never going to go away. Right now I have basic transport rules that force everything to qmail listening on an internal IP, and that works fine. In the interest of efficiency and making sure I’m actually doing this correctly, is there any other option (especially with qmail, and on the same host) to inject the mail into qmail? smtp to smtp works, and I think I have my user/alias lookups working fine (vpopmail stores this in a db, postfix queries same db, and I run a policy server to verify quotas on primary and backup mx), but something about this seems a bit inefficient. Am I missing any options? I see postfix has a qmqp server, but not a client, not sure that if one existed that would be a better option or not. Is there anything else I should be looking at for both the handoff from postfix to qmail and any general gotchas when handing email off to a “hidden” server? Thanks, Charles
different transport for all mail introduced via sendmail(1)
hi-
i have a mail submission server [submission/587 only] [msa.example.com]
for our users [config below]. in that context, it's working as desired.
we also have another, separate, msa [msa.systems.example.com], which
servers and other infrastructure devices use for submitting mail. how
can i configure postfix so that all mail introduced via sendmail(1) on
msa.example.com [regardless of envelope sender/recipient, etc] is
delivered directly to msa.systems.example.com:submission, and smtp auth
is performed with the necessary credentials, while not changing any
other existing elements of mail flow [for example, mail addressed to
f...@systems.example.com, introduced via submission, should not be
delivered directly to msa.systems.example.com:submission, but rather
follow the unadulterated delivery path]?
thanks
-ben
postconf -nf
address_verify_negative_expire_time = 30m
address_verify_negative_refresh_time = 5m
address_verify_poll_count = 20
address_verify_poll_delay = 1s
alias_database =
alias_maps =
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
content_filter = lmtp-filter:[mfa.example.com]:lmtp-filter-internal
delay_warning_time = 4h
disable_vrfy_command = yes
dist_list_restrictions = check_recipient_access
pcre:${table_directory}/dist_lists.pcre
enable_long_queue_ids = yes
local_header_rewrite_clients = check_address_map
cidr:${table_directory}/local_header_rewrite_clients.cidr
local_recipient_maps =
local_transport = error:local mail delivery is disabled
masquerade_domains = ${mydomain}
message_size_limit = 20971520
mydestination =
mydomain = example.com
myhostname = msa.${mydomain}
mynetworks =
myorigin = ${mydomain}
parent_domain_matches_subdomains =
pki_directory = ${config_directory}/pki
proxy_read_maps = ${virtual_alias_maps}
proxy:ldap:${table_directory}/sender_logins.cf
proxy:ldap:${table_directory}/dist_lists.cf
smtp_address_preference = ipv4
smtp_helo_name = ${myhostname}
smtp_tls_CAfile = /etc/pki/trusted_root_authorities/ca-certificates.crt
smtp_tls_fingerprint_digest = sha1
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = ${myhostname} ESMTP mail_submission_service
smtpd_etrn_restrictions = reject
smtpd_helo_required = yes
smtpd_recipient_restrictions = reject_non_fqdn_sender
reject_unknown_sender_domain reject_non_fqdn_recipient
reject_unknown_recipient_domain reject_unauth_pipelining
check_recipient_access hash:${table_directory}/bogus_domains
check_recipient_access
hash:${table_directory}/recipient_verification_domains
check_recipient_access proxy:ldap:${table_directory}/dist_lists.cf
check_recipient_access
pcre:${table_directory}/filter_training_transport.pcre
check_client_access
cidr:${table_directory}/non_auth_submitters.cidr
reject_plaintext_session
reject_sender_login_mismatch permit_sasl_authenticated reject
smtpd_reinjection_banner = ${myhostname} ESMTP mail_reinjection_service
smtpd_reinjection_restrictions = check_client_access
cidr:${table_directory}/reinjection_access.cidr reject
smtpd_relay_restrictions =
smtpd_restriction_classes = smtpd_reinjection_restrictions
dist_list_restrictions
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = inet:[::1]:sasl
smtpd_sasl_type = dovecot
smtpd_sender_login_maps = proxy:ldap:${table_directory}/sender_logins.cf
smtpd_tls_CAfile = /etc/pki/trusted_root_authorities/ca-certificates.crt
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = ${pki_directory}/${myhostname}-cert.pem
smtpd_tls_dh1024_param_file = ${pki_directory}/dh_2048.pem
smtpd_tls_dh512_param_file = ${pki_directory}/dh_512.pem
smtpd_tls_fingerprint_digest = sha1
smtpd_tls_key_file = ${pki_directory}/${myhostname}-key.pem
smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
strict_rfc821_envelopes = yes
table_directory = ${config_directory}/tables
transport_maps = hash:${table_directory}/transports
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 554
unknown_relay_recipient_reject_code = 554
unverified_recipient_reject_code = 550
unverified_sender_reject_code = 550
virtual_alias_domains =
virtual_alias_expansion_limit = 2000
virtual_alias_maps = proxy:ldap:${table_directory}/virtual_aliases.cf
postconf -Mf
smsp inet n - - - - smtpd
pickup unix n - - 60 1 pickup
cleanupunix n - - - 0 cleanup
qmgr unix n - n 300 1 qmgr
tlsmgr unix - - - 1000? 1 tlsmgr
rewriteunix - - - - - trivial-rewrite
bounce unix - - - - 0 bounce
defer unix - - - - 0
Re: Secondary MX behaviour
Daniel Miller: This question is actually two questions - neither of which are Postfix-specific but email-generic - but this list is the best resource I have to ask such questions. First - I've been contributing to Project Tarbaby, which means I have a pair of secondary MX records below my primary which accept anything they get - and those get used to build DNS blacklists. Properly configured hosts talk to my primary server without issue. The only question here is - does anyone have an objection to what I'm doing with this? This is unsafe, because the connection to the primary MX may fail for all kinds of reasons, including a temporary network outage somewhere far away on the Internet. Is the method for working with primary vs secondary MX records clear - at least clear enough that my tarpit setup should work? Or is there enough of a grey area that this setup is doomed to failure regardless? Tricks with MX-priority spamtraps share the problem that they make assumptions about the behavior of all legitimate MTAs. For a related approach, see, for example, nolisting. Wietse
Re: Fronting another mail server, best practices?
On Wed, Sep 10, 2014 at 01:28:17PM -0400, CSS wrote: In the interest of efficiency and making sure I?m actually doing this correctly, is there any other option (especially with qmail, and on the same host) to inject the mail into qmail? smtp to smtp works, and I think I have my user/alias lookups working fine (vpopmail stores this in a db, postfix queries same db, and I run a policy server to verify quotas on primary and backup mx), but something about this seems a bit inefficient. SMTP is the most efficient mechanism for moving content out of the Postfix queue. The only other option is to not queue the content in Postfix at all, using qmail's SMTPs server as a proxy filter, that just happens to not re-inject mail back into Postfix. You just have to make sure that any ESMTP features promised by Postfix in its EHLO reply (DSN, ...) are understood by qmail, or otherwise suppress them in Postfix. STARTTLS is an exception, because Postfix terminates the TLS connection, and does not speak TLS to the proxy filter. -- Viktor.
Re: pipemap, multiple results
On Wed, Sep 10, 2014 at 01:18:22PM -0400, Wietse Venema wrote: Instead of changing the syntax we could use a different name and call it pipemaps or spipemap (like pipemap, but split on ','). Should it be split on comma, or parse as a list of addresses? The latter is perhaps more correct if there is ever a result of the form: perverse,localpart@example.com,nor...@example.net,... IIRC virtual(5) lookups assume that the *value* is in external form, so pipemaps would have to parse the value address list, convert the elements to internal form, and then perform the next lookup. I don't recall whether virtual(5) lookup *keys* are in external or internal form, I think the latter, but I always have to check. -- Viktor.
Re: Correct cert handling when hosting multiple domains?
--On Tuesday, September 09, 2014 9:02 AM +0200 Stefan Foerster cite+postfix-us...@incertum.net wrote: * Wietse Venema wie...@porcupine.org: Viktor Dukhovni: Which works just fine with a single certificate, because TLS in SMTP in generally unauthenticated. If all the various domains share the same MX hostnames, many implementations that log speculative authentication results (no actual enforcement, just logging that a given session happened to appear to not be MiTMed) will match the MX host against the shared certificate. I'd like to hear a bit more on this from other people than Viktor. There is a difference between technically perfect (e.g., telling everyone to adopt DNSSSEC and DANE or else don't bother), and what is currently justifiable. This isn't exactly what you asked for, but: For us, there is very little interest from our customers when it comes to securing the transport side of mail exchange. Most B2C customers don't care (and probably most don't know). When it comes to our B2B customers (we have several white label units and do provide application services), we mostly encounter these scenarios: We have 6 clients, primarily BSPs, wanting the cert setup for multiple domains. For securing smtpd in general, we've had about 20 or so interested clients, and have set smtpd_tls_security=may for zimbra.com as well. Interestingly enough, there does seem to be a number of hosts using TLS when communicating with smtpd, including sites such as google, cloud9, yahoo, hotmail, dropbox, linkedin, etc. We have 2,253 (non unique domain) connections so far today using TLS over smtpd (vs 13,599 not using TLS). So approximately 14% of all connections to our smtpd are using TLS now. Hard to exactly extract how significant that is, since it'll depend on traffic patterns, but it overall does indicate to me that securing the smtpd layer is of importance to a number of organizations. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: pipemap, multiple results
Viktor Dukhovni: On Wed, Sep 10, 2014 at 01:18:22PM -0400, Wietse Venema wrote: Instead of changing the syntax we could use a different name and call it pipemaps or spipemap (like pipemap, but split on ','). Should it be split on comma, or parse as a list of addresses? apipemap, then? Yes, the external/internal address form is a pain. The lookup keys should be in internal form. For security reasons, all equivalent input forms must produce the same query result. Wietse
Re: Possible reasons for lost connection after DATA
Hi Robert, Am 10.09.2014 um 10:11 schrieb Robert Schetterer: Am 10.09.2014 um 09:56 schrieb Sean Durkin: The first question is: Can I rule out it's my fault? have you changed anything last days/month upgrades/updates software hardware ? Hardware is unchanged. The Ubuntu postfix package was upgraded in August (2.9.6-1~12.04.2), but this problem seems to have started before that, looking at older logs. Except that, I don't see any updates directly related to the mail system in the past half year. There's of course other system/security updates, but how should I know which of these might possibly be responsible? I haven't changed the basic Postfix configuration lately. I did add OpenDKIM a few months back, but I removed that a few days ago to rule out that's the problem. I also removed Spamassassin, any RBLs and Postgrey, which I normally have running there; that does not seem to make a difference. So I'm now back to a very basic Postfix conf, but the problem persists. please send you postfix config , Anonymized postfinger-output is attached below. search list archive lost connection after DATA I did that, I couldn't find anything that really applies in my case... most problems there are either related to DATA size 0 or to weird MTU issues. Mostly this seems to happen for connections from spam bots or misconfigured clients and people tell you you should just ignore it, but that doesn't really apply here. I've tried getting a TCP dump of such an SMTP session, but since most of the interesting mail is coming from server clusters and the external hosts trying to deliver mail keep changing I'm still waiting to catch a good one... Regards, Sean Here, as promised, postfinger-output: --System Parameters-- mail_version = 2.9.6 hostname = mail uname = Linux mail 3.2.0-65-virtual #99-Ubuntu SMP Fri Jul 4 21:23:03 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux --Packaging information-- looks like this postfix comes from deb package: postfix-2.9.6-1~12.04.2 --main.cf non-default parameters-- alias_maps = $alias_database append_dot_mydomain = no biff = no broken_sasl_auth_clients = yes debug_peer_list = amazon.com, srv2.de, psi.cust-cluster.com, outbound.protection.outlook.com delay_warning_time = 4h disable_vrfy_command = yes html_directory = /usr/share/doc/postfix/html mailbox_size_limit = 0 mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp message_size_limit = 262144000 mydestination = localhost, localhost.$mydomain, $mydomain, mail.$mydomain, mysql:/etc/postfix/mysql-mydestination.cf myhostname = my.host.name mynetworks = 127.0.0.0/8, ip.add.re.ss myorigin = /etc/mailname proxy_interfaces = ip.add.re.ss recipient_delimiter = + sender_canonical_maps = mysql:/etc/postfix/mysql-canonical.cf smtp_destination_concurrency_limit = 1 smtp_destination_rate_delay = 1s smtpd_helo_required = yes smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_pipelining, reject_unauth_destination, reject_unlisted_recipient reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, smtpd_sasl_auth_enable = yes smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_non_fqdn_sender, reject_unknown_sender_domain reject_unknown_recipient_domain, reject_unauth_pipelining smtpd_tls_auth_only = yes smtpd_tls_CAfile = /etc/postfix/ssl/ca.pem smtpd_tls_cert_file = /etc/postfix/ssl/my_cert.crt smtpd_tls_dh1024_param_file = /etc/postfix/ssl/dh_2048.pem smtpd_tls_dh512_param_file = /etc/postfix/ssl/dh_512.pem smtpd_tls_key_file = /etc/postfix/ssl/my_key.key smtpd_tls_protocols = !SSLv2 smtpd_tls_received_header = yes smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache smtpd_use_tls = yes smtp_tls_security_level = may smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache strict_rfc821_envelopes = yes tls_preempt_cipherlist = yes virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf --master.cf-- smtp inet n - y -- smtpd submission inet n - y - - smtpd -o smtpd_etrn_restrictions=reject -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject smtpsinet n - y - - smtpd -o smtpd_etrn_restrictions=reject -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes pickupfifo n - - 60 1 pickup cleanup unix n - - - 0 cleanup qmgr fifo n - n 100 1 qmgr tlsmgrunix - - - 1000? 1 tlsmgr rewrite unix - - - - - trivial-rewrite bounceunix - - - - 0 bounce defer unix - -
Re: Secondary MX behaviour
On 9/10/2014 10:24 AM, Viktor Dukhovni wrote: If your system ever responds with a 4XX, retries will hit the secondaries. You need to at least exclude clients that first tried the primary and tempfailed. However, transient connection or DNS problems can also cause a legitimate client to skip the primary now and then. Therefore, such automatic blacklisting needs to be implemented with great care, by excluding clients that have mostly gotten it right in the not too distant past. The DNS blacklisting is score-based - so if anyone winds up in the there it won't be the end-all, certainly not for my primary which has extensive whitelisting. MTAs MUST try the highest priority (lowest value) MX records first. However, there is no expectation that such an attempt will always be observed by the receiving system. See above. If a sender consistently fails to reach the primary MX, and you're not greylisting or otherwise returning 4XX responses forcing them to the secondaries, perhaps there is a systemic connectivity or DNS problem. Their Sendmail MTA could perhaps be misconfigured, but that seems unlikely at this time. The problem I'm facing is the remote server isn't reaching my primary at all - I have absolutely no indication of it in my logs whatsoever. And they're extensively whitelisted (by IP, domain, and address). They're just going right to the secondaries and have been for the past couple weeks. Yet everyone else is able to reach me without issue. Temporarily at least I'll drop the secondaries from my DNS and see if it helps - but I still think there's something broken on their end. I just don't know how to express it properly beyond, it's wrong, and it's on your end. -- Daniel
Re: Correct cert handling when hosting multiple domains?
On Wed, Sep 10, 2014 at 10:38:49AM -0700, Quanah Gibson-Mount wrote: Interestingly enough, there does seem to be a number of hosts using TLS when communicating with smtpd, including sites such as google, cloud9, yahoo, hotmail, dropbox, linkedin, etc. We have 2,253 (non unique domain) connections so far today using TLS over smtpd (vs 13,599 not using TLS). So approximately 14% of all connections to our smtpd are using TLS now. Hard to exactly extract how significant that is, since it'll depend on traffic patterns, but it overall does indicate to me that securing the smtpd layer is of importance to a number of organizations. Google reports 57% of inbound email encrypted via TLS. https://www.google.com/transparencyreport/saferemail/ so indeed STARTTLS is lately much more common. The question at hand is however whether domain-specific certificates at a single TCP endpoint are something Postfix should support. * Presumably because enough SMTP clients actually verify CA-issued certificates. * And the various hosted domains don't all use the same MX host name (possibly with a prefix for matching a wildcard cert): $ dig +short -t mx nist.gov 0 nist-gov.mail.protection.outlook.com. $ dig +short -t mx microsoft.com 10 microsoft-com.mail.protection.outlook.com. * And (crucially) SMTP clients signal SNI information that would allow the SMTP server to offer the right certificate. - Which also assumes that other SMTP servers don't choke on SNI requests when they don't have an exactly matching certificate. * And (with great difficulty) it is practical to obtain certificates for domains belonging to the clients, most likely via the clients obtaining these and them sharing the keys with the provider. While the above might be seen as an attempt to dissuade you from looking into this further, the goal is to get past any magical wouldn't it be nice if thinking and find out whether people really understand what it is they're asking for, and whether they still want it after they understand what it is they might get. Opportunistic TLS with no authentication works just fine with a just a self-signed certificate, bearing no name in particular. -- Viktor.
Re: Secondary MX behaviour
On 9/10/2014 10:35 AM, Wietse Venema wrote: Daniel Miller: This question is actually two questions - neither of which are Postfix-specific but email-generic - but this list is the best resource I have to ask such questions. First - I've been contributing to Project Tarbaby, which means I have a pair of secondary MX records below my primary which accept anything they get - and those get used to build DNS blacklists. Properly configured hosts talk to my primary server without issue. The only question here is - does anyone have an objection to what I'm doing with this? This is unsafe, because the connection to the primary MX may fail for all kinds of reasons, including a temporary network outage somewhere far away on the Internet. Is the method for working with primary vs secondary MX records clear - at least clear enough that my tarpit setup should work? Or is there enough of a grey area that this setup is doomed to failure regardless? Tricks with MX-priority spamtraps share the problem that they make assumptions about the behavior of all legitimate MTAs. For a related approach, see, for example, nolisting. Wietse Do I infer from that MX-priority spamtraps are a Bad Idea - at least in the real world? This is the first time in about...I think 6 months since I implemented the tarpit that I found a problem. -- Daniel
Re: Secondary MX behaviour
On Wed, Sep 10, 2014 at 10:55:47AM -0700, Daniel Miller wrote: Temporarily at least I'll drop the secondaries from my DNS and see if it helps - but I still think there's something broken on their end. I just don't know how to express it properly beyond, it's wrong, and it's on your end. There is as yet no strong evidence for that conclusion. -- Viktor.
Re: different transport for all mail introduced via sendmail(1)
btb: hi- i have a mail submission server [submission/587 only] [msa.example.com] for our users [config below]. in that context, it's working as desired. we also have another, separate, msa [msa.systems.example.com], which servers and other infrastructure devices use for submitting mail. how can i configure postfix so that all mail introduced via sendmail(1) on msa.example.com [regardless of envelope sender/recipient, etc] is delivered directly to msa.systems.example.com:submission, /etc/postfix/master.cf: pickup .. .. .. .. .. .. .. .. pickup -o filter=smtp_pickup:a.systems.example.com:submission smtp_pickup .. .. .. .. .. .. .. .. smtp -o smtp_sender_dependent_authentication=$smtp_pickup_sender_dependent_authentication -o smtp_sasl_password_maps=$smtp_pickup_sasl_password_maps and smtp auth is performed with the necessary credentials, Perhaps you mean sender-dependent credentials? /etc.postfix/master.cf: smtp_pickup_sender_dependent_authentication = yes smtp_pickup_sasl_password_maps = hash:/etc/postfix/smtp_pickup_sasl_pass Wietse
Re: Correct cert handling when hosting multiple domains?
--On Wednesday, September 10, 2014 6:56 PM + Viktor Dukhovni postfix-us...@dukhovni.org wrote: While the above might be seen as an attempt to dissuade you from looking into this further, the goal is to get past any magical wouldn't it be nice if thinking and find out whether people really understand what it is they're asking for, and whether they still want it after they understand what it is they might get. Opportunistic TLS with no authentication works just fine with a just a self-signed certificate, bearing no name in particular. Thanks Victor, I will take this back to the clients. I'm guessing what they really just want is encrypted SMTPD, which as you note, can work just fine with any valid certificate setup. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration
RE: Restricting relay of attachments
That's helpful. Thanks. -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix- us...@postfix.org] On Behalf Of Viktor Dukhovni Sent: Wednesday, September 10, 2014 10:11 AM To: postfix-users@postfix.org Subject: Re: Restricting relay of attachments On Wed, Sep 10, 2014 at 09:55:16AM -0700, Michael Fox wrote: Hmmm. O.K. Thanks to both of you. It will take me some time to think this through. The level of indirection between main.cf and master.cf sure adds flexibility. But, as someone who doesn't work in postfix every day or even every week, it also leaves my head spinning. ;-) The easiest way to understand this is that main.cf is just a lookup table that preempts built-in defaults and is loaded at the start of each Postfix daemon process. This lookup table is in turn preempted by -o command-line switches. However, both on the command-line and in main.cf itself, parameters can be recursively defined in terms of other parameters or just ad-hoc made up macros. Since the master.cf file is does not support white-space in argument values, and is not a good place for maintaining complex parameter settings, the best practice approach to master.cf overrides is to define them indirectly in terms of sensibly named macros that are actually defined in main.cf. main.cf: some_override = ... too complex to specify directly in master.cf ... master.cf service type ... daemon-program -o some_parameter=$some_override ... Even if the override value is very simple, it may be better to use indirection via main.cf, so that someone reading just main.cf can infer that there are likely master.cf overrides and it may be wise to look there also. -- Viktor.
Re: Secondary MX behaviour
Wietse: Tricks with MX-priority spamtraps share the problem that they make assumptions about the behavior of all legitimate MTAs. For a related approach, see, for example, nolisting. Daniel Miller: Do I infer from that MX-priority spamtraps are a Bad Idea - at least in the real world? This is the first time in about...I think 6 months since I implemented the tarpit that I found a problem. Assumptions about the behavior of remote clients are just that, assumptions. They can be wrong. postscreen is based on the assumption that legitimate MTAs will never make certain mistakes such as talking too soon. Sofar that turns out to be correct for legitimate MTAs. It has, however, exposed broken non-MTA software such as health checkers and address verifiers. Wietse
Bypass content_filter for some recipient
Hi! I'm running Postfix 2.11.1. I have amavisd-new as content filter (content_filter = amavisfeed:[127.0.0.1]:10024). I want to bypass this check (amavisd-new) for some recipient (mail to). It's for recipient, not for sender (mail from). How can I accomplish that? Using smtpd_recipient_restrictions? Please give me some example. Regards, Rodrigo.
Re: Possible reasons for lost connection after DATA
Hi Viktor, Am 10.09.2014 um 16:19 schrieb Viktor Dukhovni: Have you tried disabling TCP window scaling? It might be confusing some middle-box (firewall, NAT device, ...) on path between the remote systems and your MTA. I would not have thought of that... I've tried that now, but it does not seem to help. Post the hostname/IP address of the receving system. mail.tuxroot.de Capture and examine a tcpdump recording of mail from one of the problem senders. Any sign of retransmission by the sender? I'm trying to get a good dump and will post results once I get one. Not that easy since the external hosts keep changing all the time. All mail affected comes from mass mailers that use server clusters, so I keep getting those messages from lots of different remote hosts. I'm waiting for it to happen from one of the hosts I've seen before. Retransmission is tried numerous times, but for every retransmission the lost connection message is the same (identical number of bytes), as far as I can tell. That's one thing that puzzles me... So e.g. a message is delivered twice and each time the connection is lost after exactly 17441 bytes, even if it's different remote hosts trying, that's kind of odd. For at least one such session, post all related messages from the postfix/smtpd[pid] that occur between connect from and disconnect from. Here's one: http://pastebin.com/twb3Z8Eg And this seems to be the same message being redelivered later, from a different host, with the same result (connection lost after exactly 17441 bytes): http://pastebin.com/Qihbjz3w What I do notice there is that in fact the connection seems to be *very* slow. In the above example, the whole process takes several minutes. I don't have any throughput or network speed issues with other hosts, though. I've tried sending mail from Gmail, Yahoo, my workplace, my former university, GMX, whatever; everything goes through on the first attempt each and every time, and quickly. But it seems it is always slow for a few hosts. Regards, Sean
Re: Bypass content_filter for some recipient
On 9/10/2014 2:01 PM, M. Rodrigo Monteiro wrote:
Hi!
I'm running Postfix 2.11.1.
I have amavisd-new as content filter (content_filter =
amavisfeed:[127.0.0.1]:10024).
I want to bypass this check (amavisd-new) for some recipient (mail
to). It's for recipient, not for sender (mail from).
How can I accomplish that? Using smtpd_recipient_restrictions?
Please give me some example.
Regards,
Rodrigo.
The easiest way to bypass scanning for one recipient is to add that
recipient to the @{virus,spam,bad_header}_lovers_maps in amavisd.
This adds very little overhead since virus and spam scanning are
skipped.
In postfix, filtering is a message property, not a recipient
property. To bypass filtering for a recipient requires multiple
postfix instances -- one before filter and one after filter -- not
just separate master.cf listeners.
http://www.postfix.org/MULTI_INSTANCE_README.html
Don't be tempted to use the access map FILTER result to override the
filter destination based on recipient. This will unpredictably
mis-route mail addressed to multiple recipients.
-- Noel Jones
Re: Possible reasons for lost connection after DATA
Sean Durkin: [ Charset windows-1252 converted... ] Hi Viktor, Am 10.09.2014 um 16:19 schrieb Viktor Dukhovni: Have you tried disabling TCP window scaling? It might be confusing some middle-box (firewall, NAT device, ...) on path between the remote systems and your MTA. I would not have thought of that... I've tried that now, but it does not seem to help. Post the hostname/IP address of the receving system. mail.tuxroot.de Capture and examine a tcpdump recording of mail from one of the problem senders. Any sign of retransmission by the sender? I'm trying to get a good dump and will post results once I get one. Not that easy since the external hosts keep changing all the time. All mail affected comes from mass mailers that use server clusters, so I keep getting those messages from lots of different remote hosts. I'm waiting for it to happen from one of the hosts I've seen before. Retransmission is tried numerous times, but for every retransmission the lost connection message is the same (identical number of bytes), as far as I can tell. That's one thing that puzzles me... So e.g. a message is delivered twice and each time the connection is lost after exactly 17441 bytes, even if it's different remote hosts trying, that's kind of odd. No, it means the same problem is happening. Same error, same symptom. What I do notice there is that in fact the connection seems to be *very* slow. In the above example, the whole process takes several minutes. I don't have any throughput or network speed issues with other hosts, though. I've tried sending mail from Gmail, Yahoo, Slow performance is typical for TCP window scaling problems. Have you tried to turn it off in your kernel? # sysctl -w net.ipv4.tcp_window_scaling=0 To make it permanent: # echo 'net.ipv4.tcp_window_scaling = 0' /etc/sysctl.conf Wietse
Re: Postfix and SASL auth on OpenBSD 5.5.
Thank you for your reply. On 08.09.14, 21:11, Viktor Dukhovni wrote: On Mon, Sep 08, 2014 at 10:47:02PM +0200, giacomo wrote: I send you the configuration of Postfix. Change the password for this account: Username: d.lis...@gruppoisil.com Compromised Password: lisaia This acconut is only for try the server mail. smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $mydomain smtpd_sasl_security_options = So you're using Cyrus SASL, but not showing any details of the SASL configuration, available plugins, ... The configuration of SASL is in \usr\local\lib\sasl2\smtpd.conf pwcheck_method: saslauthd mech_list: PLAIN LOGIN #authdaemond_path: /var/sasl2/socket authdaemond_path: /var/run/courier-auth/socket log_level: 7 220 mail2.domain.com ESMTP Postfix ehlo tin.it 250-mail2.domain.com 250-PIPELINING 250-SIZE 1024 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN AUTH PLAIN AGQubGlzYWlhQGdydXBwb2lzaWwuY29tAGxpc2FpYQ== 535 5.7.8 Error: authentication failed: generic failure Avoid posting AUTH PLAIN and AUTH LOGIN command arguments, they contain reversibly (base64) encoded passwords. I don't understand this. Please specificy what it mean. Jul 5 23:11:19 mail2 postfix/smtpd[3717]: warning: SASL authentication failure: could not verify password Jul 5 23:11:19 mail2 postfix/smtpd[3717]: warning: SASL authentication failure: Password verification failed Jul 5 23:11:19 mail2 postfix/smtpd[3717]: warning: unknown[192.168.1.248]: SASL PLAIN authentication failed: generic failure Cyrus SASL was not happy. -- Viktor. -- Luciano
Re: Possible reasons for lost connection after DATA
On Wed, Sep 10, 2014 at 09:19:58PM +0200, Sean Durkin wrote: For at least one such session, post all related messages from the postfix/smtpd[pid] that occur between connect from and disconnect from. Here's one: http://pastebin.com/twb3Z8Eg This trace has an insane level of debugging turned on, to the point that syslogd is overwhelmed and is losing messages. PLEASE DISABLE ALL VERBOSE logging. NO -v options in master.cf, NO debug_peer_list, ... Please make sure that the /dev/log syslog socket is a dgram not a stream socket, and that mail logging is not synchronous. Then if the problem persists, report just normal Postfix logging, not the flood of noise from verbose logging. -- Viktor.
Re: Postfix and SASL auth on OpenBSD 5.5.
On Wed, Sep 10, 2014 at 10:46:43PM +0200, giacomo wrote: So you're using Cyrus SASL, but not showing any details of the SASL configuration, available plugins, ... The configuration of SASL is in /usr/local/lib/sasl2/smtpd.conf pwcheck_method: saslauthd mech_list: PLAIN LOGIN #authdaemond_path: /var/sasl2/socket authdaemond_path: /var/run/courier-auth/socket log_level: 7 The documentation for authdaemond_path says: Path to Courier-IMAP authdaemond's unix socket. Only applicable when pwcheck_method is set to authdaemond. So your smtpd.conf can't work as configured. Is the authdaemond_path correctly specified? Does the postfix user have permission to access the socket? Is smtpd(8) chrooted? AUTH PLAIN AGQubGlzYWlhQGdydXBwb2lzaWwuY29tAGxpc2FpYQ== 535 5.7.8 Error: authentication failed: generic failure Avoid posting AUTH PLAIN and AUTH LOGIN command arguments, they contain reversibly (base64) encoded passwords. I don't understand this. Please specificy what it mean. It means that you should not send the data after AUTH PLAIN to a public mailing list. It can be easily decoded to recover your no longer secret password. For example: $ echo AGQubGlzYWlhQGdydXBwb2lzaWwuY29tAGxpc2FpYQ== | openssl base64 -A -d | cat -etv ^@d.lis...@gruppoisil.com^@lisaia -- Viktor.
Re: pipemap, multiple results
On Wed, Sep 10, 2014 at 01:43:49PM -0400, Wietse Venema wrote: Should it be split on comma, or parse as a list of addresses? apipemap, then? Sure, a pipeline of 1-to-n address mappings. Yes, the external/internal address form is a pain. The lookup keys should be in internal form. For security reasons, all equivalent input forms must produce the same query result. Thanks, perhaps with the rationale stated, I'll have an easier time remembering this. -- Viktor.
