virtual MAILBOX: separate domains, non-UNIX accounts

[Mike]

Noip.com manages DNS for my FQDN.
Should virtual_mailbox_domains = mail.example.com
or only example.com

Thanks for your help.

Re: virtual MAILBOX: separate domains, non-UNIX accounts

[Mike]

On Tue, Aug 24, 2010 at 6:17 AM, Magnus Bäck  wrote:

> On Monday, August 23, 2010 at 23:20 CEST,
>  Mike <1100...@gmail.com> wrote:
>
> > Noip.com manages DNS for my FQDN.
> > Should virtual_mailbox_domains = mail.example.com
> > or only example.com
>
> That depends on whether you want u...@mail.example.com to work
> or not. virtual_mailbox_domains should list recipient address
> domains, not MX hostnames or similar. Presumably you're only
> interested in getting email for u...@example.com, in which case
> you should only list example.com.
>
>
Correct assumption.
Thanks for your time and help.
Mike

Multiple Domains; No Local Accounts - bad uid in virtual_uid_maps

[Mike]

Incoming mail is getting dropped into /var/spool/postfix/defer .
I'm seeing this error in /var/log/messages:

Aug 24 17:21:48 sato postfix/virtual[581]: warning: recipient
m...@example.com: bad uid example.com/mike/   3001   3001 in
virtual_uid_maps
Aug 24 17:21:48 sato postfix/virtual[581]: 75F57163942: to=,
relay=virtual, delay=0.21, delays=0.12/0.04/0/0.05, dsn=4.3.5,
status=deferred (mail system configuration error)


postconf -n shows the following:

command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
home_mailbox = Maildir/
html_directory = /usr/share/doc/postfix-2.6.7/html
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.6.7/readme
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
unknown_local_recipient_reject_code = 550
virtual_gid_maps = hash:/etc/postfix/virtual_gid_map
virtual_mailbox_base = /var/spool/vmailboxes
virtual_mailbox_domains = example.com
virtual_mailbox_maps = hash:/etc/postfix/vmailbox_recipients
virtual_uid_maps = hash:/etc/postfix/virtual_uid_map

- - -

My /etc/postfix/virtual_uid_map file contains the following:

m...@example.com   example.com/mike/   3001   3001

I do not see what the configuration error is.
The mailbox base --- /var/spool/vmailboxes permissions are:
drwxr-xr-x  3 vuser vuser 4096 Aug 24 13:47 vmailboxes

Then /var/spool/vmailboxes/example.com/mike permissions are:
drwx-- 3 example.com example.com 4096 Aug 24 17:10 example.com

vuser is uid/gid 3000
example.com is uid/gid 3001

Re: Multiple Domains; No Local Accounts - bad uid in virtual_uid_maps

[Mike]

Thank you, gentlemen.
I always appreciate a good "RTFM" from talented folks who actually know
where they are pointing.  :-)
I do appreciate the help and definitely do not intend to aggravate and vex.

Mike

virtual mailbox: separate domains, non-unix accounts

[Mike]

Trying to complete initial setup of postfix.

My box is on a dynamic ip internet connection.
I have a FQDN and DNS forwarding service through no-ip.com.
I am starting with this one domain, and one virtual user.
Thus far, postfix is not receiving mail and when I try send email by
testing with "telnet localhost 25", I receive a "connected" message
but cannot complete transmission of message to an external email
address.

The postfix version is 2.6.1 on Slackware 13.1.

postconf -n:
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
html_directory = /usr/doc/postfix-2.6.1/html
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/man
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/doc/postfix-2.6.1/README_FILES
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
unknown_local_recipient_reject_code = 550
virtual_gid_maps = static:2000
virtual_mailbox_base = /var/spool/vmailbox
virtual_mailbox_domains = example.com
virtual_mailbox_maps = hash:/etc/postfix/vmaps
virtual_minimum_uid = 100
virtual_uid_maps = static:2000


tcpdump -i eth0 port 25 (demonstrating incoming mail from a gmail
account to the postfix box on eth0 -- provided "zeros" to the ip
address for security):

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
18:05:16.000223 IP mail-iy0-f180.google.com.60882 >
c-71-000-000-249.hsd1.ct.comcast.net.smtp: Flags [S], seq 2243640472,
win 5720, options [mss 1430,sackOK,TS val 748956439 ecr 0,nop,wscale
6], length 0
18:05:16.000328 IP c-71-000-000-249.hsd1.ct.comcast.net.smtp >
mail-iy0-f180.google.com.60882: Flags [S.], seq 2891381781, ack
2243640473, win 2096, options [mss 536,sackOK,TS val 2828404683 ecr
748956439,nop,wscale 6], length 0
18:05:16.073426 IP mail-iy0-f180.google.com.60882 >
c-71-000-000-249.hsd1.ct.comcast.net.smtp: Flags [.], ack 1, win 90,
options [nop,nop,TS val 748956511 ecr 2828404683], length 0
18:05:40.264808 IP mail-iw0-f180.google.com.46911 >
c-71-000-000-249.hsd1.ct.comcast.net.smtp: Flags [.], ack 443680673,
win 90, options [nop,nop,TS val 624960568 ecr 2828368878], length 0
18:05:40.264891 IP c-71-000-000-249.hsd1.ct.comcast.net.smtp >
mail-iw0-f180.google.com.46911: Flags [.], ack 1, win 33, options
[nop,nop,TS val 2828428947 ecr 624780432], length 0
18:06:01.621471 IP mail-iy0-f180.google.com.50022 >
c-71-000-000-249.hsd1.ct.comcast.net.smtp: Flags [.], ack 1716017503,
win 90, options [nop,nop,TS val 749002060 ecr 2828390236], length 0
18:06:01.621552 IP c-71-000-000-249.hsd1.ct.comcast.net.smtp >
mail-iy0-f180.google.com.50022: Flags [.], ack 1, win 33, options
[nop,nop,TS val 2828450304 ecr 748881991], length 0
18:06:16.086920 IP mail-iy0-f180.google.com.60882 >
c-71-000-000-249.hsd1.ct.comcast.net.smtp: Flags [.], ack 1, win 90,
options [nop,nop,TS val 749016525 ecr 2828404683], length 0
18:06:16.087011 IP c-71-000-000-249.hsd1.ct.comcast.net.smtp >
mail-iy0-f180.google.com.60882: Flags [.], ack 1, win 33, options
[nop,nop,TS val 2828464770 ecr 748956511], length 0
18:06:40.335045 IP mail-iw0-f180.google.com.46911 >
c-71-000-000-249.hsd1.ct.comcast.net.smtp: Flags [.], ack 1, win 90,
options [nop,nop,TS val 625020638 ecr 2828428947], length 0
18:06:40.335125 IP c-71-000-000-249.hsd1.ct.comcast.net.smtp >
mail-iw0-f180.google.com.46911: Flags [.], ack 1, win 33, options
[nop,nop,TS val 2828489018 ecr 624780432], length 0

And here's the /var/log/maillog on the slackware/postfix box:

Apr 17 18:01:28 sato postfix/master[22043]: warning: process
/usr/libexec/postfix/smtpd pid 22105 exit status 1
Apr 17 18:01:28 sato postfix/master[22043]: warning:
/usr/libexec/postfix/smtpd: bad command startup -- throttling
Apr 17 18:02:28 sato postfix/smtpd[22108]: fatal: open database
/etc/aliases.db: No such file or directory
Apr 17 18:02:29 sato postfix/master[22043]: warning: process
/usr/libexec/postfix/smtpd pid 22108 exit status 1
Apr 17 18:02:29 sato postfix/master[22043]: warning:
/usr/libexec/postfix/smtpd: bad command startup -- throttling
Apr 17 18:03:29 sato postfix/smtpd[22111]: fatal: open database
/etc/aliases.db: No such file or directory
Apr 17 18:03:30 sato postfix/master[22043]: warning: process
/usr/libexec/postfix/smtpd pid 22111 exit status 1
Apr 17 18:03:30 sato postfix/master[22043]: warning:
/usr/libexec/postfix/smtpd: bad command startup -- throttling
Apr 17 18:04:30 sato postfix/smtpd[22113]: fatal: open database
/etc/aliases.db: No such file or directory
Apr 17 18:04:31 sato postfix/master[22043]: warning: process
/usr/libexec/postfix/smtpd pid 22113 exit status 1
Apr 17 18:04:31 sato postfix/master[22043]: warning:
/usr/libexec/postfix/smtpd: bad command startup -- throttling
Apr 17 18:05:31 sato postfix/smtpd[22116]: fatal: open database
/etc/aliases.db: No such file or directory
Apr 17 18:05:32 sato postfix/master[22043]: warni

Re: virtual mailbox: separate domains, non-unix accounts

[Mike]

Sahil,

Thank you for your help.
I created the virtual_alias_maps and now receive the expected response
when initiating telnet session:

~:/var/spool# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 localhost ESMTP Postfix
quit
221 2.0.0 Bye
Connection closed by foreign host.

It now appears there is a permissions problem with the maildir directories:

Apr 17 21:22:17 "host" postfix/virtual[22764]: 2C0FD184076E:
to=, relay=virtual, delay=1213,
delays=1212/0.18/0/0.14, dsn=4.2.0, status=deferred (maildir delivery
failed: create maildir file
/var/spool/vmailbox/example.com/user1/tmp/1303089737.P22764."host":
Permission denied)

I have tried chmod 0700 and 0755, but I get the same "Permission
denied" failure.
I manually created the /var/spool/example.com/user1/  directories.
I also applied directory ownership to: vmail:vmail

Re: virtual mailbox: separate domains, non-unix accounts

[Mike]

On Sun, Apr 17, 2011 at 10:01 PM, masegaloeh  wrote:
> Your problem was similiar to problem that i found in this link
> http://www.irbs.net/internet/postfix/0608/1215.html
>
> The solution is "Try turning off chroot operation in master.cf"
> http://www.postfix.org/DEBUG_README.html#no_chroot
> --
> Zagalo Nanda M
>

Hi Zagalo,
Thank you too for your kind help.
I found the link too, but when I check my master.cf it shows chroot is
set to "n":

# ==
# service type  private unpriv  chroot  wakeup  maxproc command + args
#   (yes)   (yes)   (yes)   (never) (100)
# ==
smtp inetn-   n   -
-  smtpd

Re: virtual mailbox: separate domains, non-unix accounts

[Mike]

On Sun, Apr 17, 2011 at 11:00 PM, masegaloeh  wrote:
> On 4/18/2011 8:28 AM, Mike wrote:
>>
>> I manually created the /var/spool/example.com/user1/  directories.
>> I also applied directory ownership to: vmail:vmail
>
> why you create directory in /var/spool/example.com but your mailbox_base is
> /var/spool/vmailbox/example.com ???

Yes, my typing mistake, I saw it after I hit send.
The directory is:  /var/spool/vmailbox/example.com/user1/

>
> Oh, can you post the output of command "id vmail" and "ls -la
> /var/spool/vmailbox/"?

# id vmail
uid=2000(vmail) gid=2000(vmail) groups=2000(vmail)

~# ls -la /var/spool/vmailbox
total 12
drwxr-xr-x  3 1001 vmail 4096 2011-04-17 12:19 ./
drwxr-xr-x 17 root root  4096 2011-04-17 12:03 ../
drwxr-xr-x  3 1001 vmail 4096 2011-04-17 13:39 example.com/

Aha! 
How did this happen? UID 1001 is user: Postdrop ?
I did not set it this way.
I put everything ~#chown -R vmail:vmail

I will change it now and test an email...

Re: virtual mailbox: separate domains, non-unix accounts

[Mike]

On Sun, Apr 17, 2011 at 11:57 PM, Mike <1100...@gmail.com> wrote:
> ~# ls -la /var/spool/vmailbox
> total 12
> drwxr-xr-x  3 1001 vmail 4096 2011-04-17 12:19 ./
> drwxr-xr-x 17 root root  4096 2011-04-17 12:03 ../
> drwxr-xr-x  3 1001 vmail 4096 2011-04-17 13:39 example.com/
>

chown'ed everything to uid/gid 2000 and now, Success. :)

Apr 17 23:57:54 host postfix/smtpd[23124]: connect from
mail-iy0-f180.google.com[209.85.210.180]
Apr 17 23:57:54 host postfix/smtpd[23124]: 8C1481840783:
client=mail-iy0-f180.google.com[209.85.210.180]
Apr 17 23:57:54 host postfix/cleanup[23128]: 8C1481840783:
message-id=
Apr 17 23:57:54 host postfix/qmgr[23120]: 8C1481840783:
from=, size=1654, nrcpt=1 (queue active)
Apr 17 23:57:54 host postfix/virtual[23123]: 8C1481840783:
to=, relay=virtual, delay=0.37,
delays=0.32/0/0/0.05, dsn=2.0.0, status=sent (delivered to maildir)
Apr 17 23:57:54 sato postfix/qmgr[23120]: 8C1481840783: removed

Thank you so very much for your help.

Postfix w/TLS, virtual domain, non-unix account

[Mike]

I've got postfix working with TLS in a virtual domain configuration.
The postfix server is accepting mail with no problems; per log:

Apr 26 06:05:23 sato postfix/smtpd[26962]: connect from
mail-iy0-f180.google.com[209.85.210.180]
Apr 26 06:05:23 sato postfix/smtpd[26962]: setting up TLS connection
from mail-iy0-f180.google.com[209.85.210.180]
Apr 26 06:05:23 sato postfix/smtpd[26962]:
mail-iy0-f180.google.com[209.85.210.180]: TLS cipher list
"ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH:!aNULL:!MD5"
Apr 26 06:05:23 sato postfix/smtpd[26962]: SSL_accept:before/accept
initialization
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 read client hello A
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 write server hello A
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 write certificate A
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 write server done A
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 flush data
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 read
client key exchange A
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 read finished A
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 write
change cipher spec A
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 write finished A
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 flush data
Apr 26 06:05:24 sato postfix/smtpd[26962]:
mail-iy0-f180.google.com[209.85.210.180]: save session
E5A2DA12F11C1EA1AB910C8F09FB58861FF2A0=smtp to smtpd cache
Apr 26 06:05:24 sato postfix/tlsmgr[26964]: put smtpd session
id=E5A2DA12F11C1EA1AB910C8F09FB58861FF2A0=smtp [data 127 bytes]
Apr 26 06:05:24 sato postfix/tlsmgr[26964]: write smtpd TLS cache
entry E5A2DA12F11C1EA1AB910C8F09FB58861FF2A0=smtp: time=1303812324
[data 127 bytes]
Apr 26 06:05:24 sato postfix/smtpd[26962]: Anonymous TLS connection
established from mail-iy0-f180.google.com[209.85.210.180]: TLSv1 with
cipher AES128-SHA (128/128 bits)
Apr 26 06:05:24 sato postfix/smtpd[26962]: 80D101840715:
client=mail-iy0-f180.google.com[209.85.210.180]
Apr 26 06:05:24 sato postfix/cleanup[26967]: 80D101840715:
message-id=
Apr 26 06:05:24 sato postfix/qmgr[26958]: 80D101840715:
from=, size=1564, nrcpt=1 (queue active)
Apr 26 06:05:24 sato postfix/virtual[26968]: 80D101840715:
to=, relay=virtual, delay=0.36,
delays=0.28/0.04/0/0.05, dsn=2.0.0, status=sent (delivered to maildir)
Apr 26 06:05:24 sato postfix/qmgr[26958]: 80D101840715: removed
Apr 26 06:05:54 sato postfix/smtpd[26962]: disconnect from
mail-iy0-f180.google.com[209.85.210.180]
Apr 26 06:09:14 sato postfix/anvil[26965]: statistics: max connection
rate 1/60s for (smtp:209.85.210.180) at Apr 26 06:05:23
Apr 26 06:09:14 sato postfix/anvil[26965]: statistics: max connection
count 1 for (smtp:209.85.210.180) at Apr 26 06:05:23
Apr 26 06:09:14 sato postfix/anvil[26965]: statistics: max cache size
1 at Apr 26 06:05:23


I now want to connect to postfix server and try to send email.
Using Thunderbird 3.1 email client and adding u...@example.com account.
Tbird tries to auto-configure the connection to the mail server. It
appears to "find" or connect to the smtp outgoing server, but the
incoming server fails. I've tried many different settings for the
incoming server: pop, imap, ports 110,143,587,993,995; I've tried
addressing the incoming server as mail.example.com, example.com, etc.
Everything has failed thus far.

I've been reviewing the postfix TLS and basic configuration docs., but
I'm not progressing.
Looking for guidance how to properly connect an email client to the
postfix server.

postconf -n output:

command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
html_directory = /usr/doc/postfix-2.6.1/html
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/man
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/doc/postfix-2.6.1/README_FILES
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/mycert.pem
smtpd_tls_key_file = $smtpd_tls_cert_file
smtpd_tls_loglevel = 2
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5
smtpd_tls_mandatory_protocols = TLSv1
smtpd_tls_security_level = encrypt
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtpd_tls_session_cache_timeout = 7200s
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_gid_maps = static:2000
virtual_mailbox_base = /var/mail/vmailbox
virtual_mailbox_domains = example.com
virtual_mailbox_maps = hash:/etc/postfix/vmaps
virtual_minimum_uid = 100
virtual_uid_maps = static:2000

Re: Postfix w/TLS, virtual domain, non-unix account

[Mike]

On Tue, Apr 26, 2011 at 1:58 PM, Victor Duchovni
 wrote:
>
> This is all that would be logged with "smtpd_tls_loglevel = 1", and it
> is quite sufficient.

Excellent, will do and thanks for letting me know I'm now ready to
configure an imap server.

Mike

Re: high-speed postfix configuration

[Mike]

> The first thing that comes to mind is using a ramdisk for the queue 
directories.
> But I'm doubting Postfix will work with queue directories on a 
ramdisk. Wietse can answer this.


