SV: Deliver all mail from one domain to two servers [invalid signature!]
Try a recipient_bcc_maps using pcre: Eg, something like this: /^([^\@]*)\@yourdomain\.com$/ $1...@new.server.com (first part is "match anything that does not contain a @", second is a literal @, and the final part is the external domain that your border server receives mail on) (Note, test around with the map on a test server connected to 2 other test server instances to "simulate" your setup before deploying this to a production server) And then you use a transport map to deliver the new domain to the new server. -Ursprungligt meddelande- Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För Stuart Longland Skickat: den 9 februari 2016 06:32 Till: postfix-users@postfix.org Ämne: Deliver all mail from one domain to two servers [invalid signature!] Hi all, I did a search but didn't turn up any answers. We've got a border router that runs Postfix (on Ubuntu 14.04) and accepts email for a couple of domains, all of which gets passed to a server inside our corporate network, which is configured using the relay_domains and transport_maps keys. We are in the process of commissioning a new server that will ultimately replace the first one. So we'll have two servers, the existing one (with Postfix + Zarafa 6.40, Ubuntu 10.04) and the new one (with Postfix + Dovecot, Ubuntu 14.04) both responsible for the same domains. We want to have our email go to both servers simultaneously, so that we can flip back and forth between the two hosts as need requires. i.e. if things go really pear shaped, we can switch back and we've lost no incoming email. (We might need to cherry-pick some sent mail out of the new server, but that should be an easier job.) Is it possible to nominate both servers as being the destinations for both domains so that a single email sent to user@domain is sent to both internal servers? Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. smime.p7s Description: S/MIME Cryptographic Signature
Re: Deliver all mail from one domain to two servers
On 2/8/2016 11:31 PM, Stuart Longland wrote: > > Is it possible to nominate both servers as being the destinations for > both domains so that a single email sent to user@domain is sent to both > internal servers? To deliver multiple messages, you need to have multiple recipients. The easiest way to do this is to add a virtual_alias_maps entry for each user (NOT virtual_alias_domains) to include a mapping to the new server. Here's a bare-bones example: # main.cf virtual_alias_maps = hash:/etc/postfix/virutual_alias # virtual_alias us...@example.com us...@example.com us...@new.example.com us...@example.com us...@example.com us...@new.example.com ... Don't be tempted to use wildcard rewriting here; that will break recipient validation. Use your favorite scripting language to generate the list programmatically. Use a transport_maps entry to route the new domain to the new server # main.cf transport_maps = hash:/etc/postfix/transport # transport new.example.com relay:[IP.of.new.server] And finally, use smtp_generic_maps to rewrite the domain name back to the original during delivery. # main.cf smtp_generic_maps = hash:/etc/postfix/generic # smtp_generic -- wildcards OK here @new.example.com @example.com References: http://www.postfix.org/ADDRESS_REWRITING_README.html http://www.postfix.org/postconf.5.html#transport_maps http://www.postfix.org/postconf.5.html#smtp_generic_maps http://www.postfix.org/postconf.5.html#virtual_alias_maps -- Noel Jones
Deliver all mail from one domain to two servers
Hi all, I did a search but didn't turn up any answers. We've got a border router that runs Postfix (on Ubuntu 14.04) and accepts email for a couple of domains, all of which gets passed to a server inside our corporate network, which is configured using the relay_domains and transport_maps keys. We are in the process of commissioning a new server that will ultimately replace the first one. So we'll have two servers, the existing one (with Postfix + Zarafa 6.40, Ubuntu 10.04) and the new one (with Postfix + Dovecot, Ubuntu 14.04) both responsible for the same domains. We want to have our email go to both servers simultaneously, so that we can flip back and forth between the two hosts as need requires. i.e. if things go really pear shaped, we can switch back and we've lost no incoming email. (We might need to cherry-pick some sent mail out of the new server, but that should be an easier job.) Is it possible to nominate both servers as being the destinations for both domains so that a single email sent to user@domain is sent to both internal servers? Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature
Re: 3.0.3: "mynetworks" values are busted and missing ipv6 info
On 2016-02-09 05:30, Quanah Gibson-Mount wrote: And the invalid netmask? Which was the 1st part of what I was noting. It should be 127.0.0.1/8 for example, not 127.0.0.1/32. postconf mynetworks_style where is the invalid part ? :=)
Re: 3.0.3: "mynetworks" values are busted and missing ipv6 info
--On Monday, February 08, 2016 8:00 PM -0500 Wietse Venema wrote: Quanah Gibson-Mount: In Postfix > 3.0.x, the value from postconf mynetworks returns incorrect netmask values, and it is missing IPv6 entirely: This depends on the inet_protocols setting. # postconf inet_protocols=all # postconf mynetworks mynetworks = 127.0.0.1/32 192.168.122.1/32 168.100.189.7/32 [::1]/128 [fe80::223:55ff:fe5c:3985]/128 And the invalid netmask? Which was the 1st part of what I was noting. It should be 127.0.0.1/8 for example, not 127.0.0.1/32. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc
Re: Copy mail from specific email address to specific email address to other accounts
> On Feb 8, 2016, at 10:24 PM, Bill Cole > wrote: > >> $ grep japan /usr/local/etc/postfix/virtual >> ja...@xanmax.com >> xander+ja...@xanmax.com,kris+ja...@kreme.com,lb+ja...@kreme.com > > Never gets used, because that file is for mapping addresses in virtual alias > domains, of which xanmax.com is not one. Please do not perpetuate this misconception. Virtual(5) alias rewriting applies to *all* recipient addresses, *regardless* of address class. -- Viktor.
Re: Copy mail from specific email address to specific email address to other accounts
On 8 Feb 2016, at 17:25, @lbutlr wrote: On Feb 8, 2016, at 8:26 AM, Bill Cole wrote: However, there's still something missing in what you've provided: "postconf -n" output. All of it. Preferably unmunged, but if you absolutely must obfuscate details, do so programmatically and carefully. Also, if you use ANY transport maps, include those. $ postconf -n Thank you. I'll pare down to what seems interesting to me. I'm still a bit confused about what you're trying to achieve and how it relates to everything you've provided, but there are things that seem particularly odd... [...] mydestination = $myhostname, localhost.$mydomain, $mydomain, localhost, ns1.$mydomain, ns2.$mydomain, mail.$mydomain, www.$mydomain, webmail.$mydomain mydomain = covisp.net myhostname = mail.covisp.net OK, so the two domains of actual interest (xanmax.com & kreme.com) are not local domains so must be either virtual alias domains, virtual mailbox domains, relay domains, or domains you don't do delivery for (see ADDRESS_CLASS_README.) MX records say they are both your responsibility, so you should have some delivery/transport mapping for them both. Okay... [...] virtual_alias_domains = kreme.com There's one... virtual_alias_maps = hash:$config_directory/virtual proxy:mysql:$config_directory/mysql_virtual_alias_maps.cf virtual_gid_maps = static:89 virtual_mailbox_base = /usr/local/virtual virtual_mailbox_domains = proxy:mysql:$config_directory/mysql_virtual_domains_maps.cf And maybe there's the other. Dunno. You decline to tell us :) $ more header_checks.pcre /^X-Clacks-Overhead:/ IGNORE /^Content-Transfer-Encoding:/i PREPEND X-Clacks-Overhead: GNU Terry Pratchett ##/^Subject:/WARN /^From:.*ja...@kreme.com/ REDIRECT ja...@xanmax.com So that handles redirection based on the From header, which is quirky and imperfect (less charitably: probably wrong) but maybe you really need that. $ cat sender_bcc.pcre ##/^From:.*ja...@kreme.com/ REDIRECT ja...@xanmax.com Commented. Does absolutely nothing. Also: I don't THINK you can do a REDIRECT in there, but only map to additional recipients, so that might not do what you want if you uncommented it. $ grep japan /usr/local/etc/postfix/virtual ja...@xanmax.com xander+ja...@xanmax.com,kris+ja...@kreme.com,lb+ja...@kreme.com Never gets used, because that file is for mapping addresses in virtual alias domains, of which xanmax.com is not one. $ postmap -q ja...@xanmax.com hash:/usr/local/etc/postfix/virtual xander+ja...@xanmax.com,kris+ja...@kreme.com,lb+ja...@kreme.com Which would be great, if Postfix knew that it should map xanmax.com addresses as virtual aliases, however it knows this not. Feb 8 15:24:31 mail postfix/pipe[63027]: 3pzhjW3HX6zJMjC: to=, orig_to=, relay=dovecot, delay=0.12, delays=0.09/0.01/0/0.02, dsn=5.1.1, status=bounced (user unknown) I confess to some confusion as to how THIS happened, since you didn't include any other of the log lines involving the queue item 3pzhjW3HX6zJMjC but I guess it could be a header_checks redirect. It seems clear that Dovecot doesn't know how to deliver mail to ja...@xanmax.com but is trying to do so for some reason, after the And of course there's the black box: The mysql maps aren’t useful and there is far too much personal-isa information in virtual to include it all. I'll take your word for that. The reason that's needed (at least for me...) is that you have shown mail being delivered via 'pipe' rather than 'local' or 'virtual' and that says for sure that you have a non-default delivery rig. Since your problem is in delivery, you must show how your delivery is rigged. That’s some progress at least. Hopefully there’s something obvious in the postconf output. Not 100% obvious or certain, as I thought you were only trying to redirect based on sender, not re-invent mailing list management, but you may want to add xanmax.com to your virtual_alias_domains since you have other config which does nothing without that. If that doesn't get you what you're looking for, post *all* of the log lines related to a delivery that didn't do what you wanted and the headers of that message, since you're doing header-based mail routing
Re: 3.0.3: "mynetworks" values are busted and missing ipv6 info
Quanah Gibson-Mount: > In Postfix > 3.0.x, the value from postconf mynetworks returns incorrect > netmask values, and it is missing IPv6 entirely: This depends on the inet_protocols setting. # postconf inet_protocols=all # postconf mynetworks mynetworks = 127.0.0.1/32 192.168.122.1/32 168.100.189.7/32 [::1]/128 [fe80::223:55ff:fe5c:3985]/128 # postconf inet_protocols=ipv4 # postconf mynetworks mynetworks = 127.0.0.1/32 192.168.122.1/32 168.100.189.7/32 # postconf inet_protocols=ipv6 # postconf mynetworks mynetworks = [::1]/128 [fe80::223:55ff:fe5c:3985]/128 Wietse
Re: Copy mail from specific email address to specific email address to other accounts
On Feb 8, 2016, at 8:26 AM, Bill Cole wrote: > However, there's still something missing in what you've provided: "postconf > -n" output. All of it. Preferably unmunged, but if you absolutely must > obfuscate details, do so programmatically and carefully. Also, if you use ANY > transport maps, include those. $ postconf -n alias_database = hash:$config_directory/aliases alias_maps = hash:$config_directory/aliases, hash:/usr/local/mailman/data/aliases allow_percent_hack = no always_bcc = *munged* bounce_size_limit = 10240 broken_sasl_auth_clients = yes command_directory = /usr/local/sbin compatibility_level = 2 content_filter = smtp-amavis:[127.0.0.1]:10024 daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb $daemon_directory/$process_name $process_id & sleep 5 disable_vrfy_command = yes dovecot_destination_recipient_limit = 1 enable_long_queue_ids = yes header_checks = pcre:/etc/postfix/header_checks.pcre header_size_limit = 10240 home_mailbox = Maildir/ html_directory = /usr/local/share/doc/postfix inet_interfaces = all inet_protocols = ipv4 mail_owner = postfix mailbox_command = /usr/local/bin/procmail -t -a $EXTENSION mailbox_size_limit = 52428800 mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man maps_rbl_reject_code = 521 max_use = 10 message_size_limit = 26214400 meta_directory = /usr/local/libexec/postfix mime_header_checks = pcre:$config_directory/mime_headers.pcre mydestination = $myhostname, localhost.$mydomain, $mydomain, localhost, ns1.$mydomain, ns2.$mydomain, mail.$mydomain, www.$mydomain, webmail.$mydomain mydomain = covisp.net myhostname = mail.covisp.net mynetworks = 75.148.37.64/29, 127.0.0.0/8, 65.121.55.42, , 65.121.55.45, mynetworks_style = subnet myorigin = $mydomain newaliases_path = /usr/local/bin/newaliases policyd-spf_time_limit = 3600 postscreen_access_list = permit_mynetworks, cidr:$config_directory/postscreen_access.cidr postscreen_bare_newline_ttl = 7d postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = dul.dnsbl.sorbs.net*1 zen.spamhaus.org=127.0.0.[10..11]*4 zen.spamhaus.org=127.0.0.[4..7]*6 zen.spamhaus.org=127.0.0.3*6 zen.spamhaus.org=127.0.0.2*6 spam.dnsbl.sorbs.net*2 multi.surbl.org*2 dnsbl-1.uceprotect.net dnsbl-2.uceprotect.net list.dnswl.org=127.0.[0..255].0*-3 list.dnswl.org=127.0.[0..255].1*-4 list.dnswl.org=127.0.[0..255].[2..255]*-6 dwl.spamhaus.org=127.0.2.[2;3]*-3 swl.spamhaus.org=127.0.2.[12;13]*-3 postscreen_dnsbl_threshold = 6 postscreen_dnsbl_ttl = 1d postscreen_greet_action = enforce postscreen_greet_banner = mail.covisp.net ESTMP -- Please wait postscreen_greet_ttl = 7d postscreen_greet_wait = 4s postscreen_pipelining_ttl = 7d queue_directory = /var/spool/postfix readme_directory = /usr/local/share/doc/postfix recipient_delimiter = +_ sample_directory = /usr/local/etc/postfix sender_bcc_maps = pcre:$config_directory/sender_bcc.pcre sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop shlib_directory = /usr/local/lib/postfix show_user_unknown_table_name = no smtp_tls_exclude_ciphers = MD5, aDSS, SRP, PSK, aECDH, aDH, SEED, IDEA, RC2, RC5 smtp_tls_protocols = !SSLv2, !SSLv3 smtp_tls_security_level = may smtpd_banner = $myhostname ESMTP $mail_name $mail_version smtpd_data_restrictions = reject_unauth_pipelining, reject_multi_recipient_bounce, permit smtpd_error_sleep_time = 28 smtpd_hard_error_limit = 8 smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, check_helo_access pcre:/etc/postfix/helo_checks.pcre permit smtpd_recipient_limit = 100 smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_invalid_hostname, reject_unlisted_recipient, reject_unlisted_sender, reject_unknown_reverse_client_hostname, check_client_access hash:$config_directory/access, permit smtpd_relay_restrictions = permit_mynetworks reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_soft_error_limit = 4 smtpd_starttls_timeout = 40s smtpd_tls_cert_file = /etc/ssl/certs/postfix.pem smtpd_tls_ciphers = medium smtpd_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4, LOW, EXPORT smtpd_tls_key_file = /etc/ssl/private/postfix.pem smtpd_tls_loglevel = 1 smtpd_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_security_level = may smtputf8_enable = no soft_bounce = no swap_bangpath = no tls_ssl_options = no_ticket, no_compression undisclosed_recipients_header = To: List of Bcc addresses:; unknown_local_recipient_reject_code = 550 virtual_alias_domains = kreme.com virtual_alias_maps = hash:$config_directory/virtual proxy:mysql:$config_directory/mysql_virtual_alias_maps.cf virtual_gid_maps = static:89 virtual_mailbox_base = /usr/loca
3.0.3: "mynetworks" values are busted and missing ipv6 info
In Postfix < 3.0.x, the value from postconf mynetworks was returned with correct netmask values, and includes IPv6: postconf mynetworks mynetworks = 127.0.0.0/8 10.137.242.0/24 [::1]/128 [fc00:10:137:242::]/64 [fe80::]/64 In Postfix > 3.0.x, the value from postconf mynetworks returns incorrect netmask values, and it is missing IPv6 entirely: postconf mynetworks mynetworks = 127.0.0.1/32 10.137.242.53/32 Output from ifconfig: [root@zre-ldap003 libexec]# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:50:56:8F:CB:CD inet addr:10.137.242.53 Bcast:10.137.242.255 Mask:255.255.255.0 inet6 addr: fe80::250:56ff:fe8f:cbcd/64 Scope:Link inet6 addr: fc00:10:137:242::53/64 Scope:Global loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc
Re: transport lookup behavior when tcp table is configured, but not available
> I suggest that you run the tcp_table service under some babysitter > that restarts a failing process like daemontools, init, or systemd. Oh, absolutely. It's an upstart service right now, and we're monitoring it with the same priorities we give to postfix. > Postfix will always defer mail when any map or lookup table is > unavailable. > > This is not configurable. I really appreciate the quick replies that confirmed my observations! Thanks, Nathan On Mon, Feb 8, 2016 at 1:45 PM Wietse Venema wrote: > Nathan Anderson: > > Hi all! > > > > I've built a server that conforms to tcp_table working correctly, but > I've > > got a question regarding a transport_map tcp_table. If the tcp service > is > > unavailable is it possible to configure postfix to use the default > > transport, or will postfix always log an error and defer the emails? > > As a general rule, Postfix lookup tables have no "on error" fall-back > feature (a response of "does not exist" is not an error). In your > case that means that the transport_maps feature will report that the > table is unavailable. > > I suggest that you run the tcp_table service under some babysitter > that restarts a failing process like daemontools, init, or systemd. > > Wietse > -- Nathan Anderson Basecamp
Re: transport lookup behavior when tcp table is configured, but not available
Nathan Anderson: > Hi all! > > I've built a server that conforms to tcp_table working correctly, but I've > got a question regarding a transport_map tcp_table. If the tcp service is > unavailable is it possible to configure postfix to use the default > transport, or will postfix always log an error and defer the emails? As a general rule, Postfix lookup tables have no "on error" fall-back feature (a response of "does not exist" is not an error). In your case that means that the transport_maps feature will report that the table is unavailable. I suggest that you run the tcp_table service under some babysitter that restarts a failing process like daemontools, init, or systemd. Wietse
Re: p0f milter for Postfix?
> Yes. The real question I have is why one would choose that architecture. > I'm used to the idea of putting a layer of relays outside a core mail > system with the IPs of the public MX records and all the filtering cruft > *outside* so that inside mail systems can be simpler or run problematic > stuff like Exchange. I've never seen a system where the outside MX layer > doesn't handle filtering. It seems pointless to me, although obviously > it is not for you. I do have a reason for this particular architecture, but I don't think people would appreciate my going into detail about it here because it's not narrowly specific to Postfix. Rich Wales ri...@richw.org
Re: transport lookup behavior when tcp table is configured, but not available
On 2/8/2016 9:58 AM, Nathan Anderson wrote: > Hi all! > > I've built a server that conforms to tcp_table working correctly, > but I've got a question regarding a transport_map tcp_table. If the > tcp service is unavailable is it possible to configure postfix to > use the default transport, or will postfix always log an error and > defer the emails? Postfix will always defer mail when any map or lookup table is unavailable. This is not configurable. -- Noel Jones
transport lookup behavior when tcp table is configured, but not available
Hi all!
I've built a server that conforms to tcp_table working correctly, but I've
got a question regarding a transport_map tcp_table. If the tcp service is
unavailable is it possible to configure postfix to use the default
transport, or will postfix always log an error and defer the emails?
I assumed that if a transport map was unavailable, the default_transport
option would be used. Instead, I'm getting the following errors:
Jan 28 00:35:48 test.host.domain postfix/trivial-rewrite[8906]: warning:
tcp:localhost:5000 lookup error for "user@domain"
Jan 28 00:35:48 test.host.domain postfix/error[17114]: 23CEF1C01C1:
to=, relay=none, delay=27, delays=18/9/0/0.01, dsn=4.3.0,
status=deferred (address resolver failure)
I've added another static map after the tcp:localhost:5000 entry, thinking
that it might pick it up after the failed connection to the tcp service,
but that doesn't work, either.
We're running 2.9.3-2~12.04.4 (Ubuntu), and my postconf -n (with specific
hosts/IP's redacted):
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
bounce_template_file = /etc/postfix/bounces.cf
config_directory = /etc/postfix
default_destination_concurrency_failed_cohort_limit = 20
default_destination_concurrency_limit = 3
disable_vrfy_command = yes
gmail_destination_concurrency_limit = 20
header_checks = regexp:/etc/postfix/header_checks
inet_interfaces = all
inet_protocols = ipv4
local_header_rewrite_clients = static:none
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
message_size_limit = 29360128
milter_default_action = accept
milter_protocol = 2
mydestination = foobar, localhost
myhostname = foobar
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = foobar
non_smtpd_milters = inet:localhost:8891
readme_directory = no
recipient_delimiter = +
relayhost =
sender_dependent_default_transport_maps = regexp:/etc/postfix/sdd_
transport_maps.regexp
slow_delivery_destination_concurrency_limit = 2
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
smtp_tls_scert_verifydepth = 2
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_milters = inet:localhost:8891
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
transport_maps = hash:/etc/postfix/transport tcp:localhost:5000
unknown_local_recipient_reject_code = 550
Thanks,
Nathan
--
Nathan Anderson
Basecamp
Re: p0f milter for Postfix?
On 8 Feb 2016, at 2:55, Rich Wales wrote: Hi. Does a milter or other solution exist to allow Postfix to insert OS fingerprint information into incoming e-mail via p0f? If you are desperate enough for this in milter form, you could do it using the MIMEDefang milter, which is designed for doing much more but can be given a trivial filter script that can do anything you can write the Perl to do: even a system() call to run a bit of shell if you're really into nasty hacks... Another option would be to put an amavisd-new instance on your outside hosts with a degenerate config that only does the p0f bit and hands the messages back to the outside Postfix or directly to the inside. I know it's possible to insert p0f info via amavisd-new, but I'm running MX hosts in front of my mail server (where I run amavisd-new), and if I'm going to use p0f, I assume I need to run it on my MX hosts and not on the mail server itself (since p0f on my mail server would be fingerprinting my MX hosts and not the actual source of a message). Yes. The real question I have is why one would choose that architecture. I'm used to the idea of putting a layer of relays outside a core mail system with the IPs of the public MX records and all the filtering cruft *outside* so that inside mail systems can be simpler or run problematic stuff like Exchange. I've never seen a system where the outside MX layer doesn't handle filtering. It seems pointless to me, although obviously it is not for you.
Re: Copy mail from specific email address to specific email address to other accounts
On 8 Feb 2016, at 0:25, LuKreme wrote: On Feb 7, 2016, at 14:12, Wietse Venema wrote: Viktor Dukhovni: On Feb 7, 2016, at 3:16 PM, @lbutlr wrote: /usr/local/etc/postfix which has a symlink at /etc/psotfix and That is unlikely. [...] No, it is unlikely, because he said it was linked to /etc/psotfix. I said that /usr/local/etc/postfix HAS a symlink at /etc/postfix/. See it now? It was about your typo. The email had errors in command (postmap -q -q) and pathname (/etc/psotfix) information. If someone else wants to give it a try, they are most welcome. All config files are in /usr/local/etc/postfix/, /etcpostfix is just a link. Presumably you mean /etc/postfix/, which makes more sense. Postmap -q returns th correct value, postfix itself does not access the virtual table for the header_checks or sender_bcc_maps or check_sender_access. I've provided unmunged postmap and master.cf. there are no errors or warnings in the logs. I don't know what to do now, and I don't understand at all why you think I am lying. Hyperliteralism? That's not a terrible trait when trying to provide technical support, given the endemic problem of people making simple config errors that are or resemble trivial typos, sometimes consciously and intentionally. Just last week someone here was arguing with Dr. Venema about how Postfix finds config files... However, there's still something missing in what you've provided: "postconf -n" output. All of it. Preferably unmunged, but if you absolutely must obfuscate details, do so programmatically and carefully. Also, if you use ANY transport maps, include those. The reason that's needed (at least for me...) is that you have shown mail being delivered via 'pipe' rather than 'local' or 'virtual' and that says for sure that you have a non-default delivery rig. Since your problem is in delivery, you must show how your delivery is rigged.
