Questions[aliases](server)

Just upgraded to debian bullseye postfix 3.5.6 from debian wheezy postfix 2.9.6.

We use virtual alias maps to multiple recipients, like this one:

[email protected] @theidsp-network.inter-realm.net,[email protected]

Thereby, mails sent to [email protected] are forwarded both to [email protected] and to [email protected]. It has been functioning correctly for years.

We previously learned from http://www.postfix.org/virtual.5.html that the order of the multiple recipients is important. "When the result has the form @otherdomain, the result becomes the same user in otherdomain. This works only for the first address in a multi-address lookup result." So we put the wildcard @ recipient first.

After the postfix upgrade, the smtpd seems to be attempting to forward to a single recipient "[email protected],jim"@space-port-pros.com.

Since the user does not exist, this mail is dropping to the catchall.

Here is some output from the mail.log:

Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: connect to subsystem private/proxymap
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: send attr request = lookup
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: send attr table = mysql:/etc/postfix/mysql-virtual_forwardings.cf
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: send attr flags = 540736
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: send attr key = [email protected]
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: private/proxymap socket: wanted attribute: status
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: input attribute name: status
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: input attribute value: 0
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: private/proxymap socket: wanted attribute: value
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: input attribute name: value
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: input attribute value: @theidsp-network.inter-realm.net,[email protected]
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: private/proxymap socket: wanted attribute: (list terminator)
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: input attribute name: (end)
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: dict_proxy_lookup: table=mysql:/etc/postfix/mysql-virtual_forwardings.cf flags=lock|fold_fix|utf8_request
 [email protected] -> status=0 [email protected],[email protected]
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: maps_find: virtual_alias_maps: proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf(0,lock|fold_fix|utf8
_request): [email protected] = @theidsp-network.inter-realm.net,[email protected]
Apr 14 10:45:17 mail7-057 sslmx/smtpd[8640]: mail_addr_find: [email protected] -> @theidsp-network.inter-realm.net,[email protected]
...
Apr 14 10:45:17 mail7-057 postfix/smtp[8669]: 55E65C895: to=<"[email protected],jim"@space-port-pros.com>, orig_to=<jimays@theids
p.net>, relay=mail7-052.idsp56.net[192.168.56.52]:52025, delay=0.06, delays=0.01/0.02/0.01/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 5F628
A882)

Here are snippets from a log from June showing that the forward previously resulted in two distinct lines with status=sent, one via smtp transport to [email protected] and one via lmtp-g transport to [email protected].