There's no reason Postfix won't work with /var/spool/postfix mounted 
from RAM. The standard filesystem(s) used for ramdisks may not work, you 
may need to pick a real file system like ext3/4, but if you have 
something you can treat as a block device there should be no technical 
issues.


Whether you *should* do something like this is an entirely different matter.

--
Looking for (employment|contract) work in the
Internet industry, preferrably working remotely.
Building / Supporting the net since 2400 baud was
the hot thing. Ask for a resume! ispbuil...@gmail.com

Re: Reverse Hostnames with '_msdcs' not valid

[Mike]

On 12-08-29 08:01 AM, Bernhard Schmidt wrote:

We suspect (and verified with an internal client with custom rDNS) 
that the _msdcs entry is at fault. This hostname does not seem to get 
accepted. As soon as I remove the '_' it works fine.




Have a read:

http://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_host_names



--
Looking for (employment|contract) work in the
Internet industry, preferrably working remotely.
Building / Supporting the net since 2400 baud was
the hot thing. Ask for a resume! ispbuil...@gmail.com

Odd postfix and firewall log entries

[Mike.]

I recently started seeing these log entries in the Postfix log and the
firewall log.  The sequence happens once a day, sometimes twice.  Each
time it appears to be a different client IP address.

In summary, I see an aborted connection attempt to Postfix, then a
short while later I see Postfix trying some outbound connections (which
are blocked and logged by the firewall).

Is this behavior familiar to anyone?  Any suggestions on where I should
start looking next for the source of the outbound attempts?

This is Postfix 2.7.1.Postfix 2.9.1 exhibits a similar behavior.
IP 216.xxx.68.64 is the Postfix server, which runs FreeBSD 8.3.



Sep 28 03:21:22 oneou postfix/smtpd[91250]: connect from
unknown[39.xxx.56.235]
Sep 28 03:26:22 oneou postfix/smtpd[91250]: timeout after CONNECT from
unknown[39.xxx.56.235]
Sep 28 03:26:22 oneou postfix/smtpd[91250]: disconnect from
unknown[39.xxx.56.235]
Sep 28 03:27:12 oneou pf: rule 1/0(match): block out on fxp0:
216.xxx.68.64.25 > 39.xxx.56.235.1525:  tcp 108 
Sep 28 03:28:16 oneou pf: rule 1/0(match): block out on fxp0:
216.xxx.68.64.25 > 39.xxx.56.235.1525:  tcp 108 
Sep 28 03:29:20 oneou pf: rule 1/0(match): block out on fxp0:
216.xxx.68.64.25 > 39.xxx.56.235.1525:  tcp 108 
Sep 28 03:30:24 oneou pf: rule 1/0(match): block out on fxp0:
216.xxx.68.64.25 > 39.xxx.56.235.1525:  tcp 108 
Sep 28 03:31:28 oneou pf: rule 1/0(match): block out on fxp0:
216.xxx.68.64.25 > 39.xxx.56.235.1525:  tcp 20 




Sep 30 11:05:57 oneou postfix/smtpd[34106]: connect from
6.sfi.patel.net[83.xxx.56.16]
Sep 30 11:05:58 oneou postfix/smtpd[34106]: lost connection after
CONNECT from 6.sfi.patel.net[83.xxx.56.16]
Sep 30 11:05:58 oneou postfix/smtpd[34106]: disconnect from
6.sfi.patel.net[83.xxx.56.16]
Sep 30 11:08:07 oneou pf: rule 1/0(match): block out on fxp0:
216.xxx.68.64.25 > 83.xxx.56.16.17725:  tcp 20 
Sep 30 11:09:10 oneou pf: rule 1/0(match): block out on fxp0:
216.xxx.68.64.25 > 83.xxx.56.16.17725:  tcp 20 
Sep 30 11:10:14 oneou pf: rule 1/0(match): block out on fxp0:
216.xxx.68.64.25 > 83.xxx.56.16.17725:  tcp 20 
Sep 30 11:11:18 oneou pf: rule 1/0(match): block out on fxp0:
216.xxx.68.64.25 > 83.xxx.56.16.17725:  tcp 20 
Sep 30 11:12:22 oneou pf: rule 1/0(match): block out on fxp0:
216.xxx.68.64.25 > 83.xxx.56.16.17725:  tcp 20 
Sep 30 11:13:26 oneou pf: rule 1/0(match): block out on fxp0:
216.xxx.68.64.25 > 83.xxx.56.16.17725:  tcp 20 
Sep 30 11:14:30 oneou pf: rule 1/0(match): block out on fxp0:
216.xxx.68.64.25 > 83.xxx.56.16.17725:  tcp 20 
Sep 30 11:15:34 oneou pf: rule 1/0(match): block out on fxp0:
216.xxx.68.64.25 > 83.xxx.56.16.17725:  tcp 20 

Re: Odd postfix and firewall log entries

[Mike.]

On 10/1/2012 at 3:35 PM Viktor Dukhovni wrote:

|On Mon, Oct 01, 2012 at 11:05:59AM -0400, Mike. wrote:
|
|> I recently started seeing these log entries in the Postfix log and
the
|> firewall log.  The sequence happens once a day, sometimes twice.
Each
|> time it appears to be a different client IP address.
|> 
|> In summary, I see an aborted connection attempt to Postfix, then a
|> short while later I see Postfix trying some outbound connections
(which
|> are blocked and logged by the firewall).
|
|They are not outbound connections. These are most likely
re-transmissions
|of the Postfix 220 banner, which was never acked by the connecting
client.
|
|The firewall tears down the connection before the TCP stack stops
|retrying.
|
|> Sep 28 03:21:22 oneou postfix/smtpd[91250]: connect from
|> unknown[39.xxx.56.235]
|> Sep 28 03:26:22 oneou postfix/smtpd[91250]: timeout after CONNECT
from
|> unknown[39.xxx.56.235]
|> Sep 28 03:26:22 oneou postfix/smtpd[91250]: disconnect from
|> unknown[39.xxx.56.235]
|> Sep 28 03:27:12 oneou pf: rule 1/0(match): block out on fxp0:
|> 216.xxx.68.64.25 > 39.xxx.56.235.1525:  tcp 108 
|> Sep 28 03:28:16 oneou pf: rule 1/0(match): block out on fxp0:
|> 216.xxx.68.64.25 > 39.xxx.56.235.1525:  tcp 108 
|> Sep 28 03:29:20 oneou pf: rule 1/0(match): block out on fxp0:
|> 216.xxx.68.64.25 > 39.xxx.56.235.1525:  tcp 108 
|> Sep 28 03:30:24 oneou pf: rule 1/0(match): block out on fxp0:
|> 216.xxx.68.64.25 > 39.xxx.56.235.1525:  tcp 108 
|> Sep 28 03:31:28 oneou pf: rule 1/0(match): block out on fxp0:
|> 216.xxx.68.64.25 > 39.xxx.56.235.1525:  tcp 20 
|
|-- 
|   Viktor.

 =

Thanks very much for the quick answer.  That makes sense.


btw, regarding my comment that "I recently started seeing these log
entries" :

I recently added a IPv6 tunnel to the server and I adjusted the
firewall rules.  One of the things I changed was the firewall now logs
all blocked outbound connections.  So this curiosity may have been
occurring previously, I just did not see the firewall blocks because
they were not logged.

So all the symptoms fall into place now.

Thanks again.

Mike.

Postscreen status script

[Mike.]

I implemented the postscreen capability on a small MTA I run for
friends and family.  Once I got postscreen configuration producing the
results I wanted, I soon tired of watching the detailed maillog to see
how postscreen was operating.  So I wrote a quick shell script to
summarize the log file and give me an overview of how well postscreen
is working.

I offer the script to anyone who would like to use it.   One company I
worked for would not allow open source software into the company unless
there was an explicit license on the software, so I put the BSD license
on the script.  

You can download the script from here:
 http://archive.mgm51.com/sources/pslogscan.html


Here is the sample output that pslogscan.sh produces:

Scanning /var/log/maillog

 All "incoming" log records:   5789
   All "status=sent"  log records: 1873
   All "status=deferred"  log records: 10
 rejected: 3906  (67%)
   
   PASS NEW log records:  390
   PASS OLD log records:  1762
   
   WHITELISTED log records:  109
   BLACKLISTED log records:  0
   
   Protocol errors:
  HANGUP log records:  2980
PREGREET log records:  187
BARE NEWLINE log records:  1
  COMMAND TIME LIMIT log records:  8
  COMMAND PIPELINING log records:  1
   
   DNS black lists log records:
zen.spamhaus.org:  3174
 dnsbl.sorbs.net:  1338
  b.barracudacentral.org:  2759
   
   DNSBL blocked log records: 2410
  DNSBL rank 3:  493
  DNSBL rank 4:  0
  DNSBL rank 5:  0
  DNSBL rank 6:  938
  DNSBL rank 7:  0
  DNSBL rank 8:  0
  DNSBL rank 9+: 979
   
   DNSBL blocks by domain: 
  example.com: 393
  example.biz: 69
  example.net: 1699
 example.info: 108
 

Re: Postscreen status script

[Mike.]

On 1/29/2013 at 1:14 PM Brian Evans wrote:

|On 1/29/2013 1:07 PM, Mike. wrote:
|> I implemented the postscreen capability on a small MTA I run for
|> friends and family.  Once I got postscreen configuration producing
the
|> results I wanted, I soon tired of watching the detailed maillog to
see
|> how postscreen was operating.  So I wrote a quick shell script to
|> summarize the log file and give me an overview of how well
postscreen
|> is working.
|>
|> I offer the script to anyone who would like to use it.   One company
I
|> worked for would not allow open source software into the company
unless
|> there was an explicit license on the software, so I put the BSD
license
|> on the script.
|>
|> You can download the script from here:
|>   http://archive.mgm51.com/sources/pslogscan.html
|>
|Fails without modification on my Gentoo mailserver:
|Scanning /var/log/maillog
|mktemp: too few X's in template ‘mailqscan’
|
|All "incoming" log records: 10121
|./pslogscan.sh: line 51: ${TmpFile}: ambiguous redirect
|
|Changing mailqscan to mailqscan.XXX works.
|
|Brian

 =


Thanks for the feedback.

I only run FreeBSD, so I figure there may be some minor issues like the
one you mention when running on other OS's.

Re: Postscreen status script

[Mike.]

On 1/29/2013 at 1:43 PM Brian Evans wrote:

|On 1/29/2013 1:29 PM, Mike. wrote:
|>
|> On 1/29/2013 at 1:14 PM Brian Evans wrote:
|>
|> |On 1/29/2013 1:07 PM, Mike. wrote:
|> |> I implemented the postscreen capability on a small MTA I run for
|> |> friends and family.  Once I got postscreen configuration
producing
|> the
|> |> results I wanted, I soon tired of watching the detailed maillog
to
|> see
|> |> how postscreen was operating.  So I wrote a quick shell script to
|> |> summarize the log file and give me an overview of how well
|> postscreen
|> |> is working.
|> |>
|> |> I offer the script to anyone who would like to use it.   One
company
|> I
|> |> worked for would not allow open source software into the company
|> unless
|> |> there was an explicit license on the software, so I put the BSD
|> license
|> |> on the script.
|> |>
|> |> You can download the script from here:
|> |>   http://archive.mgm51.com/sources/pslogscan.html
|> |>
|> |Fails without modification on my Gentoo mailserver:
|> |Scanning /var/log/maillog
|> |mktemp: too few X's in template ‘mailqscan’
|> |
|> |All "incoming" log records: 10121
|> |./pslogscan.sh: line 51: ${TmpFile}: ambiguous redirect
|> |
|> |Changing mailqscan to mailqscan.XXX works.
|> |
|> |Brian
|>
|>   =
|>
|>
|> Thanks for the feedback.
|>
|> I only run FreeBSD, so I figure there may be some minor issues like
the
|> one you mention when running on other OS's.
|>
|>
|>
|Also, your expressions don't count real postscreen numbers for
connects
|and rejects.
|Take into account the following lines.
|
|Jan 28 12:47:57 mx1 postfix/error[19363]: 3Yvy410c1Mz8GKk:
|to=, relay=none, delay=2332,
delays=2331/1.2/0/0.07,
|dsn=4.7.0, status=deferred (delivery temporarily suspended: host
|mta7.am0.yahoodns.net[66.94.238.147] refused to talk to me: 421 4.7.0
|[TS01] Messages from xx.xx.xx.xx temporarily deferred due to user
|complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html)
|Jan 28 12:48:26 mx1 postfix/smtp[19336]: 3Yvy4D6lG7z8GL8:
|to=, relay=none, delay=2350,
|delays=2319/0.05/31/0, dsn=4.4.1, status=deferred (connect to
|yahoo.com.com[216.239.120.187]:25: Connection timed out)
|
|Because of that, I have skewed numbers:
|All "incoming" log records: 10187
|All "status=sent" log records: 7506
|All "status=deferred" log records: 3302
|rejected: -621 (-6%)
|
|It is not a simple math of "A minus B minus C" to find out how much
|postscreen is rejecting in its current state.
|
|Brian

 =

Yup.

When there are a lot of deferrals, then things get complicated,
requiring one to following individual messages through the process to
eliminate multiple deferrals, etc., e.g., a single message "incoming"
can get deferred many times leading to the numbers you cite.

I wanted to keep things simple, so I made some compromises on the
accuracy.  I've been flipping back and forth between keeping the count
of deferrals in there, or taking it out.  Perhaps I should report the
deferrals, but not count them in the expression   hmmm...

Re: Postscreen status script

[Mike.]

On 1/29/2013 at 2:01 PM Brian Evans wrote:

|On 1/29/2013 1:43 PM, Brian Evans wrote:
|> Because of that, I have skewed numbers:
|> All "incoming" log records: 10187
|> All "status=sent" log records: 7506
|> All "status=deferred" log records: 3302
|> rejected: -621 (-6%)
|>
|> It is not a simple math of "A minus B minus C" to find out how much 
|> postscreen is rejecting in its current state.
|
|Furthermore, the script assumes that connect to sent ratio is (1:1).
|This is almost never the case with multi-recipient mail or clients
that 
|can send more than one message in a single transaction.
|
|Brian

 =

Version 1.1, now uploaded to 

 http://archive.mgm51.com/sources/pslogscan.html

has removed the deferrals from the rejected calculation.


Multi-recipients handling would involve some very detailed processing,
which is beyond the stated goal of this script.  

I use the script to watch day-to-day trends, not for detailed analysis.
  In that capacity, it works fine for me.  YMMV

Thanks again for your feedback.

Re: Postscreen status script

[Mike.]

On 1/29/2013 at 2:06 PM lcon...@go2france.com wrote:

|On Tuesday 29/01/2013 at 1:37 pm, Mike.  wrote:
|>
|I suggest you simplify and use only postscreen log lines.
|
|"sent" and "deferred" are not postscreen actions.
|
|and "sent" double counts when postfix sends to content filter  AND 
|sends to next hop, in a relay-only gateway.
|
|"incoming" should be "SMTP connections"
|
|you should automatically detect RBL servers rather than looking for 
|defined, eg sorbs, RBL server, which I don't use
|
|awk '/dnsblog/{print $11}' /var/log/maillog | sort -f | uniq -ic
|290700 b.barracudacentral.org
|209424 zen.spamhaus.org
|
|
|good work
|
|
|I think I'll write my own in python  :)
|
|
|Len
 =

Yes, after pondering the helpful pointers that Brian gave me, I have
started to think about using only the Postscreen log lines, that way I
can avoid the multiplication of messages due to multi-recipient
messages and other messes, such as the double count you note.  I backed
myself into a corner when I tried to track the flow of messages without
tracking the details thereof.

I'll leave the auto-detect to those who are more adventurous in that
area than I.  :)

"incoming" currently also includes "pickup".  But that may be removed
when I go to postscreen-only log messages.


If I sparked an idea for someone else, all the better.

Thanks for the comment.

Re: Postscreen status script

[Mike.]

On 1/30/2013 at 3:55 AM Eliezer Croitoru wrote:

|On 1/29/2013 8:07 PM, Mike. wrote:
|>
|> I implemented the postscreen capability on a small MTA I run for
|> friends and family.  Once I got postscreen configuration producing
the
|> results I wanted, I soon tired of watching the detailed maillog to
see
|> how postscreen was operating.  So I wrote a quick shell script to
|> summarize the log file and give me an overview of how well
postscreen
|> is working.
|>
|> I offer the script to anyone who would like to use it.   One company
I
|> worked for would not allow open source software into the company
unless
|> there was an explicit license on the software, so I put the BSD
license
|> on the script.
|>
|> You can download the script from here:
|>   http://archive.mgm51.com/sources/pslogscan.html
|
|Thanks Mike.
|
|The concept is really good but I must say it's a script for very small

|logs but in a system that the logs are in sizes of more then 100MB I 
|assume your script will be very slow.
|
|How are you in other scripting languages?
|I have been working with Ruby\Perl\Python\Bash and for me Ruby is the 
|most intuitive and seems like capable of doing this task easily.
|
|Regards,
|--
|Eliezer

 =


I've tried it on logs up to 40MB, and it ran to completion in around
five seconds.  However, for that test, I copied the log file off the
production mail server and on to a lightly loaded box.

Postscreen status script, take two

[Mike.]

I made some changes to the script based upon the excellent feedback I
received here.  

The script no longer wanders beyond the postscreen log records in order
to gather the information needed to determine the postscreen rejection
rate.  So that removes the problems caused by multiple-recipient
messages.   

There is now the need to tell the script whether deep protocol testing
is being done.  There's an easy way to do this in the script.   The
default setting for this is the same as postscreen's default - deep
protocol testing is disabled.

Also, there is also the ability in the script to adjust the mktemp
template according to the OS being used.



