Re: postfix munin graphs
I think I need to tell munin where my postfix logs are (/var/log/mail/current) since I use metalog. How can I do that? - Grant Try'n read some documentation http://munin.readthedocs.org/en/latest/ I've read a lot of it but: 0 Results for postfix Then check out /etc/munin/plugin-conf.d/munin-node I've successfully configured apache and nginx in that file but munin postfix config is extremely hard to find online. - Grant And then, if Munin still doesn't work, the Munin-folks might be better to help out http://munin-monitoring.org/wiki/HowToGetHelp
Re: postfix munin graphs
On 06/19/2013 08:18 AM, Grant wrote: I think I need to tell munin where my postfix logs are (/var/log/mail/current) since I use metalog. How can I do that? - Grant Try'n read some documentation http://munin.readthedocs.org/en/latest/ I've read a lot of it but: 0 Results for postfix Then check out /etc/munin/plugin-conf.d/munin-node I've successfully configured apache and nginx in that file but munin postfix config is extremely hard to find online. Instead of searching online, use the built-in pod based format, e.g.: $ munindoc postfix_mailstats NAME postfix_mailstats - Plugin to monitor the number of mails delivered and rejected by postfix CONFIGURATION Configuration parameters for /etc/munin/postfix_mailstats, if you need to override the defaults below: [postfix_mailstats] env.logdir - Which logfile to use env.logfile - What file to read in logdir DEFAULT CONFIGURATION [postfix_mailstats] env.logdir /var/log env.logfile mail.log Munin plugins are controlled by the files in /etc/munin/plugin-conf.d/. Based on the above, either create a section for postfix_mailstats in the file munin-node or create a new one (they will all be parsed), detailing the location of your mail log. Explicitly, if your mail log is /var/log/mail/current, add this: [postfix_mailstats] env.logdir /var/log/mail env.logfile current You might also need to set group permissions to be able to read the log file. -- Bjørn
Re: Getting around Comcast Port 25 Block with a Local + Remote Postfix Server?
On 18 Jun 2013, at 10:45 , Al Zick a...@familysafeinternet.com wrote: Does anyone know if Comcast will let you relay emails through there mail server that do not have a comcast email address? Yes, they will. So will Google. Mac.com, otoh, will not (last I checked). -- I find Windows of absolutely no technical interest... Mac OS X is a rock -solid system that's beautifully designed. I much prefer it to Linux. -- Bill Joy
Re: postfix munin graphs
I think I need to tell munin where my postfix logs are (/var/log/mail/current) since I use metalog. How can I do that? Instead of searching online, use the built-in pod based format, e.g.: $ munindoc postfix_mailstats You just improved my life. You might also need to set group permissions to be able to read the log file. I have this on /var/log/mail/: drwx-- 2 rootroot Since Gentoo set it up this way, I wonder if changing it would open a hole. What do you think? - Grant
Re: postfix munin graphs
I think I need to tell munin where my postfix logs are (/var/log/mail/current) since I use metalog. How can I do that? Instead of searching online, use the built-in pod based format, e.g.: $ munindoc postfix_mailstats You just improved my life. You might also need to set group permissions to be able to read the log file. I have this on /var/log/mail/: drwx-- 2 rootroot Since Gentoo set it up this way, I wonder if changing it would open a hole. What do you think? - Grant Actually, it seems to be working with permissions as-is. How can that be since apache runs as apache:apache? - Grant
Re: postfix munin graphs
On 06/19/2013 10:03 AM, Grant wrote: I think I need to tell munin where my postfix logs are (/var/log/mail/current) since I use metalog. How can I do that? Instead of searching online, use the built-in pod based format, e.g.: $ munindoc postfix_mailstats You just improved my life. You might also need to set group permissions to be able to read the log file. I have this on /var/log/mail/: drwx-- 2 rootroot Since Gentoo set it up this way, I wonder if changing it would open a hole. What do you think? - Grant Actually, it seems to be working with permissions as-is. How can that be since apache runs as apache:apache? The webinterface (running as apache:apache) does not collect the data, the munin-node daemon does that. Probably the data collection is configured to run as root (at least for the postfix plugin). Again, read the docs ;) You seem to have missed (a part of) the basic understanding of how munin works... -- Tom signature.asc Description: OpenPGP digital signature
Re: postfix munin graphs
I think I need to tell munin where my postfix logs are (/var/log/mail/current) since I use metalog. How can I do that? Instead of searching online, use the built-in pod based format, e.g.: $ munindoc postfix_mailstats You just improved my life. You might also need to set group permissions to be able to read the log file. I have this on /var/log/mail/: drwx-- 2 rootroot Since Gentoo set it up this way, I wonder if changing it would open a hole. What do you think? - Grant Actually, it seems to be working with permissions as-is. How can that be since apache runs as apache:apache? The webinterface (running as apache:apache) does not collect the data, the munin-node daemon does that. Probably the data collection is configured to run as root (at least for the postfix plugin). Again, read the docs ;) You seem to have missed (a part of) the basic understanding of how munin works... I knew that. I just didn't think it through. :) Thanks for your help! - Grant
Is this an attack?
One of my mail servers (postfix 2.6) has been target of what seems to me to be an attack. The attacker tried to deliver messages to a non-existent user names formed as a long hex string. It only happened once from one particular client and kept going for some time. SMTP sessions were coming in one every second with three delivery attampts each. Here is a fragment of one single session: Out: 220 prot..eu ESMTP Postfix In: EHLO xx Out: 250-prot..eu Out: 250-PIPELINING Out: 250-SIZE 1024 Out: 250-VRFY Out: 250-ETRN Out: 250-ENHANCEDSTATUSCODES Out: 250-8BITMIME Out: 250 DSN In: MAIL FROM:x...@xx.xxx.xx SIZE=2881 BODY=7BIT Out: 250 2.1.0 Ok In: RCPT TO:35150aa4c74ba30f04ede17ca25f1...@.yy Out: 451 4.3.0 35150aa4c74ba30f04ede17ca25f1...@.yy: Temporary lookup failure In: RCPT TO:357f21a54e272af6a629ff7657eae...@.yy Out: 451 4.3.0 357f21a54e272af6a629ff7657eae...@.yy: Temporary lookup failure In: RSET Out: 250 2.0.0 Ok In: MAIL FROM:xx...@xx.xxx.xx SIZE=2881 BODY=7BIT Out: 250 2.1.0 Ok In: RCPT TO:947a7c9627f3977247586a4fca58b...@.yy Out: 451 4.3.0 947a7c9627f3977247586a4fca58b...@x.yy: Temporary lookup failure In: QUIT Out: 221 2.0.0 Bye Is this an attack of some sort?
Local UNIX accounts, aliasing rejecting mail to non-public UNIX accounts
I'm setting up Postfix for a domain that hosts Dovecot IMAP mail dirs for real Unix accounts. Postfix needs to accept mail for users' public aliases, but not their Unix login, and reject mail for daemon accounts. e.g: joe.blo...@example.com -- jb4356 jane.blos...@example.com-- jb8921 postmas...@example.com -- postmaster ab...@example.com -- postmaster hostmas...@example.com -- hostmaster The above are in /etc/passwd: postmas...@example.com -- postmaster hostmas...@example.com -- hostmaster jb4...@example.com -- reject as unknown jb8...@example.com -- reject as unknown s...@example.com-- reject as unknown na...@example.com -- reject as unknown dove...@example.com -- reject as unknown sq...@example.com -- reject as unknown post...@example.com -- reject as unknown jb4...@server1.example.com -- reject as unknown jb8...@server2.example.com -- reject as unknown ... ... main.cf [part]: mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain myorigin = $mydomain mail_spool_directory = /var/mail/ mailbox_transport = lmtp:unix:private/dovecot-lmtp local_recipient_maps = proxy:unix:passwd.byname $alias_maps alias_maps = btree:$config_directory/aliases alias_database = btree:$config_directory/aliases local_transport = local:$myhostname canonical_maps = btree:$config_directory/canonical.map virtual_alias_domains = btree:$config_directory/virtual_alias_domains.map virtual_alias_maps = btree:$config_directory/virtual_alias_maps.map $ cat virtual_alias_domains.map example.com virtual $ head virtual_alias_maps.map postmaster postmaster abuse postmaster hostmaster hostmaster joe.blo...@example.com jb4356 jane.blos...@example.comjb8921 $ head canonical.map hostmaster hostmas...@example.com postmaster postmas...@example.com jb4356 joe.blo...@example.com jb8921 jane.blos...@example.com I've experimented with various settings and found that it works if I list the valid public address mappings as virtual aliases, but Postfix complains with: postfix/trivial-rewrite[3585]: warning: do not list domain example.com in BOTH mydestination and virtual_alias_domains. I've thumbed through 'The Book of Postfix' the packaged HTML *READMEs. The examples appear to be for either fully virtual accounts, or Unix accounts where joe@ has a Unix account of 'joe'. There's probably something simple I'm not understanding here. Help appreciated, -- Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7
Re: Is this an attack?
Zitat von Andreas Kasenides andr...@cymail.eu: One of my mail servers (postfix 2.6) has been target of what seems to me to be an attack. The attacker tried to deliver messages to a non-existent user names formed as a long hex string. It only happened once from one particular client and kept going for some time. SMTP sessions were coming in one every second with three delivery attampts each. Here is a fragment of one single session: Out: 220 prot..eu ESMTP Postfix In: EHLO xx Out: 250-prot..eu Out: 250-PIPELINING Out: 250-SIZE 1024 Out: 250-VRFY Out: 250-ETRN Out: 250-ENHANCEDSTATUSCODES Out: 250-8BITMIME Out: 250 DSN In: MAIL FROM:x...@xx.xxx.xx SIZE=2881 BODY=7BIT Out: 250 2.1.0 Ok In: RCPT TO:35150aa4c74ba30f04ede17ca25f1...@.yy Out: 451 4.3.0 35150aa4c74ba30f04ede17ca25f1...@.yy: Temporary lookup failure In: RCPT TO:357f21a54e272af6a629ff7657eae...@.yy Out: 451 4.3.0 357f21a54e272af6a629ff7657eae...@.yy: Temporary lookup failure In: RSET Out: 250 2.0.0 Ok In: MAIL FROM:xx...@xx.xxx.xx SIZE=2881 BODY=7BIT Out: 250 2.1.0 Ok In: RCPT TO:947a7c9627f3977247586a4fca58b...@.yy Out: 451 4.3.0 947a7c9627f3977247586a4fca58b...@x.yy: Temporary lookup failure In: QUIT Out: 221 2.0.0 Bye Is this an attack of some sort? The address harvester of the spammers sometimes collect everything which has a @ in it and therefore even use message-ids in their spamlist. Nothing to worry about Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: Local UNIX accounts, aliasing rejecting mail to non-public UNIX accounts
On 6/19/2013 6:11 AM, Craig R. Skinner wrote: I'm setting up Postfix for a domain that hosts Dovecot IMAP mail dirs for real Unix accounts. Postfix needs to accept mail for users' public aliases, but not their Unix login, and reject mail for daemon accounts. e.g: joe.blo...@example.com-- jb4356 jane.blos...@example.com -- jb8921 postmas...@example.com-- postmaster ab...@example.com -- postmaster hostmas...@example.com-- hostmaster The above are in /etc/passwd: postmas...@example.com-- postmaster hostmas...@example.com-- hostmaster jb4...@example.com-- reject as unknown jb8...@example.com-- reject as unknown s...@example.com -- reject as unknown na...@example.com -- reject as unknown dove...@example.com -- reject as unknown sq...@example.com -- reject as unknown post...@example.com -- reject as unknown jb4...@server1.example.com -- reject as unknown jb8...@server2.example.com -- reject as unknown ... ... main.cf [part]: mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain myorigin = $mydomain mail_spool_directory = /var/mail/ mailbox_transport = lmtp:unix:private/dovecot-lmtp local_recipient_maps = proxy:unix:passwd.byname $alias_maps alias_maps = btree:$config_directory/aliases alias_database = btree:$config_directory/aliases local_transport = local:$myhostname canonical_maps = btree:$config_directory/canonical.map virtual_alias_domains = btree:$config_directory/virtual_alias_domains.map virtual_alias_maps = btree:$config_directory/virtual_alias_maps.map $ cat virtual_alias_domains.map example.com virtual $ head virtual_alias_maps.map postmasterpostmaster abuse postmaster hostmasterhostmaster joe.blo...@example.comjb4356 jane.blos...@example.com jb8921 $ head canonical.map hostmasterhostmas...@example.com postmasterpostmas...@example.com jb4356joe.blo...@example.com jb8921jane.blos...@example.com I've experimented with various settings and found that it works if I list the valid public address mappings as virtual aliases, but Postfix complains with: postfix/trivial-rewrite[3585]: warning: do not list domain example.com in BOTH mydestination and virtual_alias_domains. What happens when you try mydestination = I've thumbed through 'The Book of Postfix' the packaged HTML *READMEs. The examples appear to be for either fully virtual accounts, or Unix accounts where joe@ has a Unix account of 'joe'. There's probably something simple I'm not understanding here. Has happened to me on more than one occasion. ;) -- Stan
Re: Is this an attack?
On 19/06/2013 14:37, lst_ho...@kwsoft.de wrote: Zitat von Andreas Kasenides andr...@cymail.eu: One of my mail servers (postfix 2.6) has been target of what seems to me to be an attack. The attacker tried to deliver messages to a non-existent user names formed as a long hex string. It only happened once from one particular client and kept going for some time. SMTP sessions were coming in one every second with three delivery attampts each. Here is a fragment of one single session: Out: 220 prot..eu ESMTP Postfix In: EHLO xx Out: 250-prot..eu Out: 250-PIPELINING Out: 250-SIZE 1024 Out: 250-VRFY Out: 250-ETRN Out: 250-ENHANCEDSTATUSCODES Out: 250-8BITMIME Out: 250 DSN In: MAIL FROM:x...@xx.xxx.xx SIZE=2881 BODY=7BIT Out: 250 2.1.0 Ok In: RCPT TO:35150aa4c74ba30f04ede17ca25f1...@.yy Out: 451 4.3.0 35150aa4c74ba30f04ede17ca25f1...@.yy: Temporary lookup failure In: RCPT TO:357f21a54e272af6a629ff7657eae...@.yy Out: 451 4.3.0 357f21a54e272af6a629ff7657eae...@.yy: Temporary lookup failure In: RSET Out: 250 2.0.0 Ok In: MAIL FROM:xx...@xx.xxx.xx SIZE=2881 BODY=7BIT Out: 250 2.1.0 Ok In: RCPT TO:947a7c9627f3977247586a4fca58b...@.yy Out: 451 4.3.0 947a7c9627f3977247586a4fca58b...@x.yy: Temporary lookup failure In: QUIT Out: 221 2.0.0 Bye Is this an attack of some sort? The address harvester of the spammers sometimes collect everything which has a @ in it and therefore even use message-ids in their spamlist. Nothing to worry about All of this should be rejected by 5xx, am I wrong? And I think this temporary lookup failure is not ok Show some log... Levi smime.p7s Description: S/MIME Cryptographic Signature
Re: Local UNIX accounts, aliasing rejecting mail to non-public UNIX accounts
On 2013-06-19 Wed 06:51 AM |, Stan Hoeppner wrote: On 6/19/2013 6:11 AM, Craig R. Skinner wrote: What happens when you try mydestination = That's something I didn't think of trying. Either blank, or with localhost: status=bounced (User unknown in virtual alias table) Which is wierd as as postmap query finds it: postmap -q hostmas...@example.com virtual_alias_maps.map hostmaster Maybe with no destination, it doesn't know what to do with mail for 'user_name' Cheers, -- Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7
Re: postfix munin graphs
Am 2013-06-19 09:56, schrieb Grant: I think I need to tell munin where my postfix logs are (/var/log/mail/current) since I use metalog. How can I do that? Instead of searching online, use the built-in pod based format, e.g.: $ munindoc postfix_mailstats You just improved my life. You might also need to set group permissions to be able to read the log file. I have this on /var/log/mail/: drwx-- 2 rootroot Since Gentoo set it up this way, I wonder if changing it would open a hole. What do you think? i think u should define your syslog-ng.conf. this is not part of the gentoo package maintainer. here munin works like a charm. with postfix. marko - Grant
Re: Local UNIX accounts, aliasing rejecting mail to non-public UNIX accounts
Craig R. Skinner: On 2013-06-19 Wed 06:51 AM |, Stan Hoeppner wrote: On 6/19/2013 6:11 AM, Craig R. Skinner wrote: What happens when you try mydestination = That's something I didn't think of trying. Either blank, or with localhost: status=bounced (User unknown in virtual alias table) This suggests that you had the domain name listed in both mydestination and in virtual_alias_domains. Now you also need to remove the domain name from virtual_alias_domains, in order to make that error go away. Until now Postfix will have logged numerous warnings with do not list domain X in both mydestination and virtual_alias_maps to remind you of a configuration error. Maybe it should just abort deliveries, that might get people's attention. Wietse
Re: Local UNIX accounts, aliasing rejecting mail to non-public UNIX accounts
On 6/19/2013 10:16 AM, Wietse Venema wrote: Craig R. Skinner: On 2013-06-19 Wed 06:51 AM |, Stan Hoeppner wrote: On 6/19/2013 6:11 AM, Craig R. Skinner wrote: What happens when you try mydestination = That's something I didn't think of trying. Either blank, or with localhost: status=bounced (User unknown in virtual alias table) This suggests that you had the domain name listed in both mydestination and in virtual_alias_domains. Now you also need to remove the domain name from virtual_alias_domains, in order to make that error go away. Until now Postfix will have logged numerous warnings with do not list domain X in both mydestination and virtual_alias_maps to remind you of a configuration error. Maybe it should just abort deliveries, that might get people's attention. Wietse I'm anything but an expert in this particular area of Postfix, but I think the problem is that Craig is trying to use virtual_alias_maps when he should probably just be using the local aliases file. His Postfix hosts a single mail domain IIUC. He's simply wanting to create alias addresses presented to the public for each local UNIX mailbox address. Additionally he wants to reject any inbound mail destined for the actual local UNIX addresses, as well as system/role accounts. These last two are straightforward. For the first: /etc/postfix/reject-local-system jb4...@example.com reject Unknown User jb8...@example.com reject Unknown User s...@example.comreject Unknown User na...@example.com reject Unknown User dove...@example.com reject Unknown User sq...@example.com reject Unknown User post...@example.com reject Unknown User and use smtpd_recipient_restrictions ... check_recipient_access hash:/etc/postfix/reject-local-system ... To satisfy the second: jb4...@server1.example.com -- reject as unknown jb8...@server2.example.com -- reject as unknown Simply do not put $myhostname, localhost.$mydomain in mydestination, assuming $myhostname is an FQDN equal to serverX.example.com. In fact there's likely no need to have anything in mydestination other than your domain name. -- Stan
Re: Is this an attack?
On 06/19/2013 02:33 PM, Birta Levente wrote: On 19/06/2013 14:37, lst_ho...@kwsoft.de wrote: Zitat von Andreas Kasenides andr...@cymail.eu: One of my mail servers (postfix 2.6) has been target of what seems to me to be an attack. The attacker tried to deliver messages to a non-existent user names formed as a long hex string. It only happened once from one particular client and kept going for some time. SMTP sessions were coming in one every second with three delivery attampts each. Here is a fragment of one single session: Out: 220 prot..eu ESMTP Postfix In: EHLO xx Out: 250-prot..eu Out: 250-PIPELINING Out: 250-SIZE 1024 Out: 250-VRFY You really don't want to enable VRFY on a public mailserver; it only enables more spammers to abuse you. Set 'disable_vrfy_command = yes' in main.cf to globally disable it. Out: 250-ETRN Out: 250-ENHANCEDSTATUSCODES Out: 250-8BITMIME Out: 250 DSN In: MAIL FROM:x...@xx.xxx.xx SIZE=2881 BODY=7BIT Out: 250 2.1.0 Ok In: RCPT TO:35150aa4c74ba30f04ede17ca25f1...@.yy Out: 451 4.3.0 35150aa4c74ba30f04ede17ca25f1...@.yy: Temporary lookup failure This means postfix attempted to verify if the recipient is valid, but failed to do so. Something is broken in your setup; either you have a broken non-hashed map, or you're misaddressing a networked service like LDAP or SQL. If *you* never come across this error normally, this is probably a later entry, for fallback, which you never reach with valid recipients. As instructed when you joined this list, provide non-verbose logs of one message, and the output of postconf -n. All of this should be rejected by 5xx, am I wrong? By default, yes - IF postfix ever got that far. This is either a name lookup failure (indicating a problem with DNS), or a map failure, indicating one of the above. And I think this temporary lookup failure is not ok Show some log... Yes he should... -- J...
Re: Local UNIX accounts, aliasing rejecting mail to non-public UNIX accounts
On 06/19/2013 05:55 PM, Stan Hoeppner wrote: On 6/19/2013 10:16 AM, Wietse Venema wrote: Craig R. Skinner: On 2013-06-19 Wed 06:51 AM |, Stan Hoeppner wrote: On 6/19/2013 6:11 AM, Craig R. Skinner wrote: What happens when you try mydestination = That's something I didn't think of trying. Either blank, or with localhost: status=bounced (User unknown in virtual alias table) This suggests that you had the domain name listed in both mydestination and in virtual_alias_domains. Now you also need to remove the domain name from virtual_alias_domains, in order to make that error go away. Until now Postfix will have logged numerous warnings with do not list domain X in both mydestination and virtual_alias_maps to remind you of a configuration error. Maybe it should just abort deliveries, that might get people's attention. Wietse I'm anything but an expert in this particular area of Postfix, but I think the problem is that Craig is trying to use virtual_alias_maps when he should probably just be using the local aliases file. His Postfix hosts a single mail domain IIUC. He's simply wanting to create alias addresses presented to the public for each local UNIX mailbox address. Additionally he wants to reject any inbound mail destined for the actual local UNIX addresses, as well as system/role accounts. These last two are straightforward. Indeed they are: mydestination = localhost virtual_alias_domains = $his_mx_domain(s) And map every valid recipient to user@localhost. -- J.
Re: Is this an attack?
On 2013-06-19 Jeroen Geilman wrote: Zitat von Andreas Kasenides andr...@cymail.eu: Out: 250-VRFY You really don't want to enable VRFY on a public mailserver; it only enables more spammers to abuse you. Set 'disable_vrfy_command = yes' in main.cf to globally disable it. Not really. Aside the fact that there are other ways to verify an address, I get a single VRFY every other month on my mail server. In my experience most spammers don't actually care if an address is valid or not and blindly throw their crap at everything that looks at least remotely like a mail address. Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
Re: Is this an attack?
Ansgar Wiechers: On 2013-06-19 Jeroen Geilman wrote: Zitat von Andreas Kasenides andr...@cymail.eu: Out: 250-VRFY You really don't want to enable VRFY on a public mailserver; it only enables more spammers to abuse you. Set 'disable_vrfy_command = yes' in main.cf to globally disable it. Not really. Aside the fact that there are other ways to verify an address, I get a single VRFY every other month on my mail server. In my experience most spammers don't actually care if an address is valid or not and blindly throw their crap at everything that looks at least remotely like a mail address. I agree. Technically, VRFY is implemented as RCPT TO without all the baggage of a mail transaction. The difference is that smtpd_client_recipient_rate_limit does not apply to VRFY, but that is easily fixed (I just copied some code from the RCPT TO handler). Wietse
Re: Is this an attack?
On 06/19/2013 07:32 PM, Wietse Venema wrote: Ansgar Wiechers: On 2013-06-19 Jeroen Geilman wrote: Zitat von Andreas Kasenides andr...@cymail.eu: Out: 250-VRFY You really don't want to enable VRFY on a public mailserver; it only enables more spammers to abuse you. Set 'disable_vrfy_command = yes' in main.cf to globally disable it. Not really. Aside the fact that there are other ways to verify an address, I get a single VRFY every other month on my mail server. In my experience most spammers don't actually care if an address is valid or not and blindly throw their crap at everything that looks at least remotely like a mail address. I agree. Technically, VRFY is implemented as RCPT TO without all the baggage of a mail transaction. The difference is that smtpd_client_recipient_rate_limit does not apply to VRFY, but that is easily fixed (I just copied some code from the RCPT TO handler). Wietse I seem to remember that allowing VRFY meant spammers could brute-force valid recipients; perhaps this was long ago and it is no longer true. -- J.
Re: Local UNIX accounts, aliasing rejecting mail to non-public UNIX accounts
On 2013-06-19 Wed 10:55 AM |, Stan Hoeppner wrote:
I'm anything but an expert in this particular area of Postfix, but I
think the problem is that Craig is trying to use virtual_alias_maps when
he should probably just be using the local aliases file. His Postfix
hosts a single mail domain IIUC.
To start with at least.
He's simply wanting to create alias
addresses presented to the public for each local UNIX mailbox address.
Correct.
Additionally he wants to reject any inbound mail destined for the actual
local UNIX addresses, as well as system/role accounts.
Correct again.
These last two are straightforward. For the first:
/etc/postfix/reject-local-system
jb4...@example.comreject Unknown User
jb8...@example.comreject Unknown User
s...@example.com reject Unknown User
na...@example.com reject Unknown User
dove...@example.com reject Unknown User
sq...@example.com reject Unknown User
post...@example.com reject Unknown User
and use
smtpd_recipient_restrictions
...
check_recipient_access hash:/etc/postfix/reject-local-system
...
$ for account in $(cut -d: -f1 /etc/passwd | grep -v master$); \
do \
print ${account}@example.com reject Unknown User \
/etc/postfix/reject-local-system.map; \
done
$ postmap
$ postmap -q s...@example.com reject-local-system.map
reject Unknown User
main.cf:
smtpd_recipient_restrictions =
reject_non_fqdn_hostname
reject_invalid_hostname
reject_non_fqdn_sender
...
...
check_recipient_access btree:$config_directory/reject-local-system.map
...
..
To satisfy the second:
jb4...@server1.example.com -- reject as unknown
jb8...@server2.example.com -- reject as unknown
Simply do not put $myhostname, localhost.$mydomain in mydestination,
assuming $myhostname is an FQDN equal to serverX.example.com. In fact
there's likely no need to have anything in mydestination other than your
domain name.
main.cf:
mydestination = $mydomain
# no virtual_alias_* stuff
restart postfix and then system accounts are still getting mail;-
$ uptime | sendmail post...@example.com
Jun 19 19:12:16 server1 postfix/pickup[2654]: 0776A6753: uid=1097 from=user1
Jun 19 19:12:16 server1 postfix/cleanup[8207]: 0776A6753:
message-id=20130619181216.0776a6...@server1.example.com
Jun 19 19:12:16 server1 postfix/qmgr[8538]: 0776A6753:
from=user.n...@example.com, size=344, nrcpt=1 (queue active)
Jun 19 19:12:16 server1 dovecot: lmtp(9851): Connect from local Jun 19 19:12:16
server1 dovecot: lmtp(9851, postfix): Error: user
_postfix: Initialization failed: Namespace '': mkdir(/var/mail/postfix) failed:
Permission denied (euid=507(postfix) egid=507(postfix) missing +w perm:
/var/mail, dir owned by 0:0 mode=0755)
Jun 19 19:12:16 server1 dovecot: lmtp(9851): Disconnect from local: Client quit
(in reset)
$ uptime | sendmail us...@example.com
Jun 19 19:12:33 server1 postfix/pickup[2654]: C90DB6765: uid=1097 from=user1
Jun 19 19:12:33 server1 postfix/cleanup[8207]: C90DB6765:
message-id=20130619181233.c90db6...@server1.example.com
Jun 19 19:12:33 server1 postfix/qmgr[8538]: C90DB6765:
from=user.n...@example.com, size=344, nrcpt=1 (queue active)
Jun 19 19:12:33 server1 dovecot: lmtp(9851): Connect from local
Jun 19 19:12:33 server1 dovecot: lmtp(9851, user1): w9hyI0r0wVF7JgAANm01jw:
sieve: msgid=20130619181233.c90db6...@server1.example.com: stored mail into
mailbox 'INBOX'
My next thought is to remove /etc/passwd from:
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
Ideas?
--
Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7
Re: Local UNIX accounts, aliasing rejecting mail to non-public UNIX accounts
On 2013-06-19 Wed 18:12 PM |, Jeroen Geilman wrote: hosts a single mail domain IIUC. He's simply wanting to create alias addresses presented to the public for each local UNIX mailbox address. Additionally he wants to reject any inbound mail destined for the actual local UNIX addresses, as well as system/role accounts. These last two are straightforward. Indeed they are: mydestination = localhost virtual_alias_domains = $his_mx_domain(s) And map every valid recipient to user@localhost. Looks simple enough, but no joy with: virtual_alias_maps.map: user.n...@example.com user1@localhost status=bounced (mail for localhost.example.com loops back to myself) And without the @localhost: user.n...@example.com user1 status=bounced (User unknown in virtual alias table) I've got this set, which I don't think would cause the above loop: myorigin = $mydomain Thanks, -- Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7
Re: Is this an attack?
On 6/19/2013 12:56 PM, Jeroen Geilman wrote: On 06/19/2013 07:32 PM, Wietse Venema wrote: Ansgar Wiechers: On 2013-06-19 Jeroen Geilman wrote: Zitat von Andreas Kasenides andr...@cymail.eu: Out: 250-VRFY You really don't want to enable VRFY on a public mailserver; it only enables more spammers to abuse you. Set 'disable_vrfy_command = yes' in main.cf to globally disable it. Not really. Aside the fact that there are other ways to verify an address, I get a single VRFY every other month on my mail server. In my experience most spammers don't actually care if an address is valid or not and blindly throw their crap at everything that looks at least remotely like a mail address. I agree. Technically, VRFY is implemented as RCPT TO without all the baggage of a mail transaction. The difference is that smtpd_client_recipient_rate_limit does not apply to VRFY, but that is easily fixed (I just copied some code from the RCPT TO handler). Wietse I seem to remember that allowing VRFY meant spammers could brute-force valid recipients; perhaps this was long ago and it is no longer true. In the old days, spammers used VRFY dictionary attacks to collect valid addresses. Then admins started disabling VRFY and spammers switched to using RCTP TO, which gives them the same information. My impression is that spammers now collect addresses other ways -- web harvesting, viruses that steal address books -- and classic dictionary attacks are seldom used anymore (with email). There is no longer any particular reason to disable VRFY, nor any particular reason not to. Disabling it doesn't protect you from anything, leaving it on doesn't add anything particularly useful. -- Noel Jones
Re: Postfix Content Filter
Prasad R: I checked in to the SendMail Milter APIs but postfix documentation said, its only used in Before Queue Content Filter and doesn't have access to the full content of the email. And I didn't find the SendMail Milter API Your reading is incorrect. The Milter has access to the full content when it is NOT used before an smtpd_proxy_filter. Wietse
Re: Postfix Content Filter
Thank you Wietse. This is the link I was reading: http://www.postfix.org/MILTER_README.html and forth bullet from the bottom of the page. How can I configure the milter to get access to full content and use it after smtpd_proxy_filter? Any pointers on the documentation? On Wed, Jun 19, 2013 at 5:41 PM, Wietse Venema wie...@porcupine.org wrote: Prasad R: I checked in to the SendMail Milter APIs but postfix documentation said, its only used in Before Queue Content Filter and doesn't have access to the full content of the email. And I didn't find the SendMail Milter API Your reading is incorrect. The Milter has access to the full content when it is NOT used before an smtpd_proxy_filter. Wietse
Re: Postfix Content Filter
Prasad R: Thank you Wietse. This is the link I was reading: http://www.postfix.org/MILTER_README.html and forth bullet from the bottom of the page. How can I configure the milter to get access to full content and use it after smtpd_proxy_filter? Any pointers on the documentation? Documentation: man 5 master man 8 smtpd Example: /etc/postfix/master.cf # Before the smtpd-proxy-filter smtp... ... ... ... smtpd -o smtpd_proxy_filter=xxx # After the smtpd-proxy-filter 127.0.0.1:10025 ... ... ... ... smtpd -o smtpd_milters=yyy Wietse
RE: Postfix Content Filter
Thank you Wieste. Sorry for the repetition but the python or the Java version of the jitler a good option? My use case is very basic so Java is much preferred for milter development if jitler framework work with the postfix. Anyone tried Java version of the milter to get full email content with postfox? -Original Message- From: Wietse Venema wie...@porcupine.org Sent: 6/19/2013 6:03 PM To: Postfix users postfix-users@postfix.org Subject: Re: Postfix Content Filter Prasad R: Thank you Wietse. This is the link I was reading: http://www.postfix.org/MILTER_README.html and forth bullet from the bottom of the page. How can I configure the milter to get access to full content and use it after smtpd_proxy_filter? Any pointers on the documentation? Documentation: man 5 master man 8 smtpd Example: /etc/postfix/master.cf # Before the smtpd-proxy-filter smtp... ... ... ... smtpd -o smtpd_proxy_filter=xxx # After the smtpd-proxy-filter 127.0.0.1:10025 ... ... ... ... smtpd -o smtpd_milters=yyy Wietse
Re: Postfix Content Filter
Venkat R: Thank you Wieste. Sorry for the repetition but the python or the Java vers -ion of the jitler a good option? My use case is very basic so Java is much p -referred for milter development if jitler framework work with the postfix. I wrote Postfix, and don't use every milter in the universe. Wietse