Jun 20 06:30:58 mail7-057 sslmx/smtpd[28956]: connect from mail7-055.idsp56.net[192.168.56.55]
Jun 20 06:30:58 mail7-057 sslmx/smtpd[28956]: Anonymous TLS connection established from mail7-055.idsp56.net[192.168.56.55]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
Jun 20 06:30:58 mail7-057 sslmx/smtpd[28956]: B91A42BE4: client=mail7-055.idsp56.net[192.168.56.55]
Jun 20 06:30:58 mail7-057 cleanup-srs/cleanup[28963]: B91A42BE4: message-id=<[email protected]>
Jun 20 06:30:58 mail7-057 postfix/qmgr[19327]: B91A42BE4: from=<SRS0=Z5tX=LO=connect.match.com=bounces-MA-1-858-ea0868c4-498f-401a-b6f1-c3ce593994a7@trumail7.inter-dimensional-space-port.net>, size=47942, nrcpt=2 (queue active)
Jun 20 06:30:58 mail7-057 sslmx/smtpd[28956]: disconnect from mail7-055.idsp56.net[192.168.56.55]
Jun 20 06:30:58 mail7-057 postfix/smtp[28966]: Anonymous TLS connection established to mail7-052.idsp56.net[192.168.56.52]:52025: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
Jun 20 06:30:58 mail7-057 lmtp-g/lmtp[28965]: Trusted TLS connection established to lmtp7-g.inter-dimensional-space-port.net[216.184.19.228]:64007: TLSv1 with cipher AES256-SHA (256/256 bits)
Jun 20 06:30:58 mail7-057 postfix/smtp[28966]: B91A42BE4: to=<[email protected]>, relay=mail7-052.idsp56.net[192.168.56.52]:52025, delay=0.16, delays=0.04/0.02/0.02/0.08, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as C66855B94)
Jun 20 06:30:59 mail7-057 sslmx/smtpd[28956]: connect from mail7-055.idsp56.net[192.168.56.55]
Jun 20 06:30:59 mail7-057 sslmx/smtpd[28956]: Anonymous TLS connection established from mail7-055.idsp56.net[192.168.56.55]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
Jun 20 06:30:59 mail7-057 sslmx/smtpd[28956]: 9D1D12CA5: client=mail7-055.idsp56.net[192.168.56.55]
Jun 20 06:30:59 mail7-057 cleanup-srs/cleanup[28963]: 9D1D12CA5: message-id=<[email protected]>
Jun 20 06:30:59 mail7-057 postfix/qmgr[19327]: 9D1D12CA5: from=<SRS0=Z5tX=LO=connect.match.com=bounces-MA-1-858-ea0868c4-498f-401a-b6f1-c3ce593994a7@trumail7.inter-dimensional-space-port.net>, size=50423, nrcpt=1 (queue active)
Jun 20 06:30:59 mail7-057 sslmx/smtpd[28956]: disconnect from mail7-055.idsp56.net[192.168.56.55]
Jun 20 06:31:07 mail7-057 lmtp-g/lmtp[28965]: B91A42BE4: to=<[email protected]>, relay=lmtp7-g.inter-dimensional-space-port.net[216.184.19.228]:64007, delay=8.9, delays=0.04/0.02/0.12/8.7, dsn=2.0.0, status=sent (250 Ok)
Jun 20 06:31:07 mail7-057 postfix/qmgr[19327]: B91A42BE4: removed

The http://www.postfix.org/COMPATIBILITY_README.html did not mention anything specific about a behavior change in virtual alias maps.

mysql-virtual_forwardings.cf is in a standard format created by ISPConfig.

user = ispconfig
password = redacted
dbname = idsp_mail7_062
table = mail_forwarding
select_field = destination
where_field = source
additional_conditions = and active = 'y' and server_id = 81
hosts = 192.168.56.121

The pertinent piece of main.cf which invokes the file is:

virtual_alias_maps = regexp:/etc/postfix/regexp-virtual_forwardings__admin.cf, proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, proxy:mysql:/etc
/postfix/mysql-virtual_email2email.cf

The virtual_forwardings table looks like:

MariaDB [idsp_mail7_057]> select * from mail_forwarding where source='[email protected]';
+---------------+------------+-------------+---------------+----------------+----------------+-----------+--------------------+----------------------------------------------------------+---------+--------+
| forwarding_id | sys_userid | sys_groupid | sys_perm_user | sys_perm_group | sys_perm_other | server_id | source             | destination                                              | type    | active |
+---------------+------------+-------------+---------------+----------------+----------------+-----------+--------------------+----------------------------------------------------------+---------+--------+
|           201 |          2 |           2 | riud          | riud           |                |        69 | [email protected] | @theidsp-network.inter-realm.net,[email protected] | forward | y      |
+---------------+------------+-------------+---------------+----------------+----------------+-----------+--------------------+----------------------------------------------------------+---------+--------+
1 row in set (0.001 sec)

Increased logging to smtpd -v -v and this shows in the log:

dict_proxy_lookup: table=mysql:/etc/postfix/mysql-virtual_forwardings.cf flags=lock|fold_fix|utf8_request
 [email protected] -> status=0 [email protected],[email protected]