You can download version 1.2 of the script from here:
 http://archive.mgm51.com/sources/pslogscan.html


Here is the sample output that pslogscan.sh produces (the 158MB file
was processed on 4 seconds):

Scanning /var/log/maillog

  CONNECT log records:  116340
  PASS NEW log records: 8190
  PASS OLD log records: 37002
  WHITELISTED log records:  2289
  BLACKLISTED log records:  0
 
  rejected: 77049  (66%)
 
 
  Protocol errors:
HANGUP log records:  62580
  PREGREET log records:  3927
  BARE NEWLINE log records:  21
COMMAND TIME LIMIT log records:  168
COMMAND PIPELINING log records:  21
 
  DNS black lists log records:
b.barracudacentral.org:  57939
   dnsbl.sorbs.net:  28098
  zen.spamhaus.org:  66654
 
  DNSBL blocked log records: 50610
DNSBL rank 3:  10353
DNSBL rank 4:  0
DNSBL rank 5:  0
DNSBL rank 6:  19698
DNSBL rank 7:  0
DNSBL rank 8:  0
DNSBL rank 9+: 20559
 
  DNSBL blocks by domain: 
   example.com: 8253
   example.net: 1449
  example.info: 35679
   example.bix: 2268
 

Re: Postscreen status script, take two

[Mike.]

On 2/2/2013 at 9:52 AM Sahil Tandon wrote:

|On Wed, 2013-01-30 at 14:23:19 -0500, Mike. wrote:
|
|> I made some changes to the script based upon the excellent feedback
I
|> received here.  
|> 
|> The script no longer wanders beyond the postscreen log records in
|> order to gather the information needed to determine the postscreen
|> rejection rate.  So that removes the problems caused by
|> multiple-recipient messages.   
|> ...
|
|Be careful with grep(1) patterns.  You overstate CONNECTs by including
|'NOQUEUE: reject: CONNECT' in the count.  Meanwhile, the script
|understates total DNSBL rejections, which you measure with:
|
|| grep -c "DNSBL rank [3-99]"
|
|That bracket expression matches on a _single_ character, and does not
|capture double-digit ranks.  A similar mistake occurs in the attempt
to
|aggregate 9+ ranks:
|
|| grep -c "DNSBL rank [9-99] "
|
|This only counts appearances of "DNSBL rank 9" in the log, as
|illustrated below:
|
|| % grep -c "DNSBL rank [9-99] " maillog
|| 4494
|
|| % grep -c "DNSBL rank 9 " maillog
|| 4494
|
|Review the re_format(7) and grep(1) manuals to improve understanding
of
|regular expressions.  In case it helps you, last year I had cobbled
|together a slower (it is Python rather than a set of grep(1)
|expressions) script[1] to collect similar statistics.  No promises
that
|it is error-free.
|
|[1] http://people.freebsd.org/~sahil/scripts/mailstats.py.txt
|
|--
|Sahil Tandon

 =


Thanks for the feedback.   

Re: Postscreen status script, take two

[Mike.]

On 2/2/2013 at 9:52 AM Sahil Tandon wrote:

|Be careful with grep(1) patterns.  You overstate CONNECTs by 
|including 'NOQUEUE: reject: CONNECT' in the count. 

I tightened up that regex to include only the CONNECT occurrences I
want.



| Meanwhile, the script 
| understates total DNSBL rejections,...
|
|A similar mistake occurs in the attempt to
|aggregate 9+ ranks:
 =

I fixed both of those.


Version 1.4 of the pslogscan.sh script, incorporating the above fixes,
is available at:
http://archive.mgm51.com/sources/pslogscan.html


Thanks again for your feedback.

Re: quiet or broken

[Mike.]

On 3/11/2013 at 8:28 PM Wietse Venema wrote:

|Either it has become very quiet here, or something has broken.
|
|   Wietse
 =

Quiet here.  I'm just sitting back and watching Postfix do its thing.

Thanks!

google outbound SMTP whitelisting

[Mike.]

I wanted to put google's outbound SMTP servers on a postscreen
whitelist, but the list seems to be dynamic.  I found this web page
that explains how to get the list of IP addresses:
http://support.google.com/a/bin/answer.py?hl=en&hlrm=de&answer=60764

So I wrote a quick script that outputs to stdout the list of CIDR
addresses in a format suitable for a postscreen whitelist.

The script is called gwhitelist.sh and is available here:
http://archive.mgm51.com/sources/gwhitelist.html




The output from the script currently is:

# gwhitelist.sh 
216.239.32.0/19   permit
64.233.160.0/19   permit
66.249.80.0/20   permit
72.14.192.0/18   permit
209.85.128.0/17   permit
66.102.0.0/20   permit
74.125.0.0/16   permit
64.18.0.0/20   permit
207.126.144.0/20   permit
173.194.0.0/16   permit
2001:4860:4000::/36   permit
2404:6800:4000::/36   permit
2607:f8b0:4000::/36   permit
2800:3f0:4000::/36   permit
2a00:1450:4000::/36   permit
2c0f:fb50:4000::/36   permit




I tested the script under OpenBSD 5.3, FreeBSD 9.1, and Debian
GNU/Linux 6.0.6.   

Comments are welcome.

Re: google outbound SMTP whitelisting

[Mike.]

On 5/20/2013 at 3:14 PM Benny Pedersen wrote:

|Mike. skrev den 2013-05-19 21:08:
|
|> Comments are welcome.
|
|wishfull thinking here: make postscreen postfix policy compatible
 =

That's beyond the scope of the project.  :)


More seriously, if I were to integrate it more closely with postscreen,
I would want to seriously beef up the error checking within the script.
  I purposely left it to the individual mail admin to decide how, and
to what extent, to fit gwhitelist.sh into the mail system.

Re: performance of postfix

[Mike]

On 13-05-22 07:53 AM, Selcuk Yazar wrote:

Hi,

we have Postfix with LDAP backend , everything is working good but i 
think we have some performance issues , but i can't sure :/  ( Our 
mailbox folders are located Storage Drive  mapped at Redhat Enterprise)




Have you looked at your logs to determine where and if your perceived 
delays are taking place?




--
Looking for (employment|contract) work in the
Internet industry, preferably working remotely.
Building / Supporting the net since 2400 baud was
the hot thing. Ask for a resume! ispbuil...@gmail.com

Re: Is it time for 2.x.y -> x.y?

[Mike.]

On 5/31/2013 at 4:56 PM wie...@porcupine.org wrote:

|After the confusion that Postfix 2.10 is not Postfix 2.1, 
 =


In 20/20 hindsight, perhaps Postfix 2.1 should have been Postfix 2.01,
allowing 100 minor versions before the major version was forced to
change.  

I have a similar problem on my TV.  The Cable Company give me channels
12.1 and 12.100, when they really mean 12.001 and 12.100.


Going forward, I would prefer a major.minor.patch type of numbering
sequence, with leading zeros as appropriate in the minor and patch
numbers.

I will also state that regardless of the numbering paradigm you decide
upon, I will continue to use and learn from the Postfix software and
community.

Thanks!

Re: Is it time for 2.x.y -> x.y?

[Mike.]

On 5/31/2013 at 10:23 PM Jim Wright wrote:

|On May 31, 2013, at 3:56 PM, wie...@porcupine.org (Wietse Venema)
wrote:
|
|> After the confusion that Postfix 2.10 is not Postfix 2.1, maybe it
is
|time to change the release numbering scheme.
|
|If they can't figure it out, they shouldn't be running a mail server. 
|There is nothing wrong with the version numbering.
 =

I cannot disagree with the former.

The latter, however, maybe there is an area for improvement with the
current numbering sequence.  Discussion on the topic is, imo, good.

Re: monitoring with Icinga?

[Mike]

On 13-06-02 12:34 PM, Lars Nielsen wrote:


My primary use is to recieve emails for my domains. Next I want to relay
general emails for a limited amount of authenticated users.



Ok, so with step one, you're going to want to have another system send 
email to a mailbox you host once every 'n' minutes, clear that mailbox 
out once every-so-often, and alarm if the mailbox remains untouched for 
more than '2n' minutes.


That way if mail is not getting delivered, you get alarms.

--
Looking for (employment|contract) work in the
Internet industry, preferably working remotely.
Building / Supporting the net since 2400 baud was
the hot thing. Ask for a resume! ispbuil...@gmail.com

Re: Monitoring

[Mike]

On 13-07-17 09:14 AM, Roman Gelfand wrote:
> Is there open source web based postfix server monitoring software?
>
> I am looking to see if there is something to monitor queue size, etc...
>
> Thanks in advance

Nagios has a "check_mailq" plugin that works very well with Postfix.


-- 
Looking for (employment|contract) work in the
Internet industry, preferably working remotely. 
Building / Supporting the net since 2400 baud was
the hot thing. Ask for a resume! ispbuil...@gmail.com

Re: ..:: Keep HTML format ::.. (solved)

[Mike.]

On 9/4/2013 at 11:32 AM Alfonso Alejandro Reyes Jiménez wrote:

|On 9/4/13 11:08 AM, Alfonso Alejandro Reyes Jiménez wrote:
|>> Alfonso Alejandro Reyes Jiménez wrote:
|>>> Thanks for the response, the thing is that if you send an email on
the
|>>> same exchange everything looks fine, if you send an email thru the
|>>> postfixs distribution list which sends to another exchange all the
|>>> format is removed. If you send postfix to exchange works fine, may

|>>> be is
|>>> something about the mailing list.
|>> Mailing lists are sometimes explicitly configured to strip images
and
|>> HTML formatting, passing only the plaintext part.
|>>
|>> Ask the admin of the specific machine you're seeing this happen
with.
|>>
|>> -kgd
|> Thanks but the mailing list is on the postfix, the postfix is
striping
|> the images according to our tests. :(
|Now it works, thanks!!
 =


Configuration management issues?

Re: Postfix Repos

[Mike]

I asked this under a thread but am asking again in its own thread to see
if I get better visibility.

Does anyone know of any good bleeding edge postfix repos?

I am using whatever the CentOS distros come with and it appears to be an
older version.

I¹d like to look into some of the newer features available like postscreen
in place of postgrey.


Faced with the same issue we did not find a suitable repo so started 
looking into building postfix ourselves.  There are (at least) two ways to 
go, simply build from source and install -or- build an RPM. My preference 
is building an RPM.  It's really not that difficult and gives you (at 
least perceived) more control of what you're installing.


Here are two good links that I've been using as references.

http://stevejenkins.com/blog/2011/01/building-postfix-2-8-on-rhel5-centos-5-from-source/
http://www.slackinfo.net/articles/build-and-install-postfix-2-9-4.html

Note that the first references Centos 5 but the process works on C6 too.

Re: Postfix doubling up as SMTP load balancer

[Mike]

In $PREVIOUSJOB, we had a number of internet facing SMTP machines, which
looked up accounts/mailboxes/transport maps etc from MySQL; all changes
were done on a master database on a separate machine, and synced out
with MySQL replication to all of the SMTP machines. This way we could
take any single machine offline, be it an SMTP server or the master
database, and nothing would break.

Load balancing was done by a pair of atom-based machines running Linux
and Keepalived. I'm not sure the Atoms would have scaled well past 100M
of traffic, but if you have more than 100M of SMTP traffic coming in you
can likely put in whatever you like for load balancers.

The whole setup worked extremely well, almost to the point where it was
boring. Just as it should be.



On 14-02-07 01:10 PM, Len Conrad wrote:
>> I  have an email receiving setup with one Postfix instance mapped to one 
>> instance of Amavisd-new (spamassassin, ClamAV),
>>
>> Now to prepare for increasing traffic, I am looking on to scale out 
>> strategies of my setup.
>>
>> So with that in mind, is it possible that one instance of Postfix can itself 
>> distribute email load on two or more  Amavisd-new instances spread over 
>> different locations over the network
>> ?
>>
>> In essence can postfix work as an SMTP load balancer ?
> not load balancer, but (dumb) load distributor via DNS round-robin.
>
> My envelope-only-filter mx1 relays to cs.mydomain.net, a domain record set 
> which has 3 IPs, one for each of our content-scanner boxes.
>
> I shown several times that DNS round-robin on an internal network like above 
> sends splits the load to target IP +/- 2%. 
>
> For intelligent load balancing, you could have a looping script that 
> SMTP-connects to each IP in the target record set every minute, to remove a 
> slow-responding IP from the record set with nsupdate, or to add an IP that 
> returns to quick SMTP responding.   
>
> Above, cs.mydomain.net would have to be defined as a dynamic zone with 
> allow-update from the IP running the monitor script.
>
> Len
>
>
>
>
>


-- 
Looking for (employment|contract) work in the
Internet industry, preferably working remotely. 
Building / Supporting the net since 2400 baud was
the hot thing. Ask for a resume! ispbuil...@gmail.com

Postfix -> bogofilter -> Dovecot -> Sieve

[Mike]

I've been trying to work out how to get postfix to accept mail, send  
it to bogofilter, then deliver using dovecot while allowing a global  
sieve filter and users able to filter mail based on the bogofilter  
header.


I've been successful at getting it to add the bogofilter header as  
needed, but don't understand what I need to do in order to have it get  
routed to sieve.


Anyone do anything like this already and have a working config?

I THINK I need to make dovecot deliver mail locally using lmtp or lda,  
but I'm not exactly sure.


Thanks for any thoughts or ideas that you might have to accomplish this.


Mike.

Re: Some DNSSEC/DANE questions

[Mike]

On 1/3/2022 2:38 PM, Dan Mahoney (Gushi) wrote:
>[snip]
> 
> One more question: Does anyone know of a "reflector" like service that one 
> can use to test DANE validation, i.e. a site that one is allowed to send 
> test messages to, that *only* has DANE as the trust mech (so, say, a 
> self-signed cert?)

Here's an SMTP DANE validator that I use when I make changes to my server.

https://dane.sys4.de/


I'm not sure if it is just what you're looking for, though.

Re: OpenDKIM

[Mike]

On 11/7/2015 9:09 AM, Steve Jenkins wrote:
> On Saturday, November 7, 2015, John Allen  > wrote:
> 
> Interesting!
> I tried a couple of DKIM test sites, one says I am signing my
> emails, the other says I am not!!
> Mailradar say I am not signing!
> DKIMValidator say I am!
> 
> 
> My favorite "test site" for SPF, DKIM, DMARC configuration
> and validation is sending to a Gmail account and then viewing the raw
> message headers.

Does gmail display whether or not the DNS information for DKIM is
secured by DNSSEC?

Re: DANE statistics

[Mike]

On 12/10/2015 9:29 AM, Dirk Stöcker wrote:
> Hello,
> 
> does anyone here have statistics about DANE enabled mail servers? And 
> maybe also a timeline showing an increase (hopefully)? I'm running DANE 
> for some time now and I don't ever get a Verified connection (except to my 
> second server). That's a bit discouraging. I'd like to have at least once 
> in a while a "Yeah" effect :-)

fwiw, here's the verified that I saw yesterday on my very low traffic MTA:

Verified TLS connection established to mx.ams1.isc.org
Verified TLS connection established to mx2.comcast.net
Verified TLS connection established to mx.pao1.isc.org


Comcast is a very large ISP here in the US.

Re: WoSign/StartCom CA in the news

[Mike]

On 9/28/2016 4:55 AM, li...@lazygranch.com wrote:
> CACert came up in my search. I will look into it. Suggestions always 
> appreciated since I'm quite comfortable with people out there knowing more 
> than me.
> 
> I didn't like the Let's Encrypt 90 day deal with mysterious upload to your 
> server. It bugs me. About the only outside control of my server I accept is 
> spam RBLs, because really I have no alternative.
> 
> I understand there is github code out there (perhaps your simp_le) as an 
> alternative to whatever Let's Encrypt does regarding updates, but that seems 
> just as dicey.


fwiw, I use GeoTrust's RapidSSL cert.

