Encrypted connection from mta to mta?
Hello, I was asking myself about the kind of connection used by a MTA to contact another one. For exemple, I know that we can setup in a MUA an SSL (or TLS) connection when configuring the SMTP connection. So the connection between the MUA and the MTA is encrypted. But can we configure postfix in some way to ask by default an encrypted connection when sending mail to others MTA? Or maybe it already do it by default? So we may have something like that : MUA --- MTA --- MTA MUA encryptedencryptedencrypted I know we can't guarantee that the entire flow will be encrypted because we only have control on our MTA. But is it possible? Thank you,
Re: Encrypted connection from mta to mta?
Encrypting emails would be simplier ( gpg or pgp ) Le 25/02/2011 09:02, Nicolas Michel a écrit : Hello, I was asking myself about the kind of connection used by a MTA to contact another one. For exemple, I know that we can setup in a MUA an SSL (or TLS) connection when configuring the SMTP connection. So the connection between the MUA and the MTA is encrypted. But can we configure postfix in some way to ask by default an encrypted connection when sending mail to others MTA? Or maybe it already do it by default? So we may have something like that : MUA --- MTA --- MTA MUA encrypted encrypted encrypted I know we can't guarantee that the entire flow will be encrypted because we only have control on our MTA. But is it possible? Thank you,
Re: Encrypted connection from mta to mta?
On Fri, Feb 25, 2011 at 09:11:11AM +0100, Frank Bonnet wrote: Encrypting emails would be simplier ( gpg or pgp ) No, it would not. I know we can't guarantee that the entire flow will be encrypted because we only have control on our MTA. But is it possible? http://www.postfix.org/TLS_README.html -- Viktor.
Re: Encrypted connection from mta to mta?
On 02/25/2011 09:02 AM, Nicolas Michel wrote: Hello, I was asking myself about the kind of connection used by a MTA to contact another one. For exemple, I know that we can setup in a MUA an SSL (or TLS) connection when configuring the SMTP connection. So the connection between the MUA and the MTA is encrypted. But can we configure postfix in some way to ask by default an encrypted connection when sending mail to others MTA? Or maybe it already do it by default? So we may have something like that : MUA --- MTA --- MTA MUA encryptedencryptedencrypted I know we can't guarantee that the entire flow will be encrypted because we only have control on our MTA. But is it possible? If the other MTAs are not under your control, you cannot enforce TLS between the other MTAs. You can only enforce TLS between the MTA you control and first MTA it connects to. After that you are no longer in control. Kind regards, Martijn Brinkers
Re: Encrypted connection from mta to mta?
On Fri, Feb 25, 2011 at 09:27:36AM +0100, martijn.list wrote: But is it possible? If the other MTAs are not under your control, you cannot enforce TLS between the other MTAs. You can only enforce TLS between the MTA you control and first MTA it connects to. After that you are no longer in control. The OP only wanted to use TLS when possible. http://www.postfix.org/TLS_README.html#client_tls_may -- Viktor.
sender_canonical_maps not matching
Hello, we are trying to solve a mail problem on the New Zealand Red Cross mail server, which is sending confirmation messages for earthquake donations from an invalid address, e.g. postfix/smtp[26060]: 44B9C100CA13: to=madd...@madduck.net, relay=b.mx.madduck.net[213.203.238.82]:25, delay=10, delays=0.01/0/6.8/3.3, dsn=4.1.8, status=deferred (host b.mx.madduck.net[213.203.238.82] said: 450 4.1.8 www-d...@rredxprdww02.netspace.net.nz: Sender address rejected: Domain not found (in reply to RCPT TO command)) I wanted to approach this using a canonical rewriting map: root@redxprdww02:/etc/postfix# grep sender_rewrite main.cf sender_canonical_maps = hash:/etc/postfix/sender_rewrite root@redxprdww02:/etc/postfix# cat sender_rewrite www-d...@redxprdww02.netspace.net.nz www-d...@redcross.org.nz www-d...@netspace.net.nz www-d...@redcross.org.nz root@redxprdww02:/etc/postfix# postconf local_header_rewrite_clients local_header_rewrite_clients = permit_inet_interfaces root@redxprdww02:/etc/postfix# postconf inet_interfaces inet_interfaces = all Unfortunately, this seems to have no effect: messages submitted to localhost:25 or via sendmail do not get their senders rewritten. What am I missing? masquerade_domains works, btw, but that yields @netspace.net.nz when we want @redcross.net.nz. Also, canonical mapping should happen before domains are masqueraded (http://www.postfix.org/ADDRESS_REWRITING_README.html#overview). Thanks, Martin PS: the easy solution would be to add a DNS record, but admins in .nz are now asleep and I'd prefer to solve this within the next 12 hours. -- martin | http://madduck.net/ | http://two.sentenc.es/ durch frauen werden die höhepunkte des lebens bereichert und die tiefpunkte vermehrt. - friedrich nietzsche spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: sender_canonical_maps not matching
On Fri, Feb 25, 2011 at 09:35:20AM +0100, martin f krafft wrote: we are trying to solve a mail problem on the New Zealand Red Cross mail server, which is sending confirmation messages for earthquake donations from an invalid address, e.g. postfix/smtp[26060]: 44B9C100CA13: to=madd...@madduck.net, relay=b.mx.madduck.net[213.203.238.82]:25, delay=10, delays=0.01/0/6.8/3.3, dsn=4.1.8, status=deferred (host b.mx.madduck.net[213.203.238.82] said: 450 4.1.8 www-d...@rredxprdww02.netspace.net.nz: Sender address rejected: Domain not found (in reply to RCPT TO command)) I wanted to approach this using a canonical rewriting map: Why not just set myorigin correctly? root@redxprdww02:/etc/postfix# grep sender_rewrite main.cf sender_canonical_maps = hash:/etc/postfix/sender_rewrite Don't waste time with sender_canonical_maps, use either canonical_maps or smtp_generic_maps if setting myorigin to the desired domain is not an option. -- Viktor.
Re: sender_canonical_maps not matching
also sprach martin f krafft madd...@madduck.net [2011.02.25.0935 +0100]: root@redxprdww02:/etc/postfix# cat sender_rewrite www-d...@redxprdww02.netspace.net.nz www-d...@redcross.org.nz www-d...@netspace.net.nz www-d...@redcross.org.nz (yes, I did run postmap) -- martin | http://madduck.net/ | http://two.sentenc.es/ if they can get you asking the wrong questions, they don't have to worry about answers. -- thomas pynchon spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: sender_canonical_maps not matching
also sprach martin f krafft madd...@madduck.net [2011.02.25.0935 +0100]: root@redxprdww02:/etc/postfix# cat sender_rewrite www-d...@redxprdww02.netspace.net.nz www-d...@redcross.org.nz Thanks to freenode staffer Tabmow: there was an 'r' missing after the '@' symbol. Sorry for the noise. -- martin | http://madduck.net/ | http://two.sentenc.es/ it is only the modern that ever becomes old-fashioned. -- oscar wilde spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: sender_canonical_maps not matching
also sprach Victor Duchovni victor.ducho...@morganstanley.com [2011.02.25.0944 +0100]: I wanted to approach this using a canonical rewriting map: Why not just set myorigin correctly? I did not want to make such potentially far-reaching modifications to a server that I did not set up nor control. I was only an emergency admin. root@redxprdww02:/etc/postfix# grep sender_rewrite main.cf sender_canonical_maps = hash:/etc/postfix/sender_rewrite Don't waste time with sender_canonical_maps, use either canonical_maps or smtp_generic_maps if setting myorigin to the desired domain is not an option. Interesting. smtp_generic_maps would have been my next step. Why do you advocate using canonical_maps over sender_canonical_maps? And is smtp_generic_maps preferred over *canonical_maps? Thanks, -- martin | http://madduck.net/ | http://two.sentenc.es/ never eat more than you can lift. -- miss piggy spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: Starting postfix
Zitat von Victor Duchovni victor.ducho...@morganstanley.com: On Fri, Feb 25, 2011 at 12:58:22AM +0100, Christian Roessner wrote: I am currently preparing an upstart script for Ubuntu. I tried several ways do use /usr/sbin/postfix, but I never would get the master PID. So I looked at the postfix.c code. There is a no single master pid. A fully-general Postfix MTA may run multiple master instances. Postfix startup is not just a fork/exec of master(8), queue files that got renamed (perhaps restored) have to be recovered via postsuper -s. Required missing directories have to be created. Basic security checks performed, all this for multiple instances. Don't run Postfix on laptops, something much simpler that drains a disk queue to a fixed SMTP smart-host is likely best for consumer machines. Do run Postfix on servers, but be prepared to not break advanced configurations, and let Postfix do its own startup and shutdown. Attempts to monitor the status of a complex multi-component Postfix MTA---as though it were a monolithic system that is either entirely up or entirely down---based on observations of a single process are likely to fail. It would be better to not monitor at all than to do it badly. I monitor Postfix by sending messages and observing their arrival or non-arrival at a monitoring sink. Automated re-start is not that interesting, the master service never crashes (not once in the last 10 years of running multiple hosts doing 2,000,000 messages a day). Automated re-start of the Postfix master(8) service is a non-problem. The problem is more of that distribution like Ubuntu and Redhat are moving to upstart for boot and starting services/daemons. The main difference for the started services is that upstart need the program to *not* daemonize or terminate itself because status is checked directly to do respawn and other things if necessary and not by monitoring a PID like it was with sys-v. So basically to get Postfix upstart compatibel a postfix-start-stop helper would be needed which is always running and only does dispatching of start/stop requests to the master(s) according to Postfix needs. Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
[PATCH] postfix won't build on FREEBSD 7.2+
This problem exist in the 2.7 and 2.8 branch: In file included from attr_clnt.c:77: /usr/include/unistd.h:329: error: conflicting types for 'closefrom' ./sys_defs.h:1399: error: previous declaration of 'closefrom' was here *** Error code 1 Stop in /home/src/postfix-2.7.2/src/util. *** Error code 1 Stop in /home/src/postfix-2.7.2. Fix: src/util/sys_defs.h 114c114 #if (__FreeBSD_version = 702104 __FreeBSD_version 80) || (__Fversion = 800099) /* safe; don't believe the experts */ --- #if __FreeBSD_version = 800107 /* safe; don't believe thts */ based on: 702104 July 14, 2009 7.2-STABLE after MFC of the closefrom system call. Ref: http://www.freebsd.org/doc/en/books/porters-handbook/freebsd-versions.html I can't find the bugreport website for postfix so I do it through this channel. Kind regards Kristof Vansant
ESMTP extension (was: Re: Encrypted connection from mta to mta?)
This gave me an idea: what do people think about an ESMTP extension that enforces TLS? MTA1 -- MTA2 - MTA3 TLS TLS with the idea of having an X-header that basically says do not forward if no TLS available so MTA1 sends to MTA2 encrypted. MTA2 reads that header and says EHLO to MTA3. If MTA3 does not reply with TLS, MTA2 retunrs an NDR to MTA1 with could not deliver, TLS not available. The big problem that I see is backward compatibility - one would need a ehlo flag that signifies this capability in order to enable MTA1 not to send to MTA2 if MTA2 was not able to recognize the header. cheers Bernhard original message- From: martijn.list martijn.l...@gmail.com To: postfix-users@postfix.org Date: Fri, 25 Feb 2011 09:27:36 +0100 - On 02/25/2011 09:02 AM, Nicolas Michel wrote: Hello, I was asking myself about the kind of connection used by a MTA to contact another one. For exemple, I know that we can setup in a MUA an SSL (or TLS) connection when configuring the SMTP connection. So the connection between the MUA and the MTA is encrypted. But can we configure postfix in some way to ask by default an encrypted connection when sending mail to others MTA? Or maybe it already do it by default? So we may have something like that : MUA --- MTA --- MTA MUA encrypted encrypted encrypted I know we can't guarantee that the entire flow will be encrypted because we only have control on our MTA. But is it possible? If the other MTAs are not under your control, you cannot enforce TLS between the other MTAs. You can only enforce TLS between the MTA you control and first MTA it connects to. After that you are no longer in control. Kind regards, Martijn Brinkers -- - Bernhard Rohrer Consulting 529 Howth Road Dublin 5, Ireland +353 87 7907 134
Re: Starting postfix
Hi, The problem is more of that distribution like Ubuntu and Redhat are moving to upstart for boot and starting services/daemons. The main difference for the started services is that upstart need the program to *not* daemonize or terminate itself because status is checked directly to do respawn and other things if necessary and not by monitoring a PID like it was with sys-v. So basically to get Postfix upstart compatibel a postfix-start-stop helper would be needed which is always running and only does dispatching of start/stop requests to the master(s) according to Postfix needs. I was thinking the whole night how to solve it for upstart. I wrote a python wrapper: # import os, sys import time program = /usr/sbin/postfix # First start postfix and wait for the return code try: pid = os.fork() except OSError, e: Log.error(First fork failed) print sys.stderr, (Fork failed: (%d) %s % (e.errno, e.strerror)) sys.exit(1) if not pid: try: os.execvp(program, (program, start)) except OSError, e: print sys.stderr, (Exec failed: (%d) %s % (e.errno, e.strerror)) os._exit(1) if os.wait()[1] != 0: sys.exit(1) # wait until we get killed while True: time.sleep(10) # This can be called with exec in upstart and doing a stop is easy, too, because I simply call /usr/sbin/postfix stop in a post-stop script block. So if this is okay, I would use it. It is some kind of silly, but I tested it here on my workstation and it does the job. But I also want to ask the Ubuntu guys, if that is a working mechanism. Thanks Christian -- Roessner-Network-Solutions Bachelor of Science Informatik Nahrungsberg 81, 35390 Gießen F: +49 641 5879091, M: +49 176 93118939 USt-IdNr.: DE225643613 http://www.roessner-network-solutions.com
Re: ESMTP extension (was: Re: Encrypted connection from mta to mta?)
Zitat von Bernhard Rohrer grayl...@sm-wg.net: This gave me an idea: what do people think about an ESMTP extension that enforces TLS? MTA1 -- MTA2 - MTA3 TLS TLS with the idea of having an X-header that basically says do not forward if no TLS available so MTA1 sends to MTA2 encrypted. MTA2 reads that header and says EHLO to MTA3. If MTA3 does not reply with TLS, MTA2 retunrs an NDR to MTA1 with could not deliver, TLS not available. The big problem that I see is backward compatibility - one would need a ehlo flag that signifies this capability in order to enable MTA1 not to send to MTA2 if MTA2 was not able to recognize the header. This does not add any benefit or security. There is no way for the sender to see if the receiving MTA is lying and ditch the header or does nothing with it at all. If you need secure/authenticated e-mail have a look at S/MIME and PGP for example at http://www.postfix.org/addon.html#security-gateway. Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] postfix won't build on FREEBSD 7.2+
Am 25.02.2011 10:50, schrieb kristof.vans...@telenet.be: This problem exist in the 2.7 and 2.8 branch: In file included from attr_clnt.c:77: /usr/include/unistd.h:329: error: conflicting types for 'closefrom' ./sys_defs.h:1399: error: previous declaration of 'closefrom' was here *** Error code 1 Stop in /home/src/postfix-2.7.2/src/util. *** Error code 1 Stop in /home/src/postfix-2.7.2. Fix: src/util/sys_defs.h 114c114 #if (__FreeBSD_version = 702104 __FreeBSD_version 80) || (__Fversion = 800099) /* safe; don't believe the experts */ --- #if __FreeBSD_version = 800107 /* safe; don't believe thts */ Hi Kristof, dank je wel et merci. The fix per se looks sane to me, but the patch doesn't apply to 2.8.1. patch: Only garbage was found in the patch input. Could you please re-diff: - in the proper direction (you had swapped unpatched and patched) - in unified or context format (-c or -u option) - without truncating lines. As to the latter, *attach* the patch, so as to keep whitespace intact. Copy paste doesn't work well for patches, so (you may need other diff options such as -r depending on whether you diff from the top-level directory of a copy of the tree) diff -c UNPATCHED PATCHED somefile # then, send mail and attach somefile (I think I recall Wietse prefers context format.) Best regards Matthias
Re: Starting postfix
lst_ho...@kwsoft.de: The problem is more of that distribution like Ubuntu and Redhat are moving to upstart for boot and starting services/daemons. The main difference for the started services is that upstart need the program to *not* daemonize or terminate itself because status is checked directly to do respawn and other things if necessary and not by monitoring a PID like it was with sys-v. So basically to get Postfix upstart compatibel a postfix-start-stop helper would be needed which is always running and only does dispatching of start/stop requests to the master(s) according to Postfix needs. The problem with this approach is that Postfix is not one program, like named, apache, etc., and that simply starting one master daemon is insufficient as it skips all the start-up repair and sanity checks. Wietse
Re: Starting postfix
Zitat von Wietse Venema wie...@porcupine.org: lst_ho...@kwsoft.de: The problem is more of that distribution like Ubuntu and Redhat are moving to upstart for boot and starting services/daemons. The main difference for the started services is that upstart need the program to *not* daemonize or terminate itself because status is checked directly to do respawn and other things if necessary and not by monitoring a PID like it was with sys-v. So basically to get Postfix upstart compatibel a postfix-start-stop helper would be needed which is always running and only does dispatching of start/stop requests to the master(s) according to Postfix needs. The problem with this approach is that Postfix is not one program, like named, apache, etc., and that simply starting one master daemon is insufficient as it skips all the start-up repair and sanity checks. That's why i said it may be useful to have a simple dispatcher/wrapper which only is started to call postfix start and keeps running to keep upstart happy and calls postfix stop/restart when advised to do so by upstart. With this the supported way of starting/stopping is possible *and* upstart could be used without problems. The only problem to solve is the non-terminating behaviour required by upstart, all other startup work can be done as usual behind the scene. Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: Starting postfix
Hi, That's why i said it may be useful to have a simple dispatcher/wrapper which only is started to call postfix start and keeps running to keep upstart happy and calls postfix stop/restart when advised to do so by upstart. With this the supported way of starting/stopping is possible *and* upstart could be used without problems. The only problem to solve is the non-terminating behaviour required by upstart, all other startup work can be done as usual behind the scene. my upstart-postfix python script works. It does call /usr/sbin/postfix start and loops. So this is a very simple form of making upstart happy and also starting/stopping postfix as expected. That postfix must not be started directly by calling master should also be documented in the master man page, as people like me (and my idea was based on Apple's practise, like they DO START postfix with launchctl on Mac OS X Server edition). Anyways. If someone likes to help me doing further coding on the python code, he/she is welcome. @Andreas: Du bist doch aus Deutschland? Kannst mich gerne mal anschreiben; vielleicht finden wir beide eine gute Lösung. Danke Best wishes Christian -- Roessner-Network-Solutions Bachelor of Science Informatik Nahrungsberg 81, 35390 Gießen F: +49 641 5879091, M: +49 176 93118939 USt-IdNr.: DE225643613 http://www.roessner-network-solutions.com
Re: Starting postfix
Wietse Venema: lst_ho...@kwsoft.de: Zitat von Wietse Venema wie...@porcupine.org: lst_ho...@kwsoft.de: The problem is more of that distribution like Ubuntu and Redhat are moving to upstart for boot and starting services/daemons. The main difference for the started services is that upstart need the program Is there any reason they can't do this: Postfix job script: pre-start exec postfix start post-stop exec postfix stop With this, the system will do the work for them, and everything uses stable documented interfaces. Wietse
Re: Starting postfix
Zitat von Wietse Venema wie...@porcupine.org:
Wietse Venema:
lst_ho...@kwsoft.de:
Zitat von Wietse Venema wie...@porcupine.org:
lst_ho...@kwsoft.de:
The problem is more of that distribution like Ubuntu and Redhat are
moving to upstart for boot and starting services/daemons. The main
difference for the started services is that upstart need the program
Is there any reason they can't do this:
Postfix job script:
pre-start exec postfix start
post-stop exec postfix stop
With this, the system will do the work for them, and everything
uses stable documented interfaces.
I'm just on the way learning the new concepts of upstart...
As far as i understand the common way is to not detach as it is done
in the common way but run in foreground to keep contact with upstart
(init) so status can be easily collected. It should be possible to
fire only a startup script and terminate but with this the daemon
listing (initctl list) would show status waiting instead of running.
A simple startup config for sshd taken from Ubuntu 10.04 is for example:
# ssh - OpenBSD Secure Shell server
#
# The OpenSSH server provides secure shell access to the system.
description OpenSSH server
start on filesystem
stop on runlevel S
respawn
respawn limit 10 5
umask 022
# replaces SSHD_OOM_ADJUST in /etc/default/ssh
oom never
pre-start script
test -x /usr/sbin/sshd || { stop; exit 0; }
test -e /etc/ssh/sshd_not_to_be_run { stop; exit 0; }
test -c /dev/null || { stop; exit 0; }
mkdir -p -m0755 /var/run/sshd
end script
# if you used to set SSHD_OPTS in /etc/default/ssh, you can change the
# 'exec' line here instead
exec /usr/sbin/sshd -D
Regards
Andreas
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Starting postfix
On Fri, Feb 25, 2011 at 03:08:51PM +0100, lst_ho...@kwsoft.de wrote: [...] Is there any reason they can't do this: Postfix job script: pre-start exec postfix start post-stop exec postfix stop With this, the system will do the work for them, and everything uses stable documented interfaces. I'm just on the way learning the new concepts of upstart... As far as i understand the common way is to not detach as it is done in the common way but run in foreground to keep contact with upstart (init) so status can be easily collected. It should be possible to fire only a startup script and terminate but with this the daemon listing (initctl list) would show status waiting instead of running. I'm just thinking how Solaris 10's SMF can solve this. As far as I noticed, it somehow keeps track on children too, so if the start method only does something then exits, it still knows that the service is running since there is child(ren) process(es) of the start method in the system. I am not sure however, but as far as I remember/experienced. Upstart may does not have this feature however ... -- Gábor
Re: Starting postfix
On 2/25/2011 8:16 AM, Wietse Venema wrote: The problem with this approach is that Postfix is not one program, like named, apache, etc., and that simply starting one master daemon is insufficient as it skips all the start-up repair and sanity checks. That's why i said it may be useful to have a simple dispatcher/wrapper which only is started to call postfix start and keeps running to keep upstart happy and calls postfix stop/restart when advised to do so by upstart. With this the supported way of starting/stopping is possible *and* upstart could be used without problems. The only problem to solve is the non-terminating behaviour required by upstart, all other startup work can be done as usual behind the scene. I suppose you mean something like this: postfix upstart Run in upstart pacifier mode, and do not terminate. Execute the equivalents of postfix start and postfix stop as appropriate, and do nothing in the mean time. Just using up an idle process slot to keep upstart happy. Wietse Wietse Since Upstart is new to me I decided to read about it: [The shortcomings of sysvinit] leaves it unable to handle various tasks on a moderndesktop computer http://en.wikipedia.org/wiki/Desktop_computerelegantly, including: The addition or removal ofUSB pen drives http://en.wikipedia.org/wiki/USB_pen_driveand other portable storage / network devices while the machine is running... (Wikipedia) 'As the primary focus of this specification is dealing with modern hardware and its coming and going nature' (Ubuntu) So the meta-issue appears to be a collision in design between typical desktop and server design models. Sort of. Desktops still have long running services too that should never go awry (wording from Fedora upstart doc page). The (*flame retardant leggings put on*) Windows service model seems much better, wherein each service must implement a defined start/stop interface. Any service management tool doesn't need a tight grip on a collection of child processes, just uses this simple interface. Breaking the daemonization model is just odd to me. In any case the upstart page makes it clear that it will be backward-compatible with sysv for a while during this transition, so there doesn't seem to be any rush. Perhaps someone can advocate for a true service model in the meantime for things that *don't* change and *should definitely* happen right at boot? -Daniel
Re: Update Postfix transport file on multiple servers
Hello, Le 24 févr. 2011 à 23:18, Luis Esteves a écrit : Hi everybody, In our organisation we have 4 postfix servers. Each time i need to add a new configuration to the transport file (for a new domain), i need to update the transport file on each server. This is cumbersome. Connect on each server with ssh, update the transport file, et run make to generate a db file. Is there an easy way to update all files on each server easily (without generating ssh public/private keys and running these commands from one server) ? Is it a good idea to use a centralized PostgreSQL database to store the Postfix configuration files ? There is things like : - puppet - cfengine - chef that can do that for you This is what I use. Xavier
Re: Starting postfix
lst_ho...@kwsoft.de: Zitat von Wietse Venema wie...@porcupine.org: Wietse Venema: lst_ho...@kwsoft.de: Zitat von Wietse Venema wie...@porcupine.org: lst_ho...@kwsoft.de: The problem is more of that distribution like Ubuntu and Redhat are moving to upstart for boot and starting services/daemons. The main difference for the started services is that upstart need the program Is there any reason they can't do this: Postfix job script: pre-start exec postfix start post-stop exec postfix stop With this, the system will do the work for them, and everything uses stable documented interfaces. I'm just on the way learning the new concepts of upstart... As far as i understand the common way is to not detach as it is done in the common way but run in foreground to keep contact with upstart (init) so status can be easily collected. It should be possible to I'll repeat, this does not work with Postfix multi-instance support, which requires multiple master daemons. They can use this: pre-start exec postfix start pre-stop exec postfix stop Or they can use a postfix upstart pacifier which does postfix start then does nothing until shutdown: exec postfix upstart pre-stop exec postfix stop They should not start and stop the master directly. Among other things, that does not work with multi-instance support. Wietse
Re: Virtual Alias maps
On 24/02/2011 17:54, Victor Duchovni wrote: On Thu, Feb 24, 2011 at 09:52:30AM +0200, Etienne Pretorius wrote: I have a email address say staff@domain that maps perfectly to all its intended recipients, but on the same machine I have user1@domain that is suppose to map to user1@domain,user2@domain but it does not. Address mappings are tested via postmap -q. MAIN.CF virtual_alias_maps = mysql:/etc/postfix/mysql.virtualaliases.cf [usually best to put proxy: in front of mysql:] Report the output of: postmap -q us...@example.com mysql:/etc/postfix/mysql.virtualaliases.cf echo $? [root@mx-02 postfix]# postmap -q user1@domain mysql:/etc/postfix/mysql.virtualaliases.cf user1@domain,user2@domain [root@mx-02 postfix]# echo $? 0 mysql select Destination from postfix_virtual where EmailAddr='user1@domain'; +--+ | Destination | +--+ | user1@domain,user2@domain | +--+ Usually, in a database, better to make this multiple rows with the same lookup key: Index columnValue Column us...@example.com us...@example.com us...@example.com us...@example.com
Re: Update Postfix transport file on multiple servers
On Thu, Feb 24, 2011 at 02:18:07PM -0800, Luis Esteves wrote: In our organisation we have 4 postfix servers. Each time i need to add a new configuration to the transport file (for a new domain), i need to update the transport file on each server. This is cumbersome. Connect on each server with ssh, update the transport file, et run make to generate a db file. Since we're talking about transport_maps here, my preference is DNS rather than transport_maps. I'd use DNS views such that each mail host sees the internal MX for each new domain rather than the MX as seen in the global DNS. Sounds like you're also talking about relay_domains and possibly relay_recipient_maps as well. You would still need a means of updating those, but that could be scripted and use SSH keys as suggested. Networked map types are possible for these, but in the case of relay_domains, not recommended. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: Starting postfix
Hi, Postfix job script: pre-start exec postfix start post-stop exec postfix stop With this, the system will do the work for them, and everything uses stable documented interfaces. sorry Wietse, if it really would have been so easy, I never had contaced the list for such trivial solutions ;-) In fact your code snipped would start, that is true, but upstart would catch a wrong pid and you could never stop postfix with upstart again. But we really can close this thread, as I already have shown a script that does the job. Thanks Christian -- Roessner-Network-Solutions Bachelor of Science Informatik Nahrungsberg 81, 35390 Gießen F: +49 641 5879091, M: +49 176 93118939 USt-IdNr.: DE225643613 http://www.roessner-network-solutions.com
Re: Starting postfix
Christian Roessner: Hi, Postfix job script: pre-start exec postfix start post-stop exec postfix stop With this, the system will do the work for them, and everything uses stable documented interfaces. sorry Wietse, if it really would have been so easy, I never had contaced the list for such trivial solutions ;-) In fact your code snipped would start, that is true, but upstart would catch a wrong pid and you could never stop postfix with upstart again. Sorry, with the above, there is no PID, since all the work is done in the pre-start and pre-start actions. This approach is valid. It is used for example to turn on/off networking, where there is no single PID. But we really can close this thread, as I already have shown a script that does the job. I disagree. We need a solution that is based on proper understanding of how upstart works, and I will provide one that has no kludges. Wietse
Re: postfix-2.8.1 cc: acomp failed for postconf.c
On Fri, Feb 25, 2011 at 01:17:08AM -0500, Dennis Clarke wrote: $ ls -l /dev/urandom lrwxrwxrwx 1 root root 34 Feb 19 2008 /dev/urandom - ../devices/pseudo/random@0:urandom Which version of SunOS first introduced unconditional support for /dev/urandom? I don't know what you mean by unconditional but the feature was added to Solaris 8 in : Patch-ID# 112439-02 That's conditional on the SunOS patch. The question is which SunOS releases *always* have /dev/urandom. Well, two responses here : 1) that patch is deemed essential and no one, ever, runs without it 2) Solaris 9 provides SSH built in and thus it has a PRNG built into the kernel. Guess which patch in the Solaris 9 beta provides that feature? Yep, you guessed it, the one that applies to Solaris 8 was actually a patch from the Sol 9 dev stage. Anyways the hard answer is Solaris 9 but in practice Solaris 8. On Fri, Feb 25, 2011 at 12:35:48AM -0500, Dennis Clarke wrote: /opt/studio/SOS11/SUNWspro/bin/cc -DNO_CLOSEFROM -DNO_DEV_URANDOM -DNO_FUTIMESAT -Dstrcasecmp=fix_strcasecmp -Dstrncasecmp=fix_strncasecmp -g -O -I. -I../../include -DSUNOS5 -c postconf.c str_table.h, line 46: non-constant initializer involving a cast cc: acomp failed for postconf.c What do you see on line 46 of str_table.h? $ cat -n str_table.h | head -46 | tail -1 46 VAR_TLS_BUG_TWEAKS, DEF_TLS_BUG_TWEAKS, var_tls_bug_tweaks, 0, 0, Well, DEF_TLS_BUG_TWEAKS is defined as the constant expression: ((TLS_BUG_TWEAK_A TLS_BUG_TWEAK_B)+1) where TLS_BUG_TWEAK_A and TLS_BUG_TWEAK_B are string literals. In your case: and . So the expression is: (( ) + 1) which should be the constant pointer to the second (NUL) character of . Not quite sure why your compiler objects, but I guess the expression needs to be simplified. :-( I could try with GCC but really it *should* compile with baseline Solaris 8 and Sun Studio 11 fully patched. Does the patch below solve the problem? Let me try it and report back shortly ! Did I say thank you? Well people in the open source world need to say it much more often. Postfix is simply the best and I thank thee from the bottom of my heart and man .. I mean it ! -- Dennis Clarke dcla...@opensolaris.ca - Email related to the open source Solaris dcla...@blastwave.org - Email related to open source for Solaris
Re: postfix-2.8.1 cc: acomp failed for postconf.c
Dennis Clarke: On Fri, Feb 25, 2011 at 01:17:08AM -0500, Dennis Clarke wrote: $ ls -l /dev/urandom lrwxrwxrwx 1 root root 34 Feb 19 2008 /dev/urandom - ../devices/pseudo/random@0:urandom Which version of SunOS first introduced unconditional support for /dev/urandom? I don't know what you mean by unconditional but the feature was added to Solaris 8 in : Patch-ID# 112439-02 That's conditional on the SunOS patch. The question is which SunOS releases *always* have /dev/urandom. Well, two responses here : 1) that patch is deemed essential and no one, ever, runs without it 2) Solaris 9 provides SSH built in and thus it has a PRNG built into the kernel. Guess which patch in the Solaris 9 beta provides that feature? Yep, you guessed it, the one that applies to Solaris 8 was actually a patch from the Sol 9 dev stage. Anyways the hard answer is Solaris 9 but in practice Solaris 8. I can confirm that my Solaris 9 test machine has /dev/urandom. In fact, the makedefs script enables /dev/urandom access by default for Solaris 9 and onwards. My Solaris 8 test machine didn't have /dev/urandom, so I guess I am in the category of no one, ever :-) Wietse
Re: Virtual Alias maps
On Fri, Feb 25, 2011 at 04:34:56PM +0200, Etienne Pretorius wrote: Address mappings are tested via postmap -q. MAIN.CF virtual_alias_maps = mysql:/etc/postfix/mysql.virtualaliases.cf [usually best to put proxy: in front of mysql:] Report the output of: postmap -q us...@example.com mysql:/etc/postfix/mysql.virtualaliases.cf echo $? [root@mx-02 postfix]# postmap -q user1@domain mysql:/etc/postfix/mysql.virtualaliases.cf user1@domain,user2@domain If this rewrite is not happening, either the cleanup instance used has master.cf overrides that change the virtual_alias_maps setting, or the smtpd instance in question disables address mappings. Or your cut/paste from main.cf is not the actual setting. -- Viktor.
Re: sender_canonical_maps not matching
On Fri, Feb 25, 2011 at 10:07:18AM +0100, martin f krafft wrote:
root@redxprdww02:/etc/postfix# grep sender_rewrite main.cf
sender_canonical_maps = hash:/etc/postfix/sender_rewrite
Don't waste time with sender_canonical_maps, use either canonical_maps
or smtp_generic_maps if setting myorigin to the desired domain is
not an option.
Interesting. smtp_generic_maps would have been my next step. Why do
you advocate using canonical_maps over sender_canonical_maps?
As always, the {sender,recipient}_canonical_maps mechanisms are
semantically flawed, since To: and Cc: are recipient headers
to the sender, but are sender headers to the recipient in
the context of Reply-All.
There is no logically sound separation between the two types of addresses,
rather some addresses are globally valid, or preferred and others are
site local or obsolete, in both cases canonical or generic mapping is
the sensible choice.
And is smtp_generic_maps preferred over *canonical_maps?
Yes, when rewriting outbound mail is sufficient and there is not
a compelling reason to rewrite incoming mail.
--
Viktor.
postscreen primary/backup MX policy results
Yesterday I mentioned the possibility of having postscreen listen on both primary and backup MX address *on the same machine*. In addition, one can also introduce new mechanisms into postscreen. For example, disabling dynamic whitelisting for connections to backup MX addresses. I have run this for a day now, and in my case about 10% of all the spambots will connect to the backup MX address. Of this 10%, 1/5 talks to the primary MX address, and 1/3 is not a pregreeter. So, the result is not as spectacular as the pregreet test, but it can still help to block some spambots before they are blacklisted. Now I need to push out some code, so that Ralf can collect statistics with larger email volumes than my single-user machine. Wietse
Re: postfix-2.8.1 cc: acomp failed for postconf.c
Dennis Clarke: On Fri, Feb 25, 2011 at 01:17:08AM -0500, Dennis Clarke wrote: $ ls -l /dev/urandom lrwxrwxrwx 1 root root 34 Feb 19 2008 /dev/urandom - ../devices/pseudo/random@0:urandom Which version of SunOS first introduced unconditional support for /dev/urandom? I don't know what you mean by unconditional but the feature was added to Solaris 8 in : Patch-ID# 112439-02 That's conditional on the SunOS patch. The question is which SunOS releases *always* have /dev/urandom. Well, two responses here : 1) that patch is deemed essential and no one, ever, runs without it 2) Solaris 9 provides SSH built in and thus it has a PRNG built into the kernel. Guess which patch in the Solaris 9 beta provides that feature? Yep, you guessed it, the one that applies to Solaris 8 was actually a patch from the Sol 9 dev stage. Anyways the hard answer is Solaris 9 but in practice Solaris 8. I can confirm that my Solaris 9 test machine has /dev/urandom. In fact, the makedefs script enables /dev/urandom access by default for Solaris 9 and onwards. My Solaris 8 test machine didn't have /dev/urandom, so I guess I am in the category of no one, ever :-) Wietse You're totally in the category of .. are you crazy? Patch that box ! -- Dennis Clarke dcla...@opensolaris.ca - Email related to the open source Solaris dcla...@blastwave.org - Email related to open source for Solaris
Re: Postfix stable release 2.8.1 available
On 02/23/2011 03:02 PM, Christian Roessner wrote: Hi, Postfix stable release 2.8.1 is available. This release fixes one signal 11 bug with SMTP server debug logging, and cleans up some code and documentation. Ubuntu packages done. https://launchpad.net/~christian-roessner-net/+archive/ppa - I dropped HP-UX patches from Debain, as they are useless in Ubuntu - I dropped chroot environment, as discussed lately on this list Christian I upgraded to these packages, thanks for that. However, I was hoping the fixes mentioned by Wietse would also get rid of the incessant postfix/postscreen[25978]: warning: getpeername: Transport endpoint is not connected -- dropping this connection messages in my logs. I suppose postscreen is saying the client went bye-bye without saying bye-bye, but this happens more often than there are actual delivery attempts! It could be valuable for troubleshooting, but for day-to-day usage - I don't care. -- J.
Re: Postfix stable release 2.8.1 available
Jeroen Geilman: I upgraded to these packages, thanks for that. However, I was hoping the fixes mentioned by Wietse would also get rid of the incessant postfix/postscreen[25978]: warning: getpeername: Transport endpoint is not connected -- dropping this connection messages in my logs. I can't fix a problem that no-one tells me about. I suppose postscreen is saying the client went bye-bye without saying bye-bye, but this happens more often than there are actual delivery attempts! Perhaps the problem is that you have a bad router, or a kernel with a weird implementation of accept(2). For example, early Linux accept() implementations would actually wake up as soon as the first SYN arrived, resulting in all kinds of WTF errors when someone tried to use the socket. People keep trying to improve software all the time. It could be valuable for troubleshooting, but for day-to-day usage - I don't care. Maybe there is a real problem. Wietse
Re: Postfix stable release 2.8.1 available
On 02/25/2011 08:58 PM, Wietse Venema wrote: Jeroen Geilman: I upgraded to these packages, thanks for that. However, I was hoping the fixes mentioned by Wietse would also get rid of the incessant postfix/postscreen[25978]: warning: getpeername: Transport endpoint is not connected -- dropping this connection messages in my logs. I can't fix a problem that no-one tells me about. I suppose postscreen is saying the client went bye-bye without saying bye-bye, but this happens more often than there are actual delivery attempts! Perhaps the problem is that you have a bad router, or a kernel with a weird implementation of accept(2). For example, early Linux accept() implementations would actually wake up as soon as the first SYN arrived, resulting in all kinds of WTF errors when someone tried to use the socket. People keep trying to improve software all the time. It could be valuable for troubleshooting, but for day-to-day usage - I don't care. Maybe there is a real problem. Wietse My head is hanging in shame. It's caused by a remote SMTP alive check I do myself - connect, then drop. -- J.
Re: Starting postfix
Zitat von Wietse Venema wie...@porcupine.org: lst_ho...@kwsoft.de: Zitat von Wietse Venema wie...@porcupine.org: Wietse Venema: lst_ho...@kwsoft.de: Zitat von Wietse Venema wie...@porcupine.org: lst_ho...@kwsoft.de: The problem is more of that distribution like Ubuntu and Redhat are moving to upstart for boot and starting services/daemons. The main difference for the started services is that upstart need the program Is there any reason they can't do this: Postfix job script: pre-start exec postfix start post-stop exec postfix stop With this, the system will do the work for them, and everything uses stable documented interfaces. I'm just on the way learning the new concepts of upstart... As far as i understand the common way is to not detach as it is done in the common way but run in foreground to keep contact with upstart (init) so status can be easily collected. It should be possible to I'll repeat, this does not work with Postfix multi-instance support, which requires multiple master daemons. Agreed and understanded. They can use this: pre-start exec postfix start pre-stop exec postfix stop This has the drawback that postfix start terminates after Postfix is started so as said upstart will report Postfix as waiting (for the next event) instead of running. Or they can use a postfix upstart pacifier which does postfix start then does nothing until shutdown: exec postfix upstart pre-stop exec postfix stop That was the construct i tried to explain. A wrapper/pacifier whatever is needed which does not terminate but does nothing until a stop or some other event arrives. They should not start and stop the master directly. Among other things, that does not work with multi-instance support. Agreed and understanded. Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: postfix-2.8.1 cc: acomp failed for postconf.c
Dennis Clarke: In fact, the makedefs script enables /dev/urandom access by default for Solaris 9 and onwards. My Solaris 8 test machine didn't have /dev/urandom, so I guess I am in the category of no one, ever :-) Wietse You're totally in the category of .. are you crazy? Patch that box ! Perhaps, if Postfix were hobbyist software, I might introduce dependencies on optional software that is not required to build, install, or run Postfix. Instead, I have made Postfix run-time configurable, so that you can configure main.cf for optional components that you add to the system. Anyway, thanks for pointing out the compiler error message. I don't routinely compile Postfix with /opt/SUNWspro/bin/cc like I used to, so I rely more on other people's reports. Wietse
Re: How do I set up address/domain literals?
On 02/24/2011 01:29 AM, Linda Pagillo wrote: Thank you Mouss. Yes, you are correct. I did indeed mean postmaster@[ip]. I'm not having any mail rejected. I was just wondering if Postfix accepts mail to literals by default. I'm getting ready to install Postfix and I wanted to be sure that I had this in my notes. I believe you answered my question. Thank you very much for your assistance. Note that if the postfix system is behind a NAT device, inet_interfaces = all does not include the external IP. You need to add the external IP to proxy_interfaces to accept IP literal addresses in that case. -- J.
RE: How do I set up address/domain literals?
Thank you! Linda Pagillo - Owner LPDynamix 931-284-9291 li...@lpdynamix.com -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Jeroen Geilman Sent: Friday, February 25, 2011 2:45 PM To: postfix-users@postfix.org Subject: Re: How do I set up address/domain literals? On 02/24/2011 01:29 AM, Linda Pagillo wrote: Thank you Mouss. Yes, you are correct. I did indeed mean postmaster@[ip]. I'm not having any mail rejected. I was just wondering if Postfix accepts mail to literals by default. I'm getting ready to install Postfix and I wanted to be sure that I had this in my notes. I believe you answered my question. Thank you very much for your assistance. Note that if the postfix system is behind a NAT device, inet_interfaces = all does not include the external IP. You need to add the external IP to proxy_interfaces to accept IP literal addresses in that case. -- J.
Re: Starting postfix
Hi, That was the construct i tried to explain. A wrapper/pacifier whatever is needed which does not terminate but does nothing until a stop or some other event arrives. They should not start and stop the master directly. Among other things, that does not work with multi-instance support. Agreed and understanded. may I ask, why postfix should find a solution? I explain my question: before I came here and started that thread, I took many hours of reading about upstart and doing many local tests here to figure out how I could get the job done. I also called strace start postfix and could see that there is some kind of message communication. Yet I did not find out, which destination receives upstart information. But at least I think, there could be more applications out there that have issues like this here. So wouldn't it make sense to ask upstart developers, if they can extend their upstart interfaces? Or if we really can find out, where upstart is comminicating to, maybe extend postfix' capabilities to send information to this place. Just thoughts and I only try to sort some ideas. If I am allowed to summarize, from what I learned here these days: Postfix does: - have a really stable master process that did not die in more than 10 years (Victor) - does not need a respawn feature upstart does: - start - stop - status - restart - what else? start, stop and status use the pid that a process had after starting it. So now I try to combine this: Some piece of software, call it dispatcher, call it wrapper, whatever, needs to call postfix start to not break any interfaces or anything else postfix related. Right? The wrapper that I showed here does this job. You can start and stop postfix cleanly. If I understood right, simply testing a status of postfix is not so easy, so Victor does the monitoring differently. So we can not simply check the status and the result may be a bogus result. This is, what I learned. So now my question: what do you have in mind Wietse, if you say, you may provide something? Do not get me wrong please. I really like to learn and even when you got me totally wrong at the beginning of this thread, I never had something bad in mind. Just coming here and trying to find a solution. Is that ok so far? Is there anything that I can do to help? Best wishes Christian -- Roessner-Network-Solutions Bachelor of Science Informatik Nahrungsberg 81, 35390 Gießen F: +49 641 5879091, M: +49 176 93118939 USt-IdNr.: DE225643613 http://www.roessner-network-solutions.com
Re: Starting postfix
Christian Roessner: This is, what I learned. So now my question: what do you have in mind Wietse, if you say, you may provide something? Do not get me wrong I have written a postfix upstart command as described below. This can automatically respawn Postfix in single instance mode (even if I have never seen Postfix die in 14 years of development). It automatically handles the SIGHUP signal from upstart. In the case of multi instance mode Postfix it just becomes an idle persistent process. Here, I still need to add code that executes postfix reload when it receives the SIGHUP signal from upstart. Some details are still in flux, for example I may decide to merge postfix check functionality under postfix upstart. Wietse POSTFIX(1) POSTFIX(1) ... upstart Start the Postfix mail system (skipping the check phase) and do not disappear into the background. See RUNNING UNDER UPSTART below. ... RUNNING UNDER UPSTART The upstart system is designed for automated stopping and (re)starting of daemon applications. The following is an example of the core entries for an upstart job def- inition: # Boot-time health check and repair. pre-start exec postfix check # Due to its one PID per job model, upstart cannot # support automatic restart in Postfix multi-instance # mode. exec postfix upstart # Orderly shut down before upstart sends SIGKILL. pre-stop exec postfix stop Note: upstart assumes that there is one PID per job, therefore it can- not support automatic restart in Postfix multi-instance mode. This is now running on an Ubuntu virtual machine. Wietse
Re: Starting postfix
Zitat von Wietse Venema wie...@porcupine.org: Christian Roessner: This is, what I learned. So now my question: what do you have in mind Wietse, if you say, you may provide something? Do not get me wrong I have written a postfix upstart command as described below. This can automatically respawn Postfix in single instance mode (even if I have never seen Postfix die in 14 years of development). It automatically handles the SIGHUP signal from upstart. In the case of multi instance mode Postfix it just becomes an idle persistent process. Here, I still need to add code that executes postfix reload when it receives the SIGHUP signal from upstart. Some details are still in flux, for example I may decide to merge postfix check functionality under postfix upstart. Wietse POSTFIX(1) POSTFIX(1) ... upstart Start the Postfix mail system (skipping the check phase) and do not disappear into the background. See RUNNING UNDER UPSTART below. ... RUNNING UNDER UPSTART The upstart system is designed for automated stopping and (re)starting of daemon applications. The following is an example of the core entries for an upstart job def- inition: # Boot-time health check and repair. pre-start exec postfix check # Due to its one PID per job model, upstart cannot # support automatic restart in Postfix multi-instance # mode. exec postfix upstart # Orderly shut down before upstart sends SIGKILL. pre-stop exec postfix stop Note: upstart assumes that there is one PID per job, therefore it can- not support automatic restart in Postfix multi-instance mode. This is now running on an Ubuntu virtual machine. Cool... And BTW i also have never seen Postfix die. It is one of the most stable non-trivial software systems i have seen until now. Many Thanks Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: Starting postfix
* lst_ho...@kwsoft.de lst_ho...@kwsoft.de: Zitat von Wietse Venema wie...@porcupine.org: This is now running on an Ubuntu virtual machine. Cool... And BTW i also have never seen Postfix die. It is one of the most stable non-trivial software systems i have seen until now. Postfix is frustrating. At first tt's fun because it is setup easily. But once you've done, you don't need to touch it again. It simply sits there and does its job. No more fun. Nothing to play with. Very frustrating... ;) p@rick -- All technical questions asked privately will be automatically answered on the list and archived for public access unless privacy is explicitely required and justified. saslfinger (debugging SMTP AUTH): http://postfix.state-of-mind.de/patrick.koetter/saslfinger/ smime.p7s Description: S/MIME cryptographic signature
Re: Outbound relayhost distribution
On Feb 23, 2011, at 8:25 PM, Victor Duchovni wrote: On Wed, Feb 23, 2011 at 02:19:28PM -0800, Robert Goodyear wrote: I'm sorry... I was speaking lazily there. I meant a 4.X.X response that would cause the message to requeue and follow a retry/backoff rate algorithm. Mere 4XX responses to MAIL FROM:, RCPT TO:, DATA or . don't impact active queue scheduling. Only responses that prematurely termination the connection, or a 4XX banner or HELO response trigger backoff (concurrency reduction and possible throttling of the destination after sufficiently many consecutive failures). What negotiation? What problem are you trying to solve? Trying to load-share my edge MTAs that are relayhosts from my origin Postfix in a more scientific way than just hitting them at random, because when one becomes saturated, its weight in the probability of receiving another request is not reduced programmatically. This is not necessary. The random loading is fine at low loads, under high loads Postfix connection caching is time-based rather than message count based, which means that faster servers get a bigger share of the load. Some sites foolishly set limits on the number of deliveries per connection not just for suspect clients, but for all SMTP clients. They are doing themselves and everyone else a disservice. By negotiation, I mean the SMTP session from my origin to the relay wherein it might get a 4.X.X Not all 4XX responses are alike, tempfailing a message is normal, rejecting SMTP service is another matter. You still have not explained what real problem you're solving. Is this just premature optimization? -- if I can apply some logic that takes that one relay out of rotation for N minutes, that would be nice, because it would reduce chatter from subsequent retries and focus traffic on the other relays for a while. Have you seen problem relays in your upstream relay mix? What real symptoms do they exhibit and what is the observed impact on the upstream Postfix SMTP client? I'm going to run some analytics on my last 12 months' worth of outbound messages to get more scientific with my gut instincts here. It's about 270 million messages, and my observation is that when we have a spike of 4 or 5 million that need to deliver at a certain point in time (surrounding a critical/time-sensitive product launch) that my deferred queues saturate too quickly. Again, rather than just brute-force it with more edge MTAs, I was hoping to devise a more deterministic way to control the internal relaying to my geographically-separated points of presence and shave off the few ms of conversation that are consumed in finding out if relay X will accept more messages yet.
Re: Outbound relayhost distribution
On Fri, Feb 25, 2011 at 02:38:16PM -0800, Robert Goodyear wrote: Have you seen problem relays in your upstream relay mix? What real symptoms do they exhibit and what is the observed impact on the upstream Postfix SMTP client? I'm going to run some analytics on my last 12 months' worth of outbound messages to get more scientific with my gut instincts here. It's about 270 million messages, and my observation is that when we have a spike of 4 or 5 million that need to deliver at a certain point in time (surrounding a critical/time-sensitive product launch) that my deferred queues saturate too quickly. 20 million a month is a moderate mail flow if it is mail from ~50-100K users spread out over the day. I would then expect no more than ~1K messages in the deferred queue of each ~4 machines to be about the right quantity of deferred email. 4 million messages to deliver all at once is a very different problem. -- Viktor.
Re: Outbound relayhost distribution
On 2/25/2011 4:38 PM, Robert Goodyear wrote: I'm going to run some analytics on my last 12 months' worth of outbound messages to get more scientific with my gut instincts here. It's about 270 million messages, and my observation is that when we have a spike of 4 or 5 million that need to deliver at a certain point in time (surrounding a critical/time-sensitive product launch) that my deferred queues saturate too quickly. Again, rather than just brute-force it with more edge MTAs, I was hoping to devise a more deterministic way to control the internal relaying to my geographically-separated points of presence and shave off the few ms of conversation that are consumed in finding out if relay X will accept more messages yet. Standard advice for this problem is to designate an internal fallback_relay (which can be a whole second MX farm) to handle mail that isn't delivered quickly. That way the primary outbound machines aren't bogged down with a clogged defer queue. I think this is discussed in TUNING_README. But you're wise to analyze prior data and determine exactly where the bottleneck is before wholesale restructuring. -- Noel Jones
Re: Outbound relayhost distribution
On Feb 25, 2011, at 2:58 PM, Victor Duchovni wrote: On Fri, Feb 25, 2011 at 02:38:16PM -0800, Robert Goodyear wrote: Have you seen problem relays in your upstream relay mix? What real symptoms do they exhibit and what is the observed impact on the upstream Postfix SMTP client? I'm going to run some analytics on my last 12 months' worth of outbound messages to get more scientific with my gut instincts here. It's about 270 million messages, and my observation is that when we have a spike of 4 or 5 million that need to deliver at a certain point in time (surrounding a critical/time-sensitive product launch) that my deferred queues saturate too quickly. 20 million a month is a moderate mail flow if it is mail from ~50-100K users spread out over the day. I would then expect no more than ~1K messages in the deferred queue of each ~4 machines to be about the right quantity of deferred email. 4 million messages to deliver all at once is a very different problem. It is definitely a lumpy distribution -- probably 2 to 3 per month of ~4-5 million to North American subscribers, interspersed with smaller regional (outside North America) campaigns of 250-300K that sometimes coincide with one of the big campaigns. Of course I could start building stovepipes in my topology to isolate activity so one doesn't affect the other, but then conversely I might have cold MTAs sitting idle when I could be using them. I *do* have some regional points of presence where I have MTAs close to the subscribers for their markets, e.g.: UK, EU and SE Asia; maybe I should experiment with offloading deferred North America queues to them. I wonder if their inherent latency would act as a rate limiter of sorts that would play more nicely with recipient domains? Anyway I'm speculating... let me go crazy with SPSS and look for some absolute patterns in the last year here.
Re: [PATCH] postfix won't build on FREEBSD 7.2+
On Fri, 2011-02-25 at 10:50:45 +0100, kristof.vans...@telenet.be wrote: This problem exist in the 2.7 and 2.8 branch: In file included from attr_clnt.c:77: /usr/include/unistd.h:329: error: conflicting types for 'closefrom' ./sys_defs.h:1399: error: previous declaration of 'closefrom' was here *** Error code 1 Stop in /home/src/postfix-2.7.2/src/util. *** Error code 1 Stop in /home/src/postfix-2.7.2. Ah, you are not using the ports infrastructure, in which sys_defs.h has been patched to be aware of the closefrom() system call in 702104 and other FreeBSD versions. FWIW, this issue was discussed[1] on -devel a few months ago. [1] http://comments.gmane.org/gmane.mail.postfix.devel/2277 -- Sahil Tandon sa...@freebsd.org
Re: Outbound relayhost distribution
the quantity of deferred is yahoo response : this as that that is this Le vendredi 25 février 2011 à 15:29 -0800, Robert Goodyear a écrit : On Feb 25, 2011, at 2:58 PM, Victor Duchovni wrote: On Fri, Feb 25, 2011 at 02:38:16PM -0800, Robert Goodyear wrote: Have you seen problem relays in your upstream relay mix? What real symptoms do they exhibit and what is the observed impact on the upstream Postfix SMTP client? I'm going to run some analytics on my last 12 months' worth of outbound messages to get more scientific with my gut instincts here. It's about 270 million messages, and my observation is that when we have a spike of 4 or 5 million that need to deliver at a certain point in time (surrounding a critical/time-sensitive product launch) that my deferred queues saturate too quickly. 20 million a month is a moderate mail flow if it is mail from ~50-100K users spread out over the day. I would then expect no more than ~1K messages in the deferred queue of each ~4 machines to be about the right quantity of deferred email. 4 million messages to deliver all at once is a very different problem. It is definitely a lumpy distribution -- probably 2 to 3 per month of ~4-5 million to North American subscribers, interspersed with smaller regional (outside North America) campaigns of 250-300K that sometimes coincide with one of the big campaigns. Of course I could start building stovepipes in my topology to isolate activity so one doesn't affect the other, but then conversely I might have cold MTAs sitting idle when I could be using them. I *do* have some regional points of presence where I have MTAs close to the subscribers for their markets, e.g.: UK, EU and SE Asia; maybe I should experiment with offloading deferred North America queues to them. I wonder if their inherent latency would act as a rate limiter of sorts that would play more nicely with recipient domains? Anyway I'm speculating... let me go crazy with SPSS and look for some absolute patterns in the last year here. -- gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7 signature.asc Description: Ceci est une partie de message numériquement signée
mysql GPL/postfix IPL incompatibility
Just curious, the GPL and the IPL are not license compatible. Anyone know how RHEL and other sites deal with this when trying to provide a postfix with mysql tables as an option? I see that postfix on RHEL6 clearly links against mysql: cd /usr/sbin [build@zre-rhel6-64 sbin]$ ldd postfix libmysqlclient.so.16 = /usr/lib64/mysql/libmysqlclient.so.16 (0x7f6e79d26000) --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: Starting postfix
On 2/25/11 6:45 AM, Christian Roessner at c+postfix_org...@roessner-network-solutions.com wrote: That postfix must not be started directly by calling master should also be documented in the master man page, as people like me (and my idea was based on Apple's practise, like they DO START postfix with launchctl on Mac OS X Server edition). This got my attention because I run the Apple provided Postfix (2.5.5) on Mac OS X client (10.6.6 specifically). What do you know - when I look at the launchctl plist Apple provides to start Postfix, it does so by running master directly. Thanks Apple! -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/
Re: Starting postfix
Larry Stone: On 2/25/11 6:45 AM, Christian Roessner at c+postfix_org...@roessner-network-solutions.com wrote: That postfix must not be started directly by calling master should also be documented in the master man page, as people like me (and my idea was based on Apple's practise, like they DO START postfix with launchctl on Mac OS X Server edition). This got my attention because I run the Apple provided Postfix (2.5.5) on Mac OS X client (10.6.6 specifically). What do you know - when I look at the launchctl plist Apple provides to start Postfix, it does so by running master directly. Thanks Apple! The upstart hacks will hopefully make it easier for other integrators to do the right thing. Wietse
Re: Starting postfix
The operative words are desktop computer, the problem it would seem to me, is that Upstart is being used in an environment for which it has not been designed and is trying to solve problems that do not occur on a server. Perhaps we need to point this out to the good folks at Ubuntu etc. jut my 2c worth John A [snip] Since Upstart is new to me I decided to read about it: [The shortcomings of sysvinit] leaves it unable to handle various tasks on a moderndesktop computer http://en.wikipedia.org/wiki/Desktop_computerelegantly, including: The addition or [snip] -- All that is necessary for the triumph of evil is that good men do nothing. (Edmund Burke)
Re: mysql GPL/postfix IPL incompatibility
On Fri, Feb 25, 2011 at 04:39:25PM -0800, Quanah Gibson-Mount wrote: Just curious, the GPL and the IPL are not license compatible. Anyone know how RHEL and other sites deal with this when trying to provide a postfix with mysql tables as an option? [IANAL] The MySQL client libraries may also be linked with software available under various other open-source licenses: http://www.mysql.com/about/legal/licensing/foss-exception/ Among these is the Common Public License, which IBM now uses instead of IPL, but it is not obvious to me that the CPL applies to Postfix. http://www.ibm.com/developerworks/library/os-cplfaq.html 1. What is the relationship between the IBM(R) Public License (IPL) and the Common Public License (CPL)? The IPL was IBM's first open source license. The CPL is essentially the next version of the IPL. the Postfix license states: IBM may publish new versions (including revisions) of this Agreement from time to time. Each new version of the Agreement will be given a distinguishing version number. The Program (including Contributions) may always be distributed subject to the version of the Agreement under which it was received. In addition, after a new version of the Agreement is published, Contributor may elect to distribute the Program (including its Contributions) under the new version. so it is perhaps useful to understand whether the CPL is such a new version, and whether Postfix may now be distributed under the CPL. I see that postfix on RHEL6 clearly links against mysql: While the IPL is listed at: http://www.opensource.org/licenses/alphabetical The MySQL FOSS exception, however, does not broadly include all OSI licenses. -- Viktor.
Re: mysql GPL/postfix IPL incompatibility
--On Saturday, February 26, 2011 1:41 AM -0500 Victor Duchovni victor.ducho...@morganstanley.com wrote: On Fri, Feb 25, 2011 at 04:39:25PM -0800, Quanah Gibson-Mount wrote: Just curious, the GPL and the IPL are not license compatible. Anyone know how RHEL and other sites deal with this when trying to provide a postfix with mysql tables as an option? [IANAL] The MySQL client libraries may also be linked with software available under various other open-source licenses: http://www.mysql.com/about/legal/licensing/foss-exception/ Among these is the Common Public License, which IBM now uses instead of IPL, but it is not obvious to me that the CPL applies to Postfix. http://www.ibm.com/developerworks/library/os-cplfaq.html 1. What is the relationship between the IBM(R) Public License (IPL) and the Common Public License (CPL)? The IPL was IBM's first open source license. The CPL is essentially the next version of the IPL. the Postfix license states: IBM may publish new versions (including revisions) of this Agreement from time to time. Each new version of the Agreement will be given a distinguishing version number. The Program (including Contributions) may always be distributed subject to the version of the Agreement under which it was received. In addition, after a new version of the Agreement is published, Contributor may elect to distribute the Program (including its Contributions) under the new version. so it is perhaps useful to understand whether the CPL is such a new version, and whether Postfix may now be distributed under the CPL. I see that postfix on RHEL6 clearly links against mysql: While the IPL is listed at: http://www.opensource.org/licenses/alphabetical The MySQL FOSS exception, however, does not broadly include all OSI licenses. Victor, Thanks for the information, very useful. I would be particularly curious to know if Postfix is now licensed under the CPL rather than the IPL. Would Wietse need to confirm that? Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: Update Postfix transport file on multiple servers
Yes, relay_domains, sender_access, and more. Maybe the easier solution is to use the ssh/keys, but is it not dangerous to store private keys on a DMZ ? Luis /dev/rob0 wrote: On Thu, Feb 24, 2011 at 02:18:07PM -0800, Luis Esteves wrote: In our organisation we have 4 postfix servers. Each time i need to add a new configuration to the transport file (for a new domain), i need to update the transport file on each server. This is cumbersome. Connect on each server with ssh, update the transport file, et run make to generate a db file. Since we're talking about transport_maps here, my preference is DNS rather than transport_maps. I'd use DNS views such that each mail host sees the internal MX for each new domain rather than the MX as seen in the global DNS. Sounds like you're also talking about relay_domains and possibly relay_recipient_maps as well. You would still need a means of updating those, but that could be scripted and use SSH keys as suggested. Networked map types are possible for these, but in the case of relay_domains, not recommended. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header -- View this message in context: http://old.nabble.com/Update-Postfix-transport-file-on-multiple-servers-tp31008507p31018639.html Sent from the Postfix mailing list archive at Nabble.com.
Re: Starting postfix
Hi, This got my attention because I run the Apple provided Postfix (2.5.5) on Mac OS X client (10.6.6 specifically). What do you know - when I look at the launchctl plist Apple provides to start Postfix, it does so by running master directly. Thanks Apple! Calling /usr/libexec/postfix/master in the plist. That should not be critics. My friend Lars runs three X-Serve servers. One Tiger, Leopard and before posting here, I asked him to please just look into the plist and tell me, what is called. I do not know for Snow Leopard I must admit. Was that said wrong? Christian -- Roessner-Network-Solutions Bachelor of Science Informatik Nahrungsberg 81, 35390 Gießen F: +49 641 5879091, M: +49 176 93118939 USt-IdNr.: DE225643613 http://www.roessner-network-solutions.com