Apr 20 16:44:37 mail7-057 sslmx/smtpd[9561]: maps_find: virtual_alias_maps: proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf(0,lock|fold_fix|utf8
_request): [email protected] = @theidsp-network.inter-realm.net,[email protected]
Apr 20 16:44:37 mail7-057 sslmx/smtpd[9561]: mail_addr_find: [email protected] -> @theidsp-network.inter-realm.net,[email protected]

so it appears the lookup is happening correctly, and then still only one dispatch happens instead of two.

We run a small postfix (and dovecot) mail server for a number of hosted domains, using virtual alias maps and with spamassassin configured.

Recently it's become apparent that we're generating some backscatter; spam emails are coming into non-existant email addresses and they are being bounced back to the forged sender. This is obviously a problem in terms of reputation for our mail server and also means we're spamming on behalf of the spammers.

What I want to do then is change the postfix behaviour so that, instead of generating a bounce email form MAILER-DAEMON the mail is rejected during the SMTP transaction.

I've tried adding local_recipient_maps (http://www.postfix.org/LOCAL_RECIPIENT_README.html), but this made no difference. I think this is because I'm using virtual_alias_maps (and other virtual mailbox solutions don't seem to apply here either).

postconf -n generates:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5
html_directory = no
inet_interfaces = all
inet_protocols = all
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
mail_owner = postfix
mail_spool_directory = /var/spool/mail
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 0
mydestination = $myhostname, localhost.$mydomain, localhost
mydomain = verrotech.com
myhostname = mail.verrotech.com
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES
sample_directory = /usr/share/doc/postfix-2.10.1/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.domain.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.domain.com/privkey.pem
smtpd_tls_security_level = may
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual

Thank you.

First question here on serverfault, so kind of a newbie, all feedback is welcome.

I have a dedicated server running Debian GNU/Linux 8.4 (jessie) with one public IP and multiple additional public IPs assigned to it. Server has two NICs, eth0 and eth1, server main public IP is routed to eth1). All additional public IPs are assigned to alias interfaces (eth1:0, eth1:1, eth1:2 etc) except for 1 IP, which I want to assign to a KVM guest, but in a routed networking configuration (the datacenter does not allow multiple MAC addresses to connect to the switch ports, so I have no option but to use routing instead of bridging).

I have set up the interface aliases, and I can assign the corresponding public IPs to different virtualhosts under Apache 2.4 (through the use of ISPConfig 3 web hosting control panel). The virtualhosts work fine in this configuration. Yet, when I try to add a routed network bridge (vmbr0) and route the KVM guest traffic through it, I lose connectivity and have to reboot the server. After reboot, the server works for some time (minutes), and loses connectivity again. I can't seem to figure out what is wrong.