I buy it through my registrar, namecheap, but I found it is also
available a bit less expensively via enom (namecheap's parent) for $10
per year.  It works fine for my low-traffic personal email and webservers.

http://www.enom.com/secure/geotrust-ssl-certificates.aspx

Re: WoSign/StartCom CA in the news

[Mike]

On 9/28/2016 10:53 AM, KSB wrote:
> On 2016.09.28. 17:47, Mike wrote:
>> On 9/28/2016 4:55 AM, li...@lazygranch.com wrote:
>>> CACert came up in my search. I will look into it. Suggestions always 
>>> appreciated since I'm quite comfortable with people out there knowing more 
>>> than me.
>>>
>>> I didn't like the Let's Encrypt 90 day deal with mysterious upload to your 
>>> server. It bugs me. About the only outside control of my server I accept is 
>>> spam RBLs, because really I have no alternative.
>>>
>>> I understand there is github code out there (perhaps your simp_le) as an 
>>> alternative to whatever Let's Encrypt does regarding updates, but that 
>>> seems just as dicey.
>>
>>
>> fwiw, I use GeoTrust's RapidSSL cert.
>>
>> I buy it through my registrar, namecheap, but I found it is also
>> available a bit less expensively via enom (namecheap's parent) for $10
>> per year.  It works fine for my low-traffic personal email and webservers.
>>
>> http://www.enom.com/secure/geotrust-ssl-certificates.aspx
>>
>>
> When we need some specific certificates, our company used to by from 
> GoGetSSL.com
> Geotrust's rapid for comparision: https://www.gogetssl.com/rapidssl/


Thanks, bookmarked.


btw, if anyone wants to check out the RapidSSL cert in production, the
Los Angeles, USA  Postfix mirror uses one.

postscreen log scanner script updated

[Mike.]

I cleaned up my pslogscan.sh script a bit.  Aside from some general
cleanup, I did some re-formatting of the output to make it look a bit
cleaner, and allow for some flexibility in display widths.  I also
went from linear processing of multiple items to loop processing of
those items.


You can download the script from here:
 http://archive.mgm51.com/sources/pslogscan.html



Sample output, showing Postscreen rejecting about 18% of the incoming
mail. Note the postscreen portion of this maillog is about 340MB in
size, about 3 million postscreen log records. The results of the time
command are shown after the sample output.

 

Scanning /var/log/maillog
 
  Screening status log records:
  CONNECT: 705024
 PASS NEW:  31104
 PASS OLD: 228096
  WHITELISTED: 316224
  BLACKLISTED:  0
 
 rejected: 129600  (18%)
 
 
  Protocol error log records:
   HANGUP:  57024
 PREGREET:  10368
 BARE NEWLINE:  0
   COMMAND TIME LIMIT:  0
   COMMAND PIPELINING:  0
 
  DNS black list log records:
 zen.spamhaus.org: 160704
   bl.spamcop.net:  51840
   b.barracudacentral.org:  98496
 
  DNSBL NOQUEUE log records: 
 DNSBL rank 1:  0
 DNSBL rank 2:  0
 DNSBL rank 3:  10368
 DNSBL rank 4:  0
 DNSBL rank 5:  10368
 DNSBL rank 6:  51840
 DNSBL rank 7:  0
 DNSBL rank 8:  46656
 DNSBL rank 9:  0
   DNSBL rank 10+:  0
 
  DNSBL NOQUEUE by domain: 
  example.com:  36288
  example.net:  15552
  example.org:  0
 

   
   

Time command results for the above sample:

real0m8.112s
user0m3.350s
sys 0m3.703s

 

Re: postscreen log scanner script updated

[Mike.]

On 9/29/2014 at 10:44 AM Mike. wrote:

|I cleaned up my pslogscan.sh script a bit.  Aside from some general
|cleanup, I did some re-formatting of the output to make it look a
bit
|cleaner, and allow for some flexibility in display widths.  I also
|went from linear processing of multiple items to loop processing of
|those items.
[snip]
 =


Someone found a typo that the FreeBSD shell seems to be OK with, but
Debian (wheezy) dislikes.


Version 1.8 has been uploaded to 
   http://archive.mgm51.com/sources/pslogscan.html


If you don't want to download, here's the description:


I fixed line 144 with :
if [ ${DeepProtocolTestsEnabled} = "no" ] ; then

instead of
if [ ${DeepProtocolTestsEnabled} == "no" ] ; then



(I guess I've been programming in c too much of late.  :) )

Thanks to AE for the bug report.

Re: Goodbye IBM, Hello Google

[Mike.]

On 3/24/2015 at 4:00 PM wie...@porcupine.org wrote:

|After 18 years, including the best of my career, I decided that it
|was time to move on. I'll be working on security at Google NY.
|
|Please, there is no reason to say negative things about my old
|employer (or my new one!).
|
|Needless to say, I will continue to support Postfix.
|
|   Wietse
 =


Sincere congratulations, and the best of the future for you at
Google!

Mike.

Re: postfix stats

[Mike.]

On 5/7/2015 at 11:09 AM Alex Regan wrote:

|Hi,
|
|>> I've been using pflogsumm but it's old and doesn't know about
|>> postscreen. I'd like to see how many connections are being
refused by
|>> postscreen. What do you like? logwatch? awstats? other?
|>>
|>
|> http://logreporters.sourceforge.net/
|>
|> I believe logwatch now includes recent copies of these two, but I
like
|> to run them standalone anyway.
|
|This one is also very good, and a new version was just made
available:
|
|http://sendmailanalyzer.darold.net/
|
|I'm sure Gilles would love to hear that you're using it and is
receptive 
|to making specific improvements.
 =

Another maillog scanner, but just for postscreen info:

  https://archive.mgm51.com/sources/pslogscan.html

albeit, with a fairly simplified output.

Exploring DANE and Postfix

[Mike]

Postfix 2.11.5 on FreeBSD 10.1 AMD64

I'm starting to look at implementing DANE on Postfix, and I have a
question or two...

Reading the info here:
http://www.postfix.org/TLS_README.html#client_tls_dane

I see the following prerequisite:
"A compile-time DNS resolver library that supports DNSSEC. Postfix
binaries built on an older system will not support DNSSEC even if
deployed on a system with an updated resolver library."


I'm running unbound as my local resolver, but I don't know what Postfix
was compiled with, as I installed it from a FreeBSD package.  Is there a
way to see if this prerequisite has been satisfied by the version of
Postfix I am running on my system.



Another question - let's suppose I have succeeded in implementing DANE.
 Will I see any evidence of that success in the Postfix logs or message
headers (such as I see for TLS)?

thx.

Re: Exploring DANE and Postfix

[Mike]

On 7/26/2015 2:06 PM, Viktor Dukhovni wrote:
> On Sun, Jul 26, 2015 at 01:50:58PM -0400, Mike wrote:
[snip]
> 
>> Is there a way to see if this prerequisite has been satisfied by the
>> version of Postfix I am running on my system.
> 
> Send mail to one of the known DANE TLSA domains (after enabling DANE
> per the documentation):
> 
>   sendmail -bv postmas...@ietf.org
>   sendmail -bv postmas...@freebsd.org
>   sendmail -bv postmas...@debian.org
>   sendmail -bv postmas...@openssl.org
>   sendmail -bv postmas...@samba.org
>   sendmail -bv postmas...@torproject.org
> 
> and check the logs to see whether the TLS authentication status was
> "Verified".

I happened to subscribe to the dane-users mailing list a few minutes ago
and [surprise!] its server is DANE-enabled.


>> Another question - let's suppose I have succeeded in implementing DANE.
>>  Will I see any evidence of that success in the Postfix logs or message
>> headers (such as I see for TLS)?
> 
> Just the logs, when you send mail to a DANE-enabled domain. 

This is what I see in the log with a TLS-enabled server:

 postfix/smtp: Trusted TLS connection established to ...


This is what I see for a DANE-enabled server:

 postfix/smtp: Verified TLS connection established to ...



Now I need to wait a few more days for my MTA's domain to transfer to a
DNSSEC-capable registrar and I'll set up it for DANE.

Many thanks for the comments.

Re: Exploring DANE and Postfix

[Mike]

On 7/26/2015 2:11 PM, Wietse Venema wrote:
[snip]
> 
> Postfix needs to be build on a system where libresolv supports
> DNSSEC.  This is already available in a FreeBSD 7.2 virtual machine
> that I have lying around.

I'm running on FreeBSD 10.1, and it looks fine.

Many thanks for the comments.

Re: Exploring DANE and Postfix

[Mike]

On 7/26/2015 2:11 PM, Wietse Venema wrote:
> Mike:
>> Postfix 2.11.5 on FreeBSD 10.1 AMD64
>>
>> I'm starting to look at implementing DANE on Postfix, and I have a
>> question or two...
>>
>> Reading the info here:
>> http://www.postfix.org/TLS_README.html#client_tls_dane
>>
>> I see the following prerequisite:
>> "A compile-time DNS resolver library that supports DNSSEC. Postfix
>> binaries built on an older system will not support DNSSEC even if
>> deployed on a system with an updated resolver library."
> 
> Postfix needs to be build on a system where libresolv supports
> DNSSEC.  This is already available in a FreeBSD 7.2 virtual machine
> that I have lying around.
> 
> freebsd72% grep RES_USE_DNSSEC /usr/include/resolv.h
> #define RES_USE_DNSSEC  0x0020  /*%< use DNSSEC using OK bit in OPT */
> 
>> I'm running unbound as my local resolver, but I don't know what Postfix
>> was compiled with, as I installed it from a FreeBSD package.  Is there a
>> way to see if this prerequisite has been satisfied by the version of
>> Postfix I am running on my system.
> 
> % strings /usr/libexec/postfix/smtp | grep -i tlsa
> lmtp_tls_force_insecure_host_tlsa_lookup
> smtp_tls_force_insecure_host_tlsa_lookup
> TLSA lookup error for %s:%u
> no TLSA records found
> TLSA records unusable
>  
>> Another question - let's suppose I have succeeded in implementing DANE.
>>  Will I see any evidence of that success in the Postfix logs or message
>> headers (such as I see for TLS)?
> 
> With opportunistic TLSA, I suppose it will say something.
> 
>   Wietse
> 


Bringing this thread to closure

The domain in question has migrated to the new registrar and now has
DNSSEC enabled.

In the logs for Postfix client I see the "Verified" as I noted in
another email.


To test the server's configuration, I found this site:
https://dane.sys4.de/
that lets me know if Postfix server DANE (along with DNSSEC and TLSA) is
working as expected.  So far, everything is working quite well.


Thanks for the assist.

(Now on to the next project)

Re: Exploring DANE and Postfix

[Mike]

On 7/31/2015 11:54 AM, Viktor Dukhovni wrote:
> On Fri, Jul 31, 2015 at 11:47:55AM -0400, Mike wrote:
> 
>> To test the server's configuration, I found this site:
>> https://dane.sys4.de/
>> that lets me know if Postfix server DANE (along with DNSSEC and TLSA) is
>> working as expected.  So far, everything is working quite well.
> 
> The key success metric will be whether you'll still remember that
> you published TLSA records when it is tme to deploy a new SSL
> certificate.
> 
> https://dane.sys4.de/common_mistakes#3
> https://dane.sys4.de/common_mistakes
> 
> At present indeed both of your domains are configured correctly.
> Good luck.
> 

I had read the "common mistakes" page previously.  Good, helpful stuff
therein.

Even before I read it, though, I modified the script I use to publish my
certs to show a reminder prompt about adding/removing the TLSA records
(with multiple TTL periods elapsed) *before* the new certs are published.

Thanks.

Forward Secrecy in the Postfix SMTP Client

[Mike]

On this page:
http://www.postfix.org/FORWARD_SECRECY_README.html#client_fs



There is:


 Once the parameters are in place, update main.cf as follows:

/etc/postfix/main.cf:
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
smtpd_tls_dh512_param_file = ${config_directory}/dh512.pem





I notice the line starting with 'smtpd_tls_dh1024_param_file' points to
a 2048 file.

Is that correct, or might it be a typo?

thanks.

Re: Forward Secrecy in the Postfix SMTP Client

[Mike]

On 8/9/2015 12:48 PM, Viktor Dukhovni wrote:
> On Sun, Aug 09, 2015 at 12:42:00PM -0400, Mike wrote:
> 
>> On this page:
>> http://www.postfix.org/FORWARD_SECRECY_README.html#client_fs
>>
>> There is:
>>
>>  Once the parameters are in place, update main.cf as follows:
>>
>> /etc/postfix/main.cf:
>> smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
>> smtpd_tls_dh512_param_file = ${config_directory}/dh512.pem
> 
> These are SMTP server not SMTP client settings (for some reason
> your subject line says "Client").

I cited the wrong subsection, both as you noted in my text and also the
URL.  I should have pointed to
http://www.postfix.org/FORWARD_SECRECY_README.html#quick-start


> 
>> I notice the line starting with 'smtpd_tls_dh1024_param_file' points to
>> a 2048 file.
>>
>> Is that correct, or might it be a typo?
> 
> It is not a typo and rationale is explained in the document.
> 
> http://www.postfix.org/FORWARD_SECRECY_README.html#server_fs
> 
>   EDH Server support:
> 
>   ...
> 
> Take a few minutes to read more of the document.


I had seen the rationale in the master.cf / submission section.  I was
unsure if that same rationale also applied to the main.cf section.

Thanks for confirming it is correct as written.

Re: Postfix 20 years ago

[Mike]

On 2/12/2017 1:06 PM, Wietse Venema wrote:
> Last month it was 20 years ago that I started writing Postfix code.


Many thanks for the amazing Postfix.

The quality and functionality of the software is among the best.


Mike.

Re: postscreen log summary

[Mike]

On 7/24/2017 12:12 PM, Scott Techlist wrote:
> Anyone have or know of a log parser/tool that includes postscreen logs?  I
> don't think Jim's pflogsum includes any type of postscreen data.
> 
> Would be nice to have some reporting that included how much I'm potentially
> preventing vs. processing.


Here's a script that works for me:

https://archive.mgm51.com/sources/pslogscan.html


Hope this helps.

Re: Letsencrypt tip

[Mike]

On 9/11/2017 5:21 AM, Dominic Raferd wrote:
> 
> 
> On 11 September 2017 at 11:59, Gary  > wrote:
> 
> As you know, letsencrypt certs can be automatically updated.
> However, you need to reload/restart Postfix/Dovecot to use the new
> cert. My email client insisted I had an expired cert. I couldn't
> download or send email. (Fortunately I'm on a test domain, getting
> ready for the Oct 1st Google insistence on encryption.)
> 
> Letsencrypt suggests running acme on a daily basis, so just do the
> same for Postfix and Dovecot.
> 
> 
> ​Does anyone know a way to detect if the certificate currently being
> used by Postfix and/or Dovecot is nearing expiry (esp. in case they
> haven't picked up the updated letsencrypt certificate)?
> 

Why not use entr (http://entrproject.org/) to detect when there is a new
certificate file, and restart Dovecot/Postfix?

Re: rsyslogd and postfix

[Mike]

On 4/25/2018 2:08 PM, @lbutlr wrote:
> This might be of use to others out there. I decided that monitoring mail.log 
> was too much of a pain with all the postscreen and dnsblog 'noise' from 
> obscuring the information that I wanted to see, so I split those log events 
> into their own log file using rsyslogd with the following lines in 
> rsyslogd.conf (before the lines that log mail.log)
> 
> if $syslogtag contains 'postscreen' then /var/log/postscreen.log
> if $syslogtag contains 'postscreen' then ~
> if $syslogtag contains 'dnsblog' then /var/log/postscreen.log
> if $syslogtag contains 'dnsblog' then ~
> 
> This lets me keep mail.log for quite a while and rotate off postscreen.log 
> very quickly since it is not something I need to check very often at all.
> 
> I've been doing this for a week or two now and found it useful enough I 
> thought it worth passing along.

I have a similar log strategy but I let postfix do it for me.

For example, my postscreen entry in master.cf is:


smtp  inet  n   -   n   -   1   postscreen
-o syslog_facility=local2



That sends the postscreen logging to the local2 log facility.

Re: rsyslogd and postfix

[Mike]

On 4/26/2018 3:08 PM, @lbutlr wrote:
> On 2018-04-26 (06:46 MDT), Mike  wrote:
>>
>> I have a similar log strategy but I let postfix do it for me.
>>
>> For example, my postscreen entry in master.cf is:
>>
>>
>> smtp  inet  n   -   n   -   1   postscreen
>>  -o syslog_facility=local2
>>
>>
>>
>> That sends the postscreen logging to the local2 log facility.
> 
> Sure that's a perfectly workable solution, but I am able to log the specific 
> information that I nearly never need into a specific log file without having 
> to keep track of which of the nearly identically named local1 local2 etc 
> facilities is setup for what. It's also easy for me to add other data that I 
> don't need in the logs (like I have one automated user who logins in ever 3 
> minutes. The only thing I ever need to know is if that login fails for some 
> reason or all the warnings about hosts not resolving (but not any other 
> warnings)). there's a lot more flexibility in configuring rsyslog than there 
> is in simply using local1-local6.
> 
> But, whatever works for you is fine. I was just sharing what worked for *me* 
> in case it was of use to someone else.
> 


I wanted the solution to be a part of this thread.

I fully realize that different operators have differing requirements.

For my needs, the solution I posted satisfies my requirement quite
nicely.  You have more extensive requirements that requires more
extensive solutions.  :)

Re: Understanding the importance of submission

[Mike]

On 3/20/2019 11:39 AM, Ralph Seichter wrote:
> * Yassine Chaouche:
> 
>> So the only thing that I need submission port for seems to be to force 
>> TLS connexions, right ?
> 
> You already mentioned having different policies, so the possibilities
> are numerous. Having the dedicated submission port allows me to easily
> force encryption, force authentication (password, client certificates),
> limit users to certain sender domains, add DKIM signatures, to name just
> some examples. I can also flat out reject envelope senders foo@mydomain
> on port 25, add DNS BL/WL checks, various milters, etc.
> 
> In my experience it is easier to configure (and understand) how your
> Postfix instances are operating when inbound and outbound emails are
> entering via separate ports.

The similarity between the two ports is that they both allow a means of
entry for an email into the server.

Beside that, they can (and usually do) have differing policies regarding
that entry.

Keeping the two entry streams separate makes it easier to put the
differing policies into place and to enforce those policies.

If someone, for whatever reason, has very similar policies for the two
ports, then for that person, the distinction of having two separate
ports becomes less apparent.

Postfix can not bind to address (IP)

[Mike Pogue]

Hi!

I have this server with 4 IPs, from x.x.x.10 to from x.x.x.14.

My main domain, example.com is bind to x.x.x.10 address (x.x.x.10 has
a PTR record too)

For some reason postfix (smtp server) is picking up the last IP
x.x.x.14 for outgoing mail instead of x.x.x.10. This is a problem
because I want to implement SPF and it fails.

I tried to set:
smtp_bind_address = x.x.x.10
inet_interfaces = x.x.x.10, 127.0.0.1

And I get the error:
fatal: parameter inet_interfaces: no local interface found for x.x.x.10

Any help and suggestion are highly appreciated.

thanks,
Mike

Re: Postfix can not bind to address (IP)

[Mike Pogue]

Thanks for helping me with this - you're right!

On Thu, Jan 22, 2009 at 7:44 PM, Wietse Venema  wrote:
> Mike Pogue:
>> You're right, the ip set on smtp_bind_address was wrong. Updated this
>> and restarted postfix.
>>
>> Got an error related to clamsmptpd, that tries to connect to x.x.x.x10
>> instead of localhost (127.0.0.1)
>> ~~~
>> www clamsmtpd: 102C71: SERVER: couldn't connect to: x.x.x.10:10026:
>> Transport endpoint is not connected
>> ~~~
>>
>> But the main question remains: how to configure postfix so the
>> outgoing IP is x.x.x.10 and not a random one (x.x.x.13 or x.x.x.14)?
>
> I repeat, Postfix is not a network address translator.
>
> If with smtp_bind_address == X, the machine sends out with
> source-address != X, then you need to look in your network
> configuration.
>
>Wietse
>

Restrict delivery of mail to some addresses to local senders

[mikie mike]

Sorry for this simple and probably already asked question but I couldn't
find any answer anyway...

How to restrict delivery of mail to some addresses (especially local
aliases) to senders from local domains only?

e.g.

I would like only senders from @mycompany.com to be allowed to send a
message to an alias a...@mycompany.com

relaying from localhost

[Mike Robinson]

Hi there,

We have a server on the internet which provides spam filtering and a couple of 
other bits and bobs.

Spam filtering is by postgrey, amavis, clamav and spamassassin. There are no 
local recipients, and all mail is forwarded to the mailbox servers (via 
transport maps) on our various internal nets. Here's the main.cf:

myhostname = server.domain.name
mydomain = domain.name
myorigin = $mydomain
mydestination = server.domain.name
local_recipient_maps =
content_filter = smtp-amavis:[localhost]:10024
mynetworks = xxx.xxx.xxx.xxx
relay_domains = $transport_maps
mailbox_size_limit = 10500
message_size_limit = 10500
bounce_queue_lifetime = 15d
maximal_queue_lifetime = 15d
transport_maps = hash:/etc/postfix/transport
smtpd_helo_required = yes
disable_vrfy_command = yes
virtual_alias_maps = hash:/etc/postfix/virtual
alias_maps = hash:/etc/aliases
recipient_delimiter =
smtpd_client_restrictions = check_client_access 
hash:/etc/postfix/client_access, reject_rbl_client bl.spamcop.net, 
reject_rbl_client dnsbl.njabl.org, reject_rbl_client cbl.abuseat.org
smtpd_helo_restrictions = check_helo_access hash:/etc/postfix/helo_access, 
reject_invalid_hostname
smtpd_sender_restrictions = check_sender_access 
hash:/etc/postfix/sender_access, reject_non_fqdn_sender, 
reject_unknown_sender_domain
smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:6, 
reject_non_fqdn_recipient, reject_unverified_recipient, 
reject_unknown_recipient_domain, reject_unauth_destination
smtpd_data_restrictions = reject_unauth_pipelining
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
sample_directory = /usr/share/doc/postfix-2.3.3/samples
sendmail_path = /usr/sbin/sendmail
html_directory = no
setgid_group = postdrop
command_directory = /usr/sbin
manpage_directory = /usr/share/man
daemon_directory = /usr/libexec/postfix
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq
queue_directory = /var/spool/postfix
mail_owner = postfix

This server is not heavily used, so we would like to add a web app. The web 
app needs to be able to send email to a range of email destinations which is 
broader than that listed in the transport file. I don't want to have to add 
recipient domains to the transport file, because there will be recipients using 
this web app for whom we don't want to relay mail coming from the internet. We 
will want to relay all mail originating from the webserver on localhost.

If what we're trying to do is very bad practice, we'll come up with another 
solution. But if there's no problem with it in principle, can anyone offer any 
hints for how to set it up?

Many thanks,

Mike.

Re: relaying from localhost

[Mike Robinson]

Hi Magnus,

Thanks for replying. 

>
> If that is the case, why isn't mydestination empty? You have emptied
> local_recipient_maps, but this means that all addresses are accepted
> (and then possibly bounced, which is bad).
>

Because I was getting messages in the logs like this, and 
/var/spool/clientmqueue/ was filling up, even though I have an alias to a real 
email address set up for emails to root:

to=root, ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, 
pri=30372, relay=[127.0.0.1] [127.0.0.1], dsn=4.1.1, stat=Deferred: 450 4.1.1 
: Recipient address rejected: undeliverable address: mail 
for server.domain loops back to myself

>
> Just make sure 127.0.0.1/32 (or 127.0.0.0/8) is listed in mynetworks.

I had tried that, and it doesn't work. If there is no server defined in 
/etc/postfix/transport for the recipient's domain, it won't relay:

Jun  7 06:35:04 servername postgrey[2392]: action=pass, reason=client AWL, 
client_name=localhost.localdomain, client_address=127.0.0.1, 
sender=ad...@server.domain, recipient=exter...@email.address 
Jun  7 06:35:04 servername postfix/smtp[28011]: 1F9033BE46: 
to=, relay=external.relay.server[xxx.xxx.xxx.xxx]:25, 
delay=0.3, delays=0.01/0.01/0.16/0.12, dsn=2.0.0, status=deliverable (250 
 ok)
Jun  7 06:35:07 spam1 postfix/smtpd[28007]: NOQUEUE: reject: RCPT from 
localhost.localdomain[127.0.0.1]: 554 5.7.1 : Relay 
access denied; from= to= 
proto=ESMTP helo=

Here's postconf -n:

alias_maps = hash:/etc/aliases
bounce_queue_lifetime = 15d
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[localhost]:10024
daemon_directory = /usr/libexec/postfix
disable_vrfy_command = yes
html_directory = no
local_recipient_maps = 
mail_owner = postfix
mailbox_size_limit = 10500
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maximal_queue_lifetime = 15d
message_size_limit = 10500
mydestination = server.domain.name
mydomain = domain.name
myhostname = server.domain.name
mynetworks = xxx.xxx.xxx.xxx,xxx.xxx.xxx.xxx,127.0.0.1/32
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
recipient_delimiter = 
relay_domains = $transport_maps
sample_directory = /usr/share/doc/postfix-2.3.3/samples
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_client_restrictions = check_client_access 
hash:/etc/postfix/client_access, reject_rbl_client bl.spamcop.net, 
reject_rbl_client dnsbl.njabl.org, reject_rbl_client cbl.abuseat.org
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_helo_restrictions = check_helo_access hash:/etc/postfix/helo_access, 
reject_invalid_hostname
smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:6, 
reject_non_fqdn_recipient, reject_unverified_recipient, 
reject_unknown_recipient_domain, reject_unauth_destination
smtpd_sender_restrictions = check_sender_access 
hash:/etc/postfix/sender_access, reject_non_fqdn_sender, 
reject_unknown_sender_domain
transport_maps = hash:/etc/postfix/transport
virtual_alias_maps = hash:/etc/postfix/virtual

Re: relaying from localhost

[Mike Robinson]

On Sunday 07 June 2009 09:14:24 mouss wrote:

>
> maybe be because you forgot to put that domain under relay_domains.
>

Ah, right, yes. Thanks!

>
> you don't have permit_mynetworks here. and btw, the order of your checks
> is dubious.
>
> smtpd_recipient_restrictions =
>   reject_non_fqdn_recipient
>   reject_unknown_recipient_domain
>   permit_mynetworks
>   reject_unauth_destination
>   reject_unverified_recipient
>   check_policy_service inet:127.0.0.1:6
>

Dubious indeed. 

Thanks to you and Magnus for your help. Its working now. I'd be interested in 
knowing what's wrong with reusing the transport maps in the way that I have?

Thanks again.

Rate control for SMTP delivery to speicific domain

[Mike Hutchinson]

Hello Everyone.

 

Our company sends out newsletters to people who have subscribed their mail
address in-store (retail). I have been working in attempt to slow down
E-Mail deliveries to Hotmail, as our server attempts deliveries too quickly
and will get blocked by their servers. I have googled and found some decent
information and have even applied it, but it does not appear to do a single
thing to slow delivery down for the domain. I have in my configuration
files:

 

Master.cf:

smtphotmail  unix   -  -  -  -
3  smtp

 

Transport:

hotmail.com   smtphotmail:hotmail.com

 

Main.cf:

smtphotmail_destination_concurrency_limit = 2

smtphotmail_destination_rate_delay = 3s

 

 

I was using the global limiters and these were working just fine - we were
able to deliver OK, until I commented them out:

#initial_destination_concurrency = 3

#local_destination_concurrency_limit = 3

#smtp_destination_concurrency_limit = 3

#smtp_destination_rate_delay = 2s

 

It appears that whenever I use the smtphotmail transport rules, instead of
the global ones, delivery attempts to the domain increase as if there was no
limitation.. Ie: after a Postfix reload, I follow the mail.info log and find
straight after the reload that there are instantly pages and pages of
delivery attempts to hotmail.com. To me this doesn't make sense - the rate
limit means I should only see a few, every couple of seconds, right?

 

Am I missing something here? 

 

Thanks in advance,

 

Yours Sincerely,

Michael Hutchinson

 

RE: Rate control for SMTP delivery to speicific domain

[Mike Hutchinson]

> >
> > smtphotmail  unix   -  - -  -  3
> smtp
> 
> Who told you to set a wakeup timer of 3 seconds? Remove it.

No-one did. I had intended to set a max processes limit..

As I understand it, this would be setting the Max Processes limit.
smtphotmail unix-   -   -   -   3   smtp

And setting the wakeup timer would be like this:
smtphotmail unix-   -   -   3   -   smtp


 
> > Transport:
> > hotmail.com   smtphotmail:hotmail.com
> 
> How do you know that Postfix uses this? The cut-and-paste fragments
> from the main.cf file show no evidence of that.

I have the transport referenced in main.cf, and have used postmap to build
the db. 



> As requested in the mailing list welcome message (see below) do
> NOT send cut-and-paste fragments from the main.cf file.

My apologies. Ill go back and start from scratch.



Cheers,
Michael

RE: Rate control for SMTP delivery to speicific domain

[Mike Hutchinson]

> -Original Message-
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
> us...@postfix.org] On Behalf Of Sahil Tandon
> Sent: Tuesday, 30 March 2010 3:07 p.m.
> To: postfix-users@postfix.org
> Subject: Re: Rate control for SMTP delivery to speicific domain
> 
> On Tue, 30 Mar 2010, Mike Hutchinson wrote:
> 
> > As I understand it, this would be setting the Max Processes limit.
> > smtphotmail unix-   -   -   -   3   smtp
> 
> That is how you set maxproc, but why do you need 3 for this transport?

This transport points to a rather fragile mail server, in other words, we
are going over their acceptable delivery rate and our Server IP gets banned
unless we do something about rate control. I assumed the Max Processes would
assist with this, but perhaps I am wrong.

 
> > And setting the wakeup timer would be like this:
> > smtphotmail unix-   -   -   3   -   smtp
> 
> That is how you set the timer.

Yes, not what I am doing / want to do.

> > My apologies. Ill go back and start from scratch.
> 
> What version of Postfix is this?

Postfix mail_version = 2.5.1

Cheers,
Michael Hutchinson

RE: Rate control for SMTP delivery to speicific domain

[Mike Hutchinson]

> 
> > > What version of Postfix is this?
> >
> > Postfix mail_version = 2.5.1
> 
> The rate control features introduced in 2.5.0 were improved in later
> patches, you must upgrade to the latest 2.5 release if you want to
> enforce inter-message delays.
> 

Sounds interesting. I shall investigate and persue upgrading our Postfix to
a more recent version.

Thanks for the information

Cheers,
Michael Hutchinson

RE: Rate control for SMTP delivery to speicific domain

[Mike Hutchinson]

> >
> >>> And setting the wakeup timer would be like this:
> >>> smtphotmail   unix-   -   -   3   -   smtp
> >>
> >> That is how you set the timer.
> >
> > Yes, not what I am doing / want to do.
> >
> >>> My apologies. Ill go back and start from scratch.
> >>
> >> What version of Postfix is this?
> >
> > Postfix mail_version = 2.5.1
> >
> > Cheers,
> > Michael Hutchinson
> >
> >
> 
> Postfix 2.5.1 is pretty old, the current 2.5 patchlevel is 10.
>   There have been some changes that could affect your rate
> delay controls.
> 
> Anyway, for diagnostics you can add a '-o
> syslog_name=smtphotmail' to your master.cf entry to verify the
> correct transport is being used, or for more info add a -v to
> your smtphotmail transport to see what it's up to.
> 
> Also see the "slow" transport example under
> http://www.postfix.org/QSHAPE_README.html#backlog


Ahh, some direct logging would be nice. Thanks for the information and
links. I will also check out whether my postfix needs to be upgraded. 

Cheers,
Michael Hutchinson

RE: Rate control for SMTP delivery to speicific domain

[Mike Hutchinson]

> >>
> >> What version of Postfix is this?
> >
> > Postfix mail_version = 2.5.1
> 
> That's what I suspected.  Upgrade; see RELEASE_NOTES for
> destination_rate_delay fix last year.  Also show logs confirming your
> special transport is actually being used.

Excellent. Sounds like I have my answer. Thanks for the info, everyone,
including Wietse.

Hopefully all will be resolved today.

Cheers,
Michael Hutchinson.

Patch: support BURL

[Mike Abbott]

Hello Postfix community,

Attached please find a patch that adds support to postfix-2.7.0 for RFC
4468 - Submission BURL.

BURL requires a pre-configured trust relationship between the submission
server and the IMAP server.  This patch adds a new configuration file
normally named "submit.cred" that contains text entries each specifying
an IMAP server hostname, a submit username, and a password.  The patched
submission server logs into the IMAP server using:
   - the user in the URL given to the BURL command as the SASL PLAIN
 authorization ID
   - the username from the corresponding submit.cred entry as the SASL
 PLAIN authentication ID
   - the password from the corresponding submit.cred entry as the
 password

The patched submission server logs into the IMAP server using either the
PLAIN or a non-standard X-PLAIN-SUBMIT authentication method.
X-PLAIN-SUBMIT specifically allows plain-text submit user logins while
plain-text regular user logins are not allowed.  This lets the system
administrator configure the same submit user and password credentials on
both the submission server and the IMAP server.  A secure connection is
required.

Today Apple also contributes BURL, CATENATE and URLAUTH support to the
Dovecot open source project.  Postfix BURL interoperates with Dovecot
BURL/URLAUTH.

Please note that all of our changes are commented with "APPLE" not to
pollute the code but to help us merge in your new releases.  Feel free
to remove those comments or restructure or rewrite the code as desired,
as long as you preserve our copyright.  We understand that our
implementation choices may differ from yours; if you see a better way to
achieve the same goal please do adopt the better way.  Some areas we are
aware could use improvement but satisfy our own needs:
   - the hard-coded TLS parameters
   - submit.cred does not match the format of other postfix config files

Please let me know if you have any questions, concerns, or bug reports
regarding this patch.  Thanks.



postfix-2.7.0+burl.patch.gz
Description: GNU Zip compressed data

Re: Patch: support BURL

[Mike Abbott]

Thank you for pointing out that I did not explain the contents of the 
submit.cred file well enough.  This file contains a single username and 
password per IMAP server which postfix uses to authenticate to that IMAP 
server.  Typically the username is "submit".  It does NOT contain regular 
users' names and passwords.  Here is an example:

submitcred version 1
server1.example.com|submit|password1
server2.example.com|submit|password2
server3.example.com|submit|password3

First field is host name.  Second field is user name.  Third field is the 
password for the user name in the second field.

The "submit" user on each of those servers must be able to authenticate using 
the password shown above (third field) and authorize for any user.  So when 
Postfix receives a BURL command with an IMAP URL for, say, 
f...@server2.example.com, Postfix logs into the IMAP server on 
server2.example.com with:  authz=fred, authc=submit, pw=password2.  Postfix 
does not know fred's password.

> in any case a fixed password for the "submit" user that is authorized
> to fetch messages for submission. With this the submission server
> just needs a single submission user id and password per IMAP server,
> not per IMAP user.

This is the method it uses.  Only, the IMAP server must permit the submit user 
to reach into any user's mail.

> Which IMAP servers implement the non-standard X-PLAIN-SUBMIT, and which
> (non-standard) document describes this protocol?

The patch Apple contributed to Dovecot today adds support for X-PLAIN-SUBMIT to 
Dovecot.  Patched Postfix can also use PLAIN if available.

> Given support for URLAUTH, why does the Postfix contribution not
> leverage that?

I don't understand this question.  The contribution does leverage URLAUTH.  
BURL logs into the IMAP server specifically to issue an URLFETCH command.

> Is anyone at Apple interested in
> working on a project to gradualy (not everything at once) integrate
> the apple features into the mainstream Postfix?

I will ask.

Re: Patch: support BURL

[Mike Abbott]

>> +if (in_stream == NULL) {
>> +/* must fail the entire transaction */
>> +chat_reset(state, var_smtpd_hist_thrsh);
>> +mail_reset(state);
>> +rcpt_reset(state);
>> +return -1;
>> +}
> 
> Why no response to the client?

The function imap_open() responds to the client before it returns NULL.
in_stream = imap_open(state, url);

>> +case SMTP_ERR_EOF:
>> +smtpd_chat_reply(state, "554 4.6.6 EOF from IMAP server");
>> +vstream_longjmp(state->client, SMTP_ERR_QUIET);
>> +break;
> 
> Why is the DSN code 4.X.X when the SMTP reply code is 5XX? Is this a
> permanent or a transient error code? 

It is a transient failure.  The reasoning for these particular codes was as 
follows.  RFC 4468 section 3.2 states "If the URL fetch fails, the server will 
fail the entire transaction."  RFC 5321 section 4.2.2 uses code 554 for 
"Transaction failed."  And the table in RFC 5248 section 2.4 implies that a 
4.6.6 is valid with a 554.  If this interpretation of the RFCs is incorrect, 
please propose corrected response codes.


The remainder of your feedback speaks to style and to weaknesses in the 
implementation that I pointed out in the cover letter to the code contribution. 
 That cover letter also said:
Feel free to [...] restructure or rewrite the code as desired,
as long as you preserve our copyright.  We understand that our
implementation choices may differ from yours; if you see a better way to
achieve the same goal please do adopt the better way.

Re: Patch: support BURL

[Mike Abbott]

> In the mean time, the authors may want to enforce strict sanity
> checks on IMAP server output such as the reply payload length, and
> also make sure that their vstream_limit code behaves when reads
> are alternated with writes (either refuse to allow read/write/read,
> or enforce the limit as promised).

OK

> One question I have is why would anyone send an email message that
> is 100% identical to a message that is already sitting in an IMAP
> store?

Because the message in the IMAP server is brand-new, having just been composed 
by the user.  For instance:
1.  As the user composes a new message, the MUA saves the new message in the 
IMAP "Drafts" mailbox, possibly by using CATENATE (RFC 4469) and URLAUTH (RFC 
4467) to compose it out of parts of other messages already on the IMAP server.
2.  The MUA connects to Postfix and uses a BURL command instead of a DATA 
command.
3.  Postfix connects to the IMAP server to retrieve the body of the message 
from the Drafts mailbox.
4.  After receiving a positive response from Postfix, the MUA moves the message 
from the Drafts mailbox to the Sent mailbox.

Notice that in this example, the body of the message is pushed out of the 
client only once (to the IMAP server).  Without BURL, it is pushed at least 
twice (once to Postfix and a second time to the Sent mailbox, and possibly also 
to the Drafts mailbox for auto-save during composition).  RFC 4550 section 2 
explains it better.  On bandwidth-constrained devices such an optimization can 
have a significant effect.

> Why is there a problem with sending mail to the SMTP server directly,
> instead of taking an indirect route via an IMAP server?

There is no such problem.  The problem is the double- or triple-transmission 
that is currently needed: once to SMTP, again to IMAP (for saving a copy in 
Sent, and auto-save to Drafts).

> explain why sending to an IMAP server is 
> faster than sending that same message to an SMTP server.

It isn't, except for CATENATE (RFC 4469) and URLAUTH (RFC 4467).  With these 
one can forward a huge attachment using minimal bandwidth.  Then once the new 
huge message is complete, fast server-to-server communication (i.e., BURL) can 
be used to send it.  The example in RFC 4550 section 2.4.1 shows how an 
arbitrarily-large attachment can be forwarded while using only a couple KB of 
bandwidth for mail headers, MIME headers, and plain-text comments.

The savings is in the reduction of bandwidth between the client and the server 
-- both servers, IMAP and SMTP.  The benefit is in being able to forward a 
multi-megabyte document from a low-network-bandwidth, high-network-latency 
device using only 2-3 TCP packets rather than thousands.

Re: Patch: support BURL

[Mike Abbott]

> How would this work for messages that are never saved to the Drafts folder?

Then instead the message could be saved to the Sent folder instead, and the 
submission server could fetch it from there.  The MUA would have to remove it 
from the Sent folder if sending failed, of course.  Nothing magic about the 
Drafts folder.

Re: Patch: support BURL

[Mike Abbott]

> This interpretation is incorrect, the 3-digit SMTP code, must match the
> 3-part DSN code. For transient errors use 454.

Thank you.

Re: rate limit issue

[Mike Morris]

On 05/01/2010 11:31 AM, Gary Smith wrote:
>>> rate_limit_transport:
>>> aol.com ratelimit:
>>> yahoo.com   ratelimit:
>>> sbcglobal.net   ratelimit:
>>> gmail.com   ratelimit:
>>>
>> This looks reasonable to me; no more than 3 connections should
>> be made at a time to any combination of those destinations.
>> Why don't you think it's working?
> 
> I'm not sure why I think it's not working.  Skimming the log file, shortly 
> after the back was launched, we saw several of these messages:
> 
> connect to sbcgloabal.net[208.73.210.27]:25: Connection refused
> connect to comcst.net[216.240.187.144]:25: Connection refused 
> connect to eathlink.net[216.65.41.185]:25: Connection refused
> 
> (obviously the last two aren't on the list, but will be added).  Anyway, I 
> will start logging see if it's working.  I also just noticed that the rate 
> limiting file was touched this week, so I need to find out what was touched 
> (which it hasn't been touched in a year since we set it up).
> 

Do you realize the entries you just posted are misspelled domains?  They
are not sbcglobal.net, comcast.net, or earthlink.net.

-Mike

Mail to local domains

[Mike Hutchinson]

Hello all,

 

I am writing to ask for a procedure for sending a broadcast E-Mail to
locally hosted domains on a postfix system. 

 

Currently we use postfixadmin for this, but this is undesirable as it will
often double-up or triple-up entire sends (we intend to fix this,
eventually). I know the previous system we used was basically a script that
copied a file into everyone's Inbox under their Maildir folder - we no
longer have the script, so that idea is out.

 

I've checked out using maildir-bulletin, as this is available in software
repo's (ubuntu). The problem with using this is that our hosted mailboxes
have been setup thusly: /home/vmail/domain.name/mailbox.name. With all
domain.name folders owned by vmail:vmail. Where the intended use of
maildir-bulletin is to pick a group to send to, and mail is delivered to
members of that group, under their Maildir folder. Sounds like a recipe for
disaster, if I run this up on our system. Has anyone had success with this
sort of system, or am I simply barking up the wrong tree?

 

Please help,

 

Thanks in advance, 

Yours Sincerely,

Michael Hutchinson

Manux Solutions Limited

mhutchin...@manux.co.nz

 

 

 

RE: Mail to local domains

[Mike Hutchinson]

> > Currently we use postfixadmin for this, but this is undesirable as it
will
> > often double-up or triple-up entire sends (we intend to fix this,
> > eventually). I know the previous system we used was basically a script
that
> > copied a file into everyone's Inbox under their Maildir folder - we no
> > longer have the script, so that idea is out.
> 
> This is not a postfix question.

[Michael Hutchinson] 
Yes, but postfix people will know how to do it :) - sorry for hijacking the
list. Thanks for the reply, anyway!
 
> However, a script is almost certainly the easiest way to do this, and it's
quite
> trivial if all your users are using Maildirs.
> 
> I use something like this (run via cron out of the user's own crontab)
> 
> ORG="Name of our company/Organization"
> BODY="text of the email I want to send"
> DATE=`date '+%a, %d %b %Y %T %z'`
> 
> echo "Subject: This is my broadcast email"; \
> echo "Date: $DATE"; \
> echo "From: $ORG Broadcast Service ";\
> echo ; \
> echo "$BODY") | /usr/local/maildrop -d
> 

[Michael Hutchinson] 
I must admit, I've not seen people do mail broadcasts from Cron before -
quite clever.

> maildrop makes putting mail into maildirs trivial if you're using Courier.
If
> you're using something else. well, I'm sure there's something similar.
Your
> best bet is to ask this on the list for your mail package.

[Michael Hutchinson] 
Well, we ended up using getting a Perl wizard to assist. We're now using a
perl script, pulling real Mail addresses from MySQL, and using a Perl Mail
module to submit the mail into the postfix queue. As this system hosts under
1000 mail addresses, we don't have to worry about message copies so much. If
this box was hosting a couple of thousand mailboxes, I'd say we'd have gone
with linking the broadcast message into their Inbox, to save mail delivery
routines and load. 

At any rate, we've got what we need now. I thought I'd better be polite and
post the script we're now using, as someone else may find it useful:

http://pastebin.com/6PDAwRzq
Credit goes to Bjorn Nilsen for writing the script. 

Cheers,
Michael Hutchinson
Manux Solutions Limited
mhutchin...@manux.co.nz

RE: dealing with Yahoo slowness

[Mike Hutchinson]

> -Original Message-
> Florin Andrei a écrit :
> > There seems to be a massive difference between the speed of various
> > providers, in terms of accepting messages for delivery. Yahoo stands out
> > as, by far, the slowest of the big ones.
> >
> > Because the messages are legitimate, we signed up for the email feedback
> > loop with Yahoo, so that messages flagged as spam by Yahoo users are
> > reported back to us, so we can silence notifications for those accounts.
> > That didn't seem to help.
> >
> > Messages @yahoo.com just accumulate in the deferred queue and stay
> there
> > for a long time. When they do get kicked back into the active queue,
> > it's just a trickle.
> >
> > Everyone else's emails are delivered very quickly. It might be my
> > imagination, but it seems some providers do accept messages more
> quickly
> > if you use the email feedback loop.
> >
> > Anyway, after a while, we end up with a bunch of @yahoo.com messages
> in
> > the queue, some domain typos, and not much else besides.
> >
> > One of the tricks some people seem to use is creating a dedicated
> > transport for the slow destination. I'm reading the tuning and qshape
> > README documents, and there are a lot of good suggestions there, but I
> > was wondering what are the solutions that are being used *now*
> > specifically for dealing with Yahoo.
> >
> 
> it looks like yahoo throttle you.
> - if you send few mail, do nothing. just wait and things will hopefully
> get better.

[Michael Hutchinson] 
Only OK if you're sending one or two E-Mails.

> - if on the other hand you send a lot of mail, then you need to get in
> touch with yahoo. there's nothing we can do to help you.

[Michael Hutchinson] 
This also does very little. Yahoo don't list a Network Operations Centre and
are about the hardest company to deal with when it comes to E-Mail delivery
resolution. I've filled out dozens of forms to get particular IP's
whitelisted for specific domains on their Mail systems, with no reply, let
alone result. 
 
> one thing you can do is to ask your recipients to explicitely tag your
> mail as "not spam" if it was ever tagged as spam. or they can reply (of
> course, this doesn't work for silly noreply mail. [sigh, I just got an
> internal one with a URL that doesn't work, and I don't know whom to
> contact...]).

[Michael Hutchinson] 
Unfortunately it only takes ONE user to click on "This is Spam" and you're
back to square one. (and being IP banned is Square one).

[Michael Hutchinson] 
We have had this exact problem, delivering Retail newsletters to people who
have opted in for it. A lot of them are on Gmail and Yahoo, and this can be
difficult with Bulk E-Mail. Despite contact with Google themselves and
signing up for all of their reporting services regarding Spammy Emails and
Certified Senders, the best result we've had is to use some Postfix
configuration to resolve the issue. It does this by gently delivering the
E-Mails at an acceptable rate (discovered with a LOT of testing and a LOT of
IP bans (good they're not permanent, huh :). In our environment, on our
servers, this has resolved the issue, and delivers mail to those domains a
LOT faster than not performing the config on Postfix. In fact, if we don’t
configure, we get banned straight away against those domains and cannot
deliver for several hours afterwards.  

We setup the postfix transport file with these entries:
# destination domains that need to be rate limited
hotmail.com hotmail:
msn.com hotmail:
live.comhotmail:
windowslive.com hotmail:
yahoo.com.aryahoo:
yahoo.com.auyahoo:
yahoo.com.bryahoo:
yahoo.cayahoo:
yahoo.com.cnyahoo:
 - there's more but you get the idea.

Then we setup master.cf:

yahoo unix  -   -   -   -   -   smtp
hotmail   unix  -   -   -   -   -   smtp

Then setup main.cf:

# Slow these destinations to avoid blacklisting, see /etc/postfix/transport
for domains configured
hotmail_destination_concurrency_limit = 2
hotmail_destination_rate_delay = 2s
hotmail_destination_recipient_limit = 5
yahoo_destination_concurrency_limit = 4
yahoo_destination_rate_delay = 1s
yahoo_destination_recipient_limit = 5

These settings can be tweaked depending on what server you're talking to.
However, these values work for us, after having dealt with not getting
10,000 mails out per week.

I hope this helps.

Cheers,
Michael Hutchinson
mhutchin...@manux.co.nz

RE: dealing with Yahoo slowness

[Mike Hutchinson]

> > # Slow these destinations to avoid blacklisting, see
/etc/postfix/transport
> > for domains configured
> > hotmail_destination_concurrency_limit = 2
> > hotmail_destination_rate_delay = 2s
> > hotmail_destination_recipient_limit = 5
> > yahoo_destination_concurrency_limit = 4
> > yahoo_destination_rate_delay = 1s
> > yahoo_destination_recipient_limit = 5
> >
> > These settings can be tweaked depending on what server you're talking
to.
> > However, these values work for us, after having dealt with not getting
> > 10,000 mails out per week.
> >
> > I hope this helps.
> 
> Interesting. Really.

[Michael Hutchinson] 
It is. I don't know of any other software that even comes close to
supporting rate limiting for outgoing E-Mail. As I understand it, even
companies that package Postfix in their NetApps are taking advantage of
these features now. 
 
> FYI This should be documented better: Postfix's _rate_delay feature
> forces a per-destination delivery concurrency of 1, so you could
> drop the _destination_concurrency_limit settings.  The Postfix
> implementation is utterly simple: schedule one delivery, then
> suspend delivery for N second, then schedule the next delivery.

[Michael Hutchinson] 
I had thought, whilst I was writing the E-Mail, that this could deserve a
howto or manual section, perhaps briefly describing a general situation that
would reflect the real world problem of delivery of E-Mail to servers like
Yahoo/Google, and how postfix can be configured to react in a more
Yahoo/Google restricted manner. What assistance can I provide ?

Cheers,
Michael Hutchinson
mhutchin...@manux.co.nz

RE: dealing with Yahoo slowness

[Mike Hutchinson]

> -Original Message-
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
> us...@postfix.org] On Behalf Of Florin Andrei
> Sent: Tuesday, 15 June 2010 6:00 a.m.
> To: postfix-users@postfix.org
> Subject: Re: dealing with Yahoo slowness
> 
> On 06/10/2010 05:09 PM, Mike Hutchinson wrote:
> > yahoo_destination_concurrency_limit = 4
> > yahoo_destination_rate_delay = 1s
> 
> Well, we do that already (concurrency = 2, rate_delay = 2s). It's still
> slow. Do you use multiple outbound email gateways?
> 
> Maybe I should try to increase our existing parameters, it looks like
> we're using half your values.

[Michael Hutchinson] made a late reply:
Sounds like you've run into the version problem I had some time ago, where
the rate controls were present, but were a bit buggy. See Wietse's post if
you haven't already. 

Once we'd performed the upgrade, and applied the rate limiting configuration
everything went smoothly - perhaps try the same values from the original
post and work from there.

Cheers,
Michael.
 

Separate Submission Instance on Same IP as MX

[Mike Morris]

Hi,

I'm working on a mail server deployment that will only have one server
for MX and SASL submission purposes.  Generally I like to have separate
Postfix instances to handle a specific task.  In this case I'm running
in to problems when the submission instance uses the same IP address as
the MX instance.  (Due to a limited IP address pool there is currently
only one routable IP address assigned to this server.)

Using the submission instance to send a message to a recipient address
for which the server is also the MX host triggers Postfix' loop
detection.  Mail for foreign addresses is relayed correctly.  I realize
this can be done easily enough without using multiple instances.  Is
there a way to work around this so that an MX instance and submission
instance can share single IP address?  I've gotten used to the queue,
logging, and configuration separation provided by multiple instances and
would rather like to use that approach here if I can.

Configuration and debugging information follow.  In this example, the
server is the MX host for both domains 'example.com' and 'example.org'.



m...@mail[~]$ nc 127.0.0.1 587
220 smtp.example.com ESMTP Postfix
EHLO test
250-smtp.example.com
250-PIPELINING
250-SIZE 1024
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
AUTH PLAIN blahblahblah
235 2.7.0 Authentication successful
MAIL FROM:
250 2.1.0 Ok
RCPT TO:
250 2.1.5 Ok
DATA
354 End data with .
test
.
250 2.0.0 Ok: queued as 098981BF0969
quit
221 2.0.0 Bye




Corresponding log entries for above transaction:

Jul 31 18:27:48 mail postfix-submission/smtpd[13440]: connect from
localhost.localdomain[127.0.0.1]
Jul 31 18:27:56 mail postfix-submission/smtpd[13440]: 098981BF0969:
client=localhost.localdomain[127.0.0.1], sasl_method=PLAIN,
sasl_username=m...@example.com
Jul 31 18:27:59 mail postfix-submission/cleanup[13442]: 098981BF0969:
message-id=<20100801012756.098981bf0...@smtp.example.com>
Jul 31 18:27:59 mail postfix-submission/qmgr[13433]: 098981BF0969:
from=, size=348, nrcpt=1 (queue active)
Jul 31 18:27:59 mail postfix-submission/smtp[13443]: 098981BF0969:
to=, relay=none, delay=4.7, delays=4.6/0.09/0/0,
dsn=5.4.6, status=bounced (mail for example.org loops back to myself)
Jul 31 18:27:59 mail postfix-submission/cleanup[13442]: AB7021BF096B:
message-id=<20100801012759.ab7021bf0...@smtp.example.com>
Jul 31 18:27:59 mail postfix-submission/qmgr[13433]: AB7021BF096B:
from=<>, size=2151, nrcpt=1 (queue active)
Jul 31 18:27:59 mail postfix-submission/bounce[13445]: 098981BF0969:
sender non-delivery notification: AB7021BF096B
Jul 31 18:27:59 mail postfix-submission/qmgr[13433]: 098981BF0969: removed
Jul 31 18:27:59 mail postfix-submission/smtp[13443]: AB7021BF096B:
to=, relay=none, delay=0.15, delays=0.15/0/0/0,
dsn=5.4.6, status=bounced (mail for example.com loops back to myself)
Jul 31 18:27:59 mail postfix-submission/qmgr[13433]: AB7021BF096B: removed
Jul 31 18:28:02 mail postfix-submission/smtpd[13440]: disconnect from
localhost.localdomain[127.0.0.1]



postconf -c /etc/postfix-submission -n:

alias_database =
alias_maps =
config_directory = /etc/postfix-submission
data_directory = /var/lib/postfix-submission
default_database_type = cdb
local_recipient_maps =
local_transport = error:5.1.1 Mailbox unavailable
multi_instance_enable = yes
multi_instance_name = postfix-submission
mydestination =
mydomain = example.com
myhostname = smtp.example.com
myorigin = $mydomain
parent_domain_matches_subdomains =
queue_directory = /var/spool/postfix-submission
smtpd_client_restrictions = permit_sasl_authenticated   reject
smtpd_helo_required = yes
smtpd_recipient_restrictions = reject_non_fqdn_recipient
permit_sasl_authenticated   reject
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = /var/run/dovecot/auth-client
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = reject_non_fqdn_sender
reject_unknown_sender_domain
strict_rfc821_envelopes = yes
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554

mail_version = 2.8-20100707

In master.cf for the postfix-submission instance, the "smtp   inet ...
smtpd" entry is commented out, and "submission   inet ... smtpd" is enabled.


Thanks,

Mike

Re: Separate Submission Instance on Same IP as MX

[Mike Morris]

On 08/01/2010 02:37 AM, Jeroen Geilman wrote:
> On 08/01/2010 04:11 AM, Mike Morris wrote:
>> Hi,
>>
>> I'm working on a mail server deployment that will only have one server
>> for MX and SASL submission purposes.  Generally I like to have separate
>> Postfix instances to handle a specific task.
> 
> Why ?
> It's totally useless in this case.
> SMTP runs on port 25, and rejects anything not_invented_here.
> Submission runs on port 587, and requires SASL.
> Simple.

I don't believe it is "totally useless" to use separate instances for
distinct services.  Configurations can get complex.  Outgoing mail may
be handled differently than incoming mail.  Using multiple instances can
simplify the task.  While it may not *work* in this case, using multiple
instances for MX and submission services is far from *useless*.

> 
>> mail_version = 2.8-20100707
>>
> 
> UNSTABLE.
> sheesh.
> 

Plenty of people would argue that Postfix experimental releases are
quite stable.  In this case I would like to test and make use of postscreen.

Re: Separate Submission Instance on Same IP as MX

[Mike Morris]

On 08/01/2010 09:29 AM, Wietse Venema wrote:
> Mike Morris:
>> Hi,
>>
>> I'm working on a mail server deployment that will only have one server
>> for MX and SASL submission purposes.  Generally I like to have separate
>> Postfix instances to handle a specific task.  In this case I'm running
>> in to problems when the submission instance uses the same IP address as
>> the MX instance.  (Due to a limited IP address pool there is currently
>> only one routable IP address assigned to this server.)
>>
>> Using the submission instance to send a message to a recipient address
>> for which the server is also the MX host triggers Postfix' loop
>> detection.  Mail for foreign addresses is relayed correctly.  I realize
>> this can be done easily enough without using multiple instances.  Is
>> there a way to work around this so that an MX instance and submission
>> instance can share single IP address?  I've gotten used to the queue,
> 
> If you use different MTAs, then use different myhostname AND
> different inet_interfaces settings.  Otherwise it is just too easy
> to screw up and have a high-speed mail system meltdown/explosion/etc.
> 
> Postfix is not just about "secure" for some vague definition of
> secure, it is about making a safe to use, so that it does not rip
> off your arms and legs when you make a trivial mistake.
> 
>   Wietse


Fair enough.  I'll see what can be done about a second IP address.

-Mike

Re: Separate Submission Instance on Same IP as MX

[Mike Morris]

On 08/05/2010 11:57 AM, Jeroen Geilman wrote:
> On 08/01/2010 08:42 PM, Mike Morris wrote:
>> On 08/01/2010 02:37 AM, Jeroen Geilman wrote:
>>
>>> On 08/01/2010 04:11 AM, Mike Morris wrote:
>>>  
>>>> Hi,
>>>>
>>>> I'm working on a mail server deployment that will only have one server
>>>> for MX and SASL submission purposes.  Generally I like to have separate
>>>> Postfix instances to handle a specific task.
>>>>
>>> Why ?
>>> It's totally useless in this case.
>>> SMTP runs on port 25, and rejects anything not_invented_here.
>>> Submission runs on port 587, and requires SASL.
>>> Simple.
>>>  
>> I don't believe it is "totally useless" to use separate instances for
>> distinct services.
> 
> Certainly, and postfix supplies its fair share, as I explained above.
>>Configurations can get complex.  Outgoing mail may
>> be handled differently than incoming mail.
> 
> All mail comes in. all mail goes out.

I am aware that from the perspective of an MTA, all mail comes in and
all mail goes out.  However, from the perspective of an organization,
there may be differences between how mail coming in to, and sent from,
that organization is handled.

> 
>>   Using multiple instances can
>> simplify the task.  While it may not *work* in this case, using multiple
>> instances for MX and submission services is far from *useless*.
>>
> Instead of using multiple instances of postfix, why not use multiple 
> smtpd-listener instances, like we suggest ?

I've set up mail systems using both approaches.  It isn't always
possible to foresee what may be required in the future.  In the long run
it often is simpler to maintain the configurations of multiple instances
from the beginning rather than switch to such a setup after maintaining
a single instance becomes unwieldy.

I hadn't intended this to become a multiple- vs. single-instance debate.
 Each individual user can decide which approach best suits their
environment, and when one is preferred over the other.

Anyhow, in this particular case we were able to configure the server
with a second IP address.

>>>> mail_version = 2.8-20100707
>>>>
>>>>
>>> UNSTABLE.
>>> sheesh.
>>>
>>>  
>> Plenty of people would argue that Postfix experimental releases are
>> quite stable.  In this case I would like to test and make use of postscreen.
>>
> 
> Yes, postscreen is sexy... I think there are ways to get it to work with 
> 2.7, if you're prepared to overlay it onto a 2.7 build and fix what 
> breaks (if anything breaks, I know of at least one successful deployment).

I was wondering if this was going to be your response.  I find it
interesting that the person who shouted "UNSTABLE" in response to
someone using an experimental Postfix release would then suggest such an
approach.  Out of curiosity, what would your reasons be for suggesting
running postscreen with 2.7 rather than using a 2.8 snapshot?  Wouldn't
similar instability concerns about the latter apply to the former?

-Mike

Re: I think that thing smtpd_recipient_restrictions does not work

[Mike Morris]

On 01/21/2011 04:56 PM, Noel Jones wrote:
> On 1/21/2011 5:08 PM, Condor wrote:
>>
>> Hello,
>> i have postfix 2.7.2 and i have problem with restrictions. I setup
>> smtpd_recipient_restrictions here is my main.cf config file:
>>
>> smtpd_recipient_restrictions =
>>permit_mynetworks,
>>permit_sasl_authenticated,
>>check_helo_access hash:/etc/postfix/helo_checks,
>>check_sender_access hash:/etc/postfix/helo_checks,
>>check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
>>reject_unauth_destination,
>>reject_invalid_hostname,
>>reject_unauth_pipelining,
>>reject_non_fqdn_sender,
>>reject_unknown_sender_domain,
>>reject_non_fqdn_recipient,
>>reject_unknown_recipient_domain,
>>reject_unlisted_sender,
>>reject_rhsbl_client blackhole.securitysage.com,
>>reject_rhsbl_sender blackhole.securitysage.com,
>>reject_rbl_client relays.ordb.org,
>>reject_rbl_client blackholes.easynet.nl,
>>reject_rbl_client cbl.abuseat.org,
>>reject_rbl_client proxies.blackholes.wirehub.net,
>>reject_rbl_client bl.spamcop.net,
>>reject_rbl_client sbl.spamhaus.org,
>>reject_rbl_client opm.blitzed.org,
>>reject_rbl_client dnsbl.njabl.org,
>>reject_rbl_client list.dsbl.org,
>>reject_rbl_client multihop.dsbl.org,
>>reject_rbl_client pbl.spamhaus.org,
>>permit
>>
>> That file pcre:/etc/postfix/recipient_checks.pcre contain:
>> /^\@/   550 Invalid address format.
>> /[!%\@].*\@/550 This server disallows weird address syntax.
>> /^postmaster\@/ OK
>> /^hostmaster\@/ OK
>> /^abuse\@/  OK
>> /^nobody\@/ REJECT
> 
> Don't escape the @ in pcre tables. ie:
> /^nobody@/ REJECT  nobody isn't here.
> 

Additionally, doesn't this configuration make the server in question an
open relay?  The recipient_checks.pcre file returns an OK when the RHS
of an email address is anything for an LHS of postmater, hostmaster, and
abuse, and it immediately precedes reject_unauth_destination in
smtpd_recipient_restrictions.

What is the purpose of configuring recipient validation in such a
manner?  The OP would be better served by correctly configuring the
proper address classes.

-Mike

Re: I think that thing smtpd_recipient_restrictions does not work

[Mike Morris]

On 01/21/2011 05:25 PM, Noel Jones wrote:
> On 1/21/2011 7:13 PM, Mike Morris wrote:
>> On 01/21/2011 04:56 PM, Noel Jones wrote:
>>> On 1/21/2011 5:08 PM, Condor wrote:
>>>>
>>>> Hello,
>>>> i have postfix 2.7.2 and i have problem with restrictions. I setup
>>>> smtpd_recipient_restrictions here is my main.cf config file:
>>>>
>>>> smtpd_recipient_restrictions =
>>>> permit_mynetworks,
>>>> permit_sasl_authenticated,
>>>> check_helo_access hash:/etc/postfix/helo_checks,
>>>> check_sender_access hash:/etc/postfix/helo_checks,
>>>> check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
>>>> reject_unauth_destination,
>>>> reject_invalid_hostname,
>>>> reject_unauth_pipelining,
>>>> reject_non_fqdn_sender,
>>>> reject_unknown_sender_domain,
>>>> reject_non_fqdn_recipient,
>>>> reject_unknown_recipient_domain,
>>>> reject_unlisted_sender,
>>>> reject_rhsbl_client blackhole.securitysage.com,
>>>> reject_rhsbl_sender blackhole.securitysage.com,
>>>> reject_rbl_client relays.ordb.org,
>>>> reject_rbl_client blackholes.easynet.nl,
>>>> reject_rbl_client cbl.abuseat.org,
>>>> reject_rbl_client proxies.blackholes.wirehub.net,
>>>> reject_rbl_client bl.spamcop.net,
>>>> reject_rbl_client sbl.spamhaus.org,
>>>> reject_rbl_client opm.blitzed.org,
>>>> reject_rbl_client dnsbl.njabl.org,
>>>> reject_rbl_client list.dsbl.org,
>>>> reject_rbl_client multihop.dsbl.org,
>>>> reject_rbl_client pbl.spamhaus.org,
>>>> permit
>>>>
>>>> That file pcre:/etc/postfix/recipient_checks.pcre contain:
>>>> /^\@/   550 Invalid address format.
>>>> /[!%\@].*\@/550 This server disallows weird address syntax.
>>>> /^postmaster\@/ OK
>>>> /^hostmaster\@/ OK
>>>> /^abuse\@/  OK
>>>> /^nobody\@/ REJECT
>>>
>>> Don't escape the @ in pcre tables. ie:
>>> /^nobody@/ REJECT  nobody isn't here.
>>>
>>
>> Additionally, doesn't this configuration make the server in question an
>> open relay?  The recipient_checks.pcre file returns an OK when the RHS
>> of an email address is anything for an LHS of postmater, hostmaster, and
>> abuse, and it immediately precedes reject_unauth_destination in
>> smtpd_recipient_restrictions.
> 
> Yes, you're right.  reject_unauth_destination should be 
> directly after permit_mynetworks, permit_sasl_authenticated.
> 
>>
>> What is the purpose of configuring recipient validation in such a
>> manner?  The OP would be better served by correctly configuring the
>> proper address classes.
> 
> It's not uncommon to whitelist role accounts before anti-UCE 
> checks, 

Yeah, I realized why this might be useful after I sent my last response.
 Years ago I gave up and started subjecting role accounts to anti-UCE
rules, so I suppose such a purpose doesn't immediately register with me
any more.

-Mike

Re: I think that thing smtpd_recipient_restrictions does not work

[Mike Morris]

On 01/21/2011 11:20 PM, Condor wrote:
> 
>>
>> Does postconf smtpd_recipient_restrictions show the the same
>> as what you've posted above?
>>
> 
> Yes, i did not post it because i posted in previous email but here is it
> again:
> 
> # postconf smtpd_recipient_restrictions
> 
> smtpd_recipient_restrictions = permit_mynetworks, 
> permit_sasl_authenticated,  reject_unauth_destination,  check_helo_access
> hash:/etc/postfix/helo_checks,  check_sender_access
> hash:/etc/postfix/helo_checks,  check_recipient_access
> pcre:/etc/postfix/recipient_checks.pcre,  reject_invalid_hostname, 
> reject_unauth_pipelining,  reject_non_fqdn_sender, 
> reject_unknown_sender_domain,  reject_non_fqdn_recipient, 
> reject_unknown_recipient_domain,  reject_unlisted_sender, 
> reject_rhsbl_client dbl.spamhaus.org,  reject_rhsbl_sender
> dbl.spamhaus.org,  reject_rbl_client relays.ordb.org,  reject_rbl_client
> b.barracudacentral.org,  reject_rbl_client cbl.abuseat.org, 
> reject_rbl_client dyna.spamrats.com,  reject_rbl_client bl.spamcop.net, 
> reject_rbl_client zen.spamhaus.org,  reject_rbl_client opm.blitzed.org, 
> reject_rbl_client dnsbl.njabl.org,  reject_rbl_client dnsbl.sorbs.net, 
> reject_rbl_client db.wpbl.info,  permit
> 
> 
> I change my rbl lists and will see did they work, but this
> check_recipient_access pcre:/etc/postfix/recipient_checks.pcre still does
> not work. I change my file as you tell me:
> /^@/REJECT 550 Invalid address format.
> /[!%@].*@/  REJECT 550 This server disallows weird address syntax.
> /^postmaster@/  OK
> /^hostmaster@/  OK
> /^abuse@/   OK
> /^nobody@/  REJECT 550 User is unknow.
> 
> Reload postfix configuration once and after that i still can receive email
> to nobody mailbox.
> I can't find why isn't work. Any advice what i can do ? I change to
> check_recipient_access to hash:/etc/postix/block that contain
> nob...@my-domain.com REJECT Go away postmap and reload but again does not
> work. Server just pass the mail to nobody.
> 

What are the contents of the file /etc/postfix/helo_checks?  Your server
also does not reject on the restrictions reject_non_fqdn_sender,
reject_unknown_sender_domain, or reject_non_fqdn_recipient.  Something
is generating an 'OK' or 'permit' result prior to those checks.  Maybe
it's time you provided your current postconf -n output, as well as the
full contents of access maps you're using.

Also, replacing your 'OK' results in your access maps with
permit_auth_destination may be safer in case you accidentally move them
after reject_unauth_destination again in the future.

-Mike

relay_recipient and/or relay_domains issue

[Mike Loiterman]

I have two issues that I believe are connected so I'm putting them into one 
submission to the list:


ISSUE 1 

I want to forward root's mail to a local user called mike.  The user's email 
address is m...@ascendency.net and is a legitimate user on the system, but has 
a virtual mailbox.  I've added that email address in /etc/aliases and run the 
/usr/bin/newaliases command.  The problem I'm having is that root's email gets 
directed to m...@patton.ascendecny.net instead of m...@ascendency.net resulting 
in the following error:


Reason: Remote SMTP server has rejected address
Diagnostic code: smtp;554 5.7.1 : Relay 
access denied



ISSUE 2 

Messages sent to aliases that should point to legitimate email address on the 
server return the following error:

Remote host said: 550 5.1.1 <$aliasaddr...@ascendency.net>: Recipient 
address rejected: User unknown in relay recipient table




I believe both of these issues are related to my configuration of relay_domains 
and/or relay_recipient_maps.  Please see links below to links all relevant 
configuration files.



DOCUMENTATION REVIEWED

1.  http://www.postfix.org/ADDRESS_CLASS_README.html
2.  http://www.postfix.org/postconf.5.html#relay_recipient_maps



VERSIONS

1.  FreeBSD - 8.1-RELEASE
2.  PostFix - 2.7.2,1
3.  MySQL - 5.5.9
4.  Dovecot - 1.2.16



CONFIGURATION FILES

1.  postconf -n: http://pastebin.com/E0gMpmqf
2.  postconf -m: http://pastebin.com/hC7waDmY
3.  master.cf: http://pastebin.com/KcPTccCA
4.  mysql_virtual_alias_maps.cf: http://pastebin.com/guqFiMQA
5.  mysql_virtual_domains_maps.cf: http://pastebin.com/jV1iVEF8
6.  mysql_virtual_mailbox_maps.c: http://pastebin.com/UckJ2FQ9
7.  mysql_virtual_mailbox_limit_maps.cf: http://pastebin.com/6fkzV9eH
8.  mysql_relay_domains_maps.c: http://pastebin.com/TL3y5KwG



OTHER CONFIGURATION DETAILS (I have most of my configuration in mysql tables)

1.  Domain - ascendency.net
2.  Server name - patton 


--
Mike Loiterman
Email: m...@ascendency.net

Re: relay_recipient and/or relay_domains issue

[Mike Loiterman]

On Feb 15, 2011, at 3:45 PM, Jeroen Geilman wrote:

> On 02/15/2011 07:07 PM, Mike Loiterman wrote:
>> I have two issues that I believe are connected so I'm putting them into one 
>> submission to the list:
>> 
>> 
>> ISSUE 1
>> 
>> I want to forward root's mail to a local user called mike.  The user's email 
>> address is m...@ascendency.net and is a legitimate user on the system, but 
>> has a virtual mailbox.  I've added that email address in /etc/aliases and 
>> run the /usr/bin/newaliases command.  The problem I'm having is that root's 
>> email gets directed to m...@patton.ascendecny.net instead of 
>> m...@ascendency.net resulting in the following error:
>> 
>> 
>>  Reason: Remote SMTP server has rejected address
>>  Diagnostic code: smtp;554 5.7.1: Relay 
>> access denied
>> 
>> 
>> 
>> ISSUE 2
>> 
>> Messages sent to aliases that should point to legitimate email address on 
>> the server return the following error:
>> 
>>  Remote host said: 550 5.1.1<$aliasaddr...@ascendency.net>: Recipient 
>> address rejected: User unknown in relay recipient table
>> 
>> 
>> 
>> 
>> I believe both of these issues are related to my configuration of 
>> relay_domains and/or relay_recipient_maps.  Please see links below to links 
>> all relevant configuration files.
>> 
>> 
>> 
>> DOCUMENTATION REVIEWED
>> 
>> 1.  http://www.postfix.org/ADDRESS_CLASS_README.html
>> 2.  http://www.postfix.org/postconf.5.html#relay_recipient_maps
>> 
>> 
>> 
>> VERSIONS
>> 
>> 1.  FreeBSD - 8.1-RELEASE
>> 2.  PostFix - 2.7.2,1
>> 3.  MySQL - 5.5.9
>> 4.  Dovecot - 1.2.16
>> 
>> 
>> 
>> CONFIGURATION FILES
>> 
>> 1.  postconf -n: http://pastebin.com/E0gMpmqf
>> 2.  postconf -m: http://pastebin.com/hC7waDmY
>> 3.  master.cf: http://pastebin.com/KcPTccCA
>> 4.  mysql_virtual_alias_maps.cf: http://pastebin.com/guqFiMQA
>> 5.  mysql_virtual_domains_maps.cf: http://pastebin.com/jV1iVEF8
>> 6.  mysql_virtual_mailbox_maps.c: http://pastebin.com/UckJ2FQ9
>> 7.  mysql_virtual_mailbox_limit_maps.cf: http://pastebin.com/6fkzV9eH
>> 8.  mysql_relay_domains_maps.c: http://pastebin.com/TL3y5KwG
>> 
>> 
>> 
>> OTHER CONFIGURATION DETAILS (I have most of my configuration in mysql tables)
>> 
>> 1.  Domain - ascendency.net
>> 2.  Server name - patton
>> 
>> 
>> --
>> Mike Loiterman
>> Email: m...@ascendency.net
>> 
>>   
> 
> The nature of the error messages indicates that you have your address classes 
> mixed up.
> 
> Mydestination holds domains that will be delivered locally.
> These can be, but should not trivially be, aliased away to virtual addresses 
> - it is much simpler to reverse the function of the domains, or use the 
> proper masquerading or canonicalizing maps.
> 
> Likewise, virtual_mailbox_domains holds domains that will be delivered to the 
> virtual(8) delivery agent - or whatever you use as virtual_transport instead.
> 
> Relay_domains contains domains you want to accept mail for, but which you 
> will always send onwards.
> 
> 
> Now:
> 
> The problem I'm having is that root's email gets directed to 
> m...@patton.ascendecny.net instead of m...@ascendency.net
> 
> 
> How does it "get directed" ?
> 
> Presumably, you aliased root to m...@patton.net.
> 
> If, instead, you aliased root to "mike" - don't do that.
> 
> You should not use unqualified addresses on the RHS of an alias, unless you 
> know /exactly/ what the result will be.
> 
> http://www.postfix.org/postconf.5.html#myorigin
> 
> 
> 
> And:
> 
> Remote host said: 550 5.1.1<$aliasaddr...@ascendency.net>: Recipient address 
> rejected: User unknown in relay recipient table
> 
> 
> This has nothing to do with aliasing; note that it thinks the address in 
> question is present in *relay_domains*.
> 
> Make SURE that your domains occur in only one address class; specifying a 
> domain in multiple classes does not work.
> This may not be immediately apparent (to you or to postfix) when they are 
> buried in mysql maps.
> 
> (The contents of which would make this certain, instead of conjecture.)
> 
> -- 
> J.
> 

Issue number 1 was a problem with an upstream relay.  I have fixed since fixed 
my issue.  The problem was that the upstream relay was using recipient 
verification caching before it even got to my server.

Issue number 2 is still a problem for me.  Yes, I have aliased root to 
m...@ascendency.net.  

Here is the log of what happens:
http://pastebin.com/sXsyuMdH  

Re: relay_recipient and/or relay_domains issue

[Mike Loiterman]

On Feb 15, 2011, at 4:08 PM, Jeroen Geilman wrote:

> On 02/15/2011 10:56 PM, Mike Loiterman wrote:
>> On Feb 15, 2011, at 3:45 PM, Jeroen Geilman wrote:
>> 
>>   
>>> On 02/15/2011 07:07 PM, Mike Loiterman wrote:
>>> 
>>>> I have two issues that I believe are connected so I'm putting them into 
>>>> one submission to the list:
>>>> 
>>>> 
>>>> ISSUE 1
>>>> 
>>>> I want to forward root's mail to a local user called mike.  The user's 
>>>> email address is m...@ascendency.net and is a legitimate user on the 
>>>> system, but has a virtual mailbox.  I've added that email address in 
>>>> /etc/aliases and run the /usr/bin/newaliases command.  The problem I'm 
>>>> having is that root's email gets directed to m...@patton.ascendecny.net 
>>>> instead of m...@ascendency.net resulting in the following error:
>>>> 
>>>> 
>>>>Reason: Remote SMTP server has rejected address
>>>>Diagnostic code: smtp;554 5.7.1: Relay 
>>>> access denied
>>>> 
>>>> 
>>>> 
>>>> ISSUE 2
>>>> 
>>>> Messages sent to aliases that should point to legitimate email address on 
>>>> the server return the following error:
>>>> 
>>>>Remote host said: 550 5.1.1<$aliasaddr...@ascendency.net>: Recipient 
>>>> address rejected: User unknown in relay recipient table
>>>> 
>>>> 
>>>> 
>>>> 
>>>> I believe both of these issues are related to my configuration of 
>>>> relay_domains and/or relay_recipient_maps.  Please see links below to 
>>>> links all relevant configuration files.
>>>> 
>>>> 
>>>> 
>>>> DOCUMENTATION REVIEWED
>>>> 
>>>> 1.  http://www.postfix.org/ADDRESS_CLASS_README.html
>>>> 2.  http://www.postfix.org/postconf.5.html#relay_recipient_maps
>>>> 
>>>> 
>>>> 
>>>> VERSIONS
>>>> 
>>>> 1.  FreeBSD - 8.1-RELEASE
>>>> 2.  PostFix - 2.7.2,1
>>>> 3.  MySQL - 5.5.9
>>>> 4.  Dovecot - 1.2.16
>>>> 
>>>> 
>>>> 
>>>> CONFIGURATION FILES
>>>> 
>>>> 1.  postconf -n: http://pastebin.com/E0gMpmqf
>>>> 2.  postconf -m: http://pastebin.com/hC7waDmY
>>>> 3.  master.cf: http://pastebin.com/KcPTccCA
>>>> 4.  mysql_virtual_alias_maps.cf: http://pastebin.com/guqFiMQA
>>>> 5.  mysql_virtual_domains_maps.cf: http://pastebin.com/jV1iVEF8
>>>> 6.  mysql_virtual_mailbox_maps.c: http://pastebin.com/UckJ2FQ9
>>>> 7.  mysql_virtual_mailbox_limit_maps.cf: http://pastebin.com/6fkzV9eH
>>>> 8.  mysql_relay_domains_maps.c: http://pastebin.com/TL3y5KwG
>>>> 
>>>> 
>>>> 
>>>> OTHER CONFIGURATION DETAILS (I have most of my configuration in mysql 
>>>> tables)
>>>> 
>>>> 1.  Domain - ascendency.net
>>>> 2.  Server name - patton
>>>> 
>>>> 
>>>> --
>>>> Mike Loiterman
>>>> Email: m...@ascendency.net
>>>> 
>>>> 
>>>>   
>>> The nature of the error messages indicates that you have your address 
>>> classes mixed up.
>>> 
>>> Mydestination holds domains that will be delivered locally.
>>> These can be, but should not trivially be, aliased away to virtual 
>>> addresses - it is much simpler to reverse the function of the domains, or 
>>> use the proper masquerading or canonicalizing maps.
>>> 
>>> Likewise, virtual_mailbox_domains holds domains that will be delivered to 
>>> the virtual(8) delivery agent - or whatever you use as virtual_transport 
>>> instead.
>>> 
>>> Relay_domains contains domains you want to accept mail for, but which you 
>>> will always send onwards.
>>> 
>>> 
>>> Now:
>>> 
>>> The problem I'm having is that root's email gets directed to 
>>> m...@patton.ascendecny.net instead of m...@ascendency.net
>>> 
>>> 
>>> How does it "get directed" ?
>>> 
>>

Re: postscreen test

[Mike Cappella]

On 7/13/09 5:20 PM, Wietse Venema wrote:
>
> I'm still open for program name suggestions. If someone has a better
> name than "swatter" or "halligan" let me know. Once the name changes,
> all the configuration parameters will change, too.

   posttriage

or if you have issues w/the French:

   postcull
   postreject
   postdiscard

---
Mike

Re: postscreen test

[Mike Cappella]

On 7/16/09 1:01 PM, Victor Duchovni wrote:


The service is an SMTP "bouncer", keeping unwanted clients from entering
the premises. We already have a "bounce unix" service, will having:

 smtp  inet  n   -   n   -   1   bouncer
 ...
 bounceunix  -   -   n   -   0   bounce

cause significant confusion?



While I like the name, please no.  Postfix support lists have had to 
call attention to "smtp" v. "smtpd" enough.



On 7/16/09 1:10 PM, Wietse Venema wrote:
> It's no worse than smtp versus smtpd. If there exists a different

By itself, it is not.  I'd suggest that increasing the number of support 
questions for little gain is not prudent.  Uniquely distinct names have 
value.


my 2c.

---
Mike

Re: postscreen test

[Mike Cappella]

On 7/16/09 6:02 PM, Noel Jones wrote:


postquack (like water off a ducks back)

But I can't beat prefix.



I like prefix too; that Ralf is very clever. postfix/postprefix might 
twist one's mind.


Or, go biblical: postsmite.  ;-)

Good fun.

Re: postscreen test

[Mike Morris]

On 07/17/2009 05:30 AM, José Luis Tallón wrote:
> Patrick Ben Koetter wrote:
>> * Wietse Venema :
>>   
>>> Victor Duchovni:
>>> 
>>>> On Thu, Jul 16, 2009 at 05:21:13PM -0400, Rob Foehl wrote:
>>>>
>>>>   
>>>>> Possible substitutes include concierge or valet, or perhaps any of the 
>>>>> less 
>>>>> specific guard, sentry, sentinel, ...
>>>>> 
>>>> I think "sentry" is short, and simple, and can even be thought of as a
>>>> contraction of "smtp" and "entry". A bit less corny than "prefix" IMHO
>>>> (sorry Patrick, nothing personal).
>>>>   
>>> "sentry" is good. 
>>>
>>> In a similar class is "triage", which I mention in the postscreen
>>> manpage at http://www.postfix.org/postscreen.8.html
>>> 
>> Two more names:
>>
>>   refuse
>>   drop(down)
>>
>>
>> I am very much in favor of greek or latin mythology, but I think prefix and
>> both words above are more in the tradition of describing what the program 
>> does
>> e.g.  pickup, cleanup, tlsmgr etc. which I actually like very much about
>> Postfix naming convention.
>>   
> "screener", then.
> Oh, wait ...
> 
> 
> but then, there is also "anvil"
> 
> J.L.
> 

"Anvil" is a name I always liked for a Postfix daemon, and I was also
thinking that building on that theme would be a good idea.  However, I'm
not clever enough to come up with an example.  "Vise" was all that I
could come up with.

-Mike

Re: allow sasl authenticated on submission port and bypass rbl

[Mike Cappella]

On 8/3/09 12:26 AM, Nick Sharp wrote:

Hi all,

Since adding check_sender_access to stop our domain from emailing unauthed
from the outside and our Wireless Broadband now being in the
pbl.spamhaus.org list, we want to allow TLS/SASL Auth'd users to email from
their broadband cards and get them bypassing the rbl's, ie RBL checks on
port 25 without auth, no rbl checks on 587 but reject those not
authenticated.

I thought I could just overwrite smtpd restrictions from main.cf with
additional rules in master.cf and get it working, but all combinations I
have tried have failed.


A sample submission entry in master.cf:

submission inet n   -   n   -   -   smtpd
   -o smtpd_tls_security_level=encrypt
   -o smtpd_tls_auth_only=yes
   -o smtpd_sasl_auth_enable=yes
   -o broken_sasl_auth_clients=yes
   -o receive_override_options=no_header_body_checks,no_address_mappings
   -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
   -o content_filter=lmtp-amavis:[127.0.0.1]:10026

The key is the smtpd_recipient_restrictions' permit_sasl_authenticated 
coming first or early.  Thus, port 587 users who authenticate pass the 
green light.





Do I have to move main.cf smtpd_(client|recipient|sender)_restrictions into
master.cf under smtp and then use the alternative restrictions under the
submission port? If so I wonder what else will loose restriction options.


Tailor as you see fit for your users.  The restrictions you'll add under 
submission overrides those in main.cf.




I am pretty sure that I can whitelist their subnet, but I must be able to
bypass the rbl checks for any auth'ed user on port 587.


Whitelisting == not so good.



Any suggestions gratefully received.

The error I seem to get if its not the rbl error;
Aug  3 15:39:14 mail1 postfix/smtpd[25528]: NOQUEUE: reject: CONNECT from
unknown[58.171.177.107]: 554 5.7.1: Client host
rejected: Access denied; proto=SMTP

Re: HELO/EHLO rejection rate

[Mike Cappella]

On 8/17/09 12:43 PM, Michael Orlitzky wrote:

LuKreme wrote:

I looked at the various rejections for the last 31 days, and I noticed
that my unknown/HELO is very very high and my RBL is very very low.

5xx Reject relay denied 0.08%
5xx Reject HELO/EHLO 45.97%
5xx Reject DATA 0.01%
5xx Reject unknown user 47.47%
5xx Reject recipient address 0.00%
5xx Reject sender address 0.11%
5xx Reject client host 1.07%
5xx Reject RBL 5.29%
5xx Reject header 0.01%
--
Total 5xx Rejects 100.00%

looking at some other stats I've been able to find, I am seeing
numbers more like 20/1/70 where I have 46/47/5


What version of postfix-logwatch is this? A quick check of the ChangeLog
suggests that versions prior to 2007-02-14 might not distinguish
warn_if_reject messages from true reject messages.



The "5xx Reject" format of the output above was implemented in version 
1.36.13pre5:


2007-11-14 (version: 1.36.13pre5)

 - New: Rejects can now be categorized by reject reply code.  A new
   option/variable "reject_reply_patterns" is a list of reject reply
   code regular expressions, which are used for categorizing rejects.
   This feature allows, for example, distinguishing 421 transmission
   channel closes from 45x errors. (eg. 450 mailbox unavailable, 451
   local processing errors, 452 insufficient storage).  The default
   list is: "5.. 4.. Warn" which creates three groups of rejects:
   permanent rejects, temporary failures, and reject warnings (as in
   warn_if_reject).  Requested by: Noel Jones

so there is no doubt that warn_if_reject's would appear in a separate 
section (as would 4xx temp rejects, also not shown).



Since you include,

warn_if_reject reject_unknown_client_hostname


The OP didn't show any Warn Reject sections, so we can't infer when any 
warn_if_reject was appended to reject_unknown_client_hostname.  All we 
can infer is that there were some 5xx reject_unknown_client_hostname's 
in the log for the period analyzed.




in your smtpd_recipient_restrictions, that could explain the difference
you're seeing.


If the OPs question was about why the apparent discrepancy between 
postfix-logwatch and the "other stats" generated from the unmentioned 
stats tools, who can say without more data.  Perhaps a representative 
sample of log lines and direct comparison against the other tools would 
help clarify any confusion.


--
Mike

Re: error message

[Mike Cappella]

On 9/11/09 4:48 PM, ghe wrote:

I don't understand this line from today's logwatch report:

308 *Warning: Database file needs update



This message appears when you have a map file that requires postmap'ing 
to bring the db file up to date relative to the source file.  Look at 
the log messages to see which file is not up to date and run postmap on 
that file.




I looked and didn't find it in the mail logs, but logwatch is saying it
was found 308 times. Google led me to a number of pages that denied me
access and a CVS server that didn't make sense. Anybody understand this
message?

If it's postfix, which database needs updating, and how do I do it? If
it's logwatch, please tell me, and I apologize for wasting your time...



--
Mike

Re: error message

[Mike Cappella]

On 9/11/09 5:05 PM, ghe wrote:


On Sep 11, 2009, at 5:51 PM, Mike Cappella wrote:


I don't understand this line from today's logwatch report:

308 *Warning: Database file needs update



This message appears when you have a map file that requires
postmap'ing to bring the db file up to date relative to the source
file. Look at the log messages to see which file is not up to date and
run postmap on that file.


Thank's Mike. I found a mention of virtual with google, but since I
couldn't find the message in /var/log/mail*, I couldn't figure it out.



Its in the report at detail >= 5:

$ grep 'older than source' maillog  | tail | \
postfix-logwatch --detail 5 --max_report_width=70
** Summary ***

  10   *Warning: Database file needs update

** Detail (10) ***

  10   *Warning: Database file needs update --
   9  /etc/postfix/virtual
   1  /etc/postfix/transport



Also since I didn't find it, I just re-postmapped 'em all.



No need.  The file is indicated in the log and via postfix-logwatch (or 
logwatch w/detail >= 5).


Consider using a Makefile to keep source up to date, so that you can 
just run "make" w/o thinking about which file needs updating.


--
Mike