Note: I have followed the Hetzner guide [https://wiki.hetzner.de/index.php/Netzkonfiguration_Debian/en#Routed_.28brouter.29] on another host system, and the KVM guests work alright. Only difference is the aliased interfaces I also need to have in this case.

I have created the bridge interface with:

brctl addbr vmbr0

prior to restarting networking with

/etc/init.d/networking restart

Network configuration for the host system:

auto lo
        iface lo inet loopback

auto eth0
        iface eth0 inet manual

auto eth1
        iface eth1 inet static
        address AAA.AAA.AAA.AAA
        netmask 255.255.255.0
        gateway AAA.AAA.AAA.1
        pointopoint AAA.AAA.AAA.1

auto eth1:1
        iface eth1:1 inet static
        address BBB.BBB.BBB.BBB
        netmask 255.255.255.255

auto eth1:2
        iface eth1:2 inet static
        address CCC.CCC.CCC.CCC
        netmask 255.255.255.255

auto eth1:3
        iface eth1:3 inet static
        address DDD.DDD.DDD.DDD
        netmask 255.255.255.255

auto eth1:4
        iface eth1:4 inet static
        address EEE.EEE.EEE.EEE
        netmask 255.255.255.255

auto eth1:5
        iface eth1:5 inet static
        address FFF.FFF.FFF.FFF
        netmask 255.255.255.255

auto eth1:6
        iface eth1:6 inet static
        address GGG.GGG.GGG.GGG
        netmask 255.255.255.255

auto eth1:7
        iface eth1:7 inet static
        address HHH.HHH.HHH.HHH
        netmask 255.255.255.255

auto eth1:8
        iface eth1:8 inet static
        address III.III.III.III
        netmask 255.255.255.255

auto eth1:9
        iface eth1:9 inet static
        address JJJ.JJJ.JJJ.JJJ
        netmask 255.255.255.255

auto eth1:10
        iface eth1:10 inet static
        address KKK.KKK.KKK.KKK
        netmask 255.255.255.255

# KVM VM routed (bridge) interface for single IPs
auto vmbr0
iface vmbr0 inet static
       address         AAA.AAA.AAA.AAA
       netmask         255.255.255.0
       bridge_ports    none
       bridge_stp      off
       bridge_fd       0

#      up ip route add ip1_goes_here/32 dev vmbr0
#      up ip route add ip2_goes_here/32 dev vmbr0
#      up ip route add ip3_goes_here/32 dev vmbr0

I haven't yet created the KVM guest machine. Perhaps I should have a running VM and traffic routed to it BEFORE bringing the vmbr0 bridge up for some reason? If I can make this work, I'll add additional KVM guests with additional public IPs assigned to them.

Last thing to add is, this is a server already running some websites, so if what I need can be done and with minimum downtime that'd be great!

Thanks!

Possible Duplicate:
How to configure postfix to pipe all incoming email to a script?

I'm having problems setting up simple piping for Redmine (or '|cat > /tmp/temp')

/etc/postfix/virtual:

[email protected] support

/etc/postfix/aliases:

support: "|/opt/redmine-1.2.2/processemail.sh"

main.cf

virtual_alias_maps = hash:/etc/postfix/virtual, mysql:/etc/postfix/mysql_virtual_forwards.cf
virtual_mailbox_domains = myhost.com, mysql:/etc/postfix/mysql_virtual_domains.cf
virtual_mailbox_maps = hash:/etc/postfix/virtual_alias, mysql:/etc/postfix/mysql_virtual_mailboxes.cf

alias_maps = hash:/etc/postfix/aliases
alias_database = $alias_maps

processemail.sh:

#!/bin/sh
/opt/redmine-1.2.2/extra/mail_handler/rdm-mailhandler.rb --url http://myhost.com --key f5obfctmGfqZWnOWNtR8 --project test --tracker support --allow-override tracker,project --verbose --unknown-user accept --no-permission-check

I've run newaliases; postmap virtual; postalias aliases; postalias virtual_alias; newalias - Yeah, probably overdoes it, but still misses the pouint :(

I've run newaliases and restarted postfix. Mail is delivered as usual, but nothing is added to /tmp

This is the only log entry saying anything about virtual.

Dec 10 04:08:41 master postfix/virtual[3112]:
A3F46AD1BF: to=<[email protected]>, relay=virtual, delay=0.4,
delays=0.38/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to maildir)

If I run cat someemail | processemail.sh in the shell, everything works. Processemail isn't even run by postfix.

Anyone knows what might be wrong? Or how I can turn on more logging?

I've got a hosted exchange solution through Apptix, which isn't the problem, I think, but it may be relevant.

I have my main account, [email protected], and to that, I have an alias, [email protected].

Whenever I send an email to [email protected], I examine the headers, and I see the "To:" field being correct, "To: [email protected]". All is well.

I recently set up another user, [email protected] to function as a multipurpose mailbox. I aliased "[email protected]" to the services account in the same method that I did "[email protected]", however nothing I have sent to "[email protected]" actually goes TO "[email protected]". All of the headers say "To: [email protected]". This makes it extremely difficult to filter based on headers alone.

Does anyone have any feedback on what settings I would need to look at in order to fix that?