Re: post-install, IPv6-only: could not find any active network interfaces (again)

[Wietse Venema]

Wietse Venema:
> After I made "inet_protocols=all" the default on your request, I
> received notice that Postfix no longer would build on freebsd.org
> "build" systems, and that it would be removed from ports. These
> build environments have IPv6 in the kernel but they have no IPv6
> interfaces.  Basically, these are IPv4-only boxes with can IPv6
> configuration that violates the RFCs.

Attached is a postfix-install patch that works with conf/main.cf
as distributed, on systems without IPv4 support.

This adds one new question to the install dialog, so people
who run automated builds may want to take notice.

To install Postfix from scratch, answer with "ipv6" or "all" to the
question for "inet_protocols". For best performance specify "ipv6"
as this eliminates useless IPv4 DNS lookups and useless connection
attempts.

Wietse

*** postfix-install Sat Nov 19 18:09:16 2011
--- /tmp/postfix-installTue Dec 27 17:48:43 2011
***
*** 147,152 
--- 147,155 
  # .IP readme_directory
  # The destination directory for the Postfix README files.
  # This parameter setting is recorded in the installed main.cf file.
+ # .IP inet_protocols
+ # The supported Internet protocols: "ipv4", "ipv6" or all".
+ # This parameter setting is recorded in the installed main.cf file.
  # SEE ALSO
  # post-install(1) post-installation procedure
  # FILES
***
*** 359,364 
--- 362,372 
  html_directory_prompt="the destination directory for the Postfix
  HTML files. Specify \"no\" if you do not want to install these files."
  
+ inet_protocols_prompt="the Internet protocols that Postfix will
+ support.  Specify \"ipv4\", \"ipv6\", or \"all\". Specify \"all\"
+ only if you have both IPv4 and IPv6 connectivity, otherwise mail
+ delivery performance will suffer."
+ 
  # Default settings, just to get started.
  
  : ${install_root=/}
***
*** 422,428 
  
  CONFIG_PARAMS="command_directory daemon_directory data_directory \
  html_directory mail_owner mailq_path  manpage_directory newaliases_path \
! queue_directory readme_directory sendmail_path setgid_group"
  
  # Extract parameter settings from the installed main.cf file.
  
--- 430,436 
  
  CONFIG_PARAMS="command_directory daemon_directory data_directory \
  html_directory mail_owner mailq_path  manpage_directory newaliases_path \
! queue_directory readme_directory sendmail_path setgid_group inet_protocols"
  
  # Extract parameter settings from the installed main.cf file.
  
***
*** 520,525 
--- 528,543 
  }
  done
  
+ case "$inet_protocols" in
+  ipv4|ipv6|all)
+ ;;
+  *) (echo $0: Error: the inet_protocols parameter requires a value \"ipv4\",
+  echo \"ipv6\", or \"all\". Try again with \"inet_protocols=name\" on
+  echo the command line or execute \"make install\" and specify
+  echo inet_protocols interactively.) | ${FMT} 1>&2
+  exit 1;;
+ esac
+ 
  test -d $tempdir || mkdir -p $tempdir || exit 1
  
  trap "rm -f $tempdir/junk" 0 1 2 3 15
***
*** 738,743 
--- 756,762 
  "manpage_directory = $manpage_directory" \
  "sample_directory = $sample_directory" \
  "readme_directory = $readme_directory" \
+ "inet_protocols = $inet_protocols" \
  || exit 1
  
  # If Postfix is being installed locally from source code, do the

Re: post-install, IPv6-only: could not find any active network interfaces (again)

[Sahil Tandon]

On Tue, 2011-12-27 at 17:24:57 -0500, Wietse Venema wrote:

> ... 
> After I made "inet_protocols=all" the default on your request, I
> received notice that Postfix no longer would build on freebsd.org
> "build" systems, and that it would be removed from ports. These
> build environments have IPv6 in the kernel but they have no IPv6
> interfaces.  Basically, these are IPv4-only boxes with can IPv6
> configuration that violates the RFCs.
> 
> These changes were made to avoid being kicked out of the ports:
> 
> 2017
> 
> Workaround: don't use IPv6 at build time. File: conf/main.cf.
> 
> Workaround: don't abort when IPv6 is present but busted.
> File: util/inet_proto.c.
> 
> Now, I can easily remove the first workaround. But that won't
> prevent the post-install script from adding "inet_protocols=ipv4"
> to main.cf when you upgrade Postfix.
> ...

FWIW, the FreeBSD Postfix port is patched so that post-install does not
add "inet_protocols=ipv4" to main.cf during upgrades. Instead, users are
notified[1] about the recent change of defaults, and asked to append the
ipv4 line to their main.cf, if necessary.  

[1] This is in ports/UPDATING, a file users consult before upgrading any
port.  I elected to go this route to force users to pay attention to
this particular change.

-- 
Sahil Tandon
--- conf/post-install.orig  2011-10-11 20:39:19.0 -0400
+++ conf/post-install   2011-10-11 20:41:58.0 -0400
@@ -790,18 +790,6 @@
 EOF
 }
 
-# Postfix 2.9.
-# Safety net for incompatible changes in IPv6 defaults.  This
-# requires that the default is "inet_protocols = ipv4" when
-# IPv6 support is not compiled in. See util/sys_defs.h.
-
-test "`$POSTCONF -dh inet_protocols`" = "ipv4" ||
-   test -n "`$POSTCONF -c $config_directory -nh inet_protocols`" || {
-   echo COMPATIBILITY: editing main.cf, setting inet_protocols=ipv4.
-   echo Specify inet_protocols explicitly if you want to enable IPv6.
-   echo In a future release IPv6 will be enabled by default.
-   $POSTCONF -c $config_directory inet_protocols=ipv4 || exit 1
-}
 }
 
 # A reminder if this is the first time Postfix is being installed.

Re: post-install, IPv6-only: could not find any active network interfaces (again)

[Wietse Venema]

Wietse Venema:
> Wietse Venema:
> > Mark Martinec:
> > > Trying to install postfix-2.9-20111219 from ports on FreeBSD 9.0
> > > (with an inet6-only kernel), the installation fails as before:
> > > 
> > > postfix-current$ make install
> > > ...
> > > Skipping /usr/local/share/doc/postfix/postfix-power.png...
> > > Skipping /usr/local/share/doc/postfix/scache.8.html...
> > > Skipping /usr/local/share/doc/postfix/tlsmgr.8.html...
> > > postfix: fatal: could not find any active network interfaces
> > > *** Error code 1
> > 
> > How do you want to proceed: wait until I have time to reproduce
> > your IPv6-only setup for which I have no specification, or spend
> > all of next year doing blind testing?
> 
> I'm assuming that you have "inet_protocols=ipv6" in main.cf, instead
> of the backwards-compatibility "inet_protocols=ipv4" workaround,
> because that would not work on your machine.

After I made "inet_protocols=all" the default on your request, I
received notice that Postfix no longer would build on freebsd.org
"build" systems, and that it would be removed from ports. These
build environments have IPv6 in the kernel but they have no IPv6
interfaces.  Basically, these are IPv4-only boxes with can IPv6
configuration that violates the RFCs.

These changes were made to avoid being kicked out of the ports:

2017

Workaround: don't use IPv6 at build time. File: conf/main.cf.

Workaround: don't abort when IPv6 is present but busted.
File: util/inet_proto.c.

Now, I can easily remove the first workaround. But that won't
prevent the post-install script from adding "inet_protocols=ipv4"
to main.cf when you upgrade Postfix.

To avoid all this, patch conf/main.cf and s/ipv4/ipv6/. Meanwhile
I'll see what it takes to add a question to the Postfix install
script. I hate to bug people with useless questions.

Wietse

Re: Loadbalancing+failover solution

[Lorens Kockum]

On Tue, Dec 27, 2011 at 09:24:01PM +0100, Michael Maymann wrote:
> thanks for your kind reply...:-) !
> yes this is exactly the case... and my internal local-mailers consist on
> standard RHEL5+6 servers and NetApp's.
> Our ISP is restricting mail from only 1 of our sites, so we need to relay
> all our internal mail globally through this site.
> 
> We can't prevent non-mail applications, as we don't have 100% control of
> all hosts (LAB equipment etc.), so I guess it makes sense to still keep
> local-mailer, at-least just to keep consistency.

If it's for consistency, you would *not* have local mailers,
but you would configure everything to point at your HA postfix
relay. However I personally like local mailers as long as
something is automatically monitoring that they are well, and
you may find programs that will not work otherwise.

> Do you have a howto for this setup laying around somewhere
> (local-mailer -> HA postfix relay) ?:

Not really, but it's basically going through the "basic
configuration readme" and answering

For local mailers:

What domain name to use in outbound mail: $your_domain.com

What domains to receive mail for: none at all

What clients to relay mail from: localhost only

What destinations to relay mail to: default (nothing)

What delivery method: indirect:  relayhost = [mailout.$your_domain.com]

For your HA relays:

What domain name to use in outbound mail: $your_domain.com

What domains to receive mail for: none at all

What clients to relay mail from: your local networks

What destinations to relay mail to: nothing (not applicable)

What delivery method: direct

Hope this helps.

Re: post-install, IPv6-only: could not find any active network interfaces (again)

[Wietse Venema]

Mark Martinec:
> > I'm assuming that you have "inet_protocols=ipv6" in main.cf, instead
> > of the backwards-compatibility "inet_protocols=ipv4" workaround,
> > because that would not work on your machine.
> 
> No, that was a fresh install attempt, no directory /etc/postfix
> or /usr/local/etc/postfix, no previous main.cf or master.cf files.
> 
> The problem is in the hardwired inet_protocols=ipv4 in the code,
> if I remember correctly.

There is no such hard coding, as we found out when the
Postfix build broke on freebsd.org test machines

Wietse 

Re: post-install, IPv6-only: could not find any active network interfaces (again)

[Mark Martinec]

> I'm assuming that you have "inet_protocols=ipv6" in main.cf, instead
> of the backwards-compatibility "inet_protocols=ipv4" workaround,
> because that would not work on your machine.

No, that was a fresh install attempt, no directory /etc/postfix
or /usr/local/etc/postfix, no previous main.cf or master.cf files.

The problem is in the hardwired inet_protocols=ipv4 in the code,
if I remember correctly.

  Mark

Re: post-install, IPv6-only: could not find any active network interfaces (again)

[Mark Martinec]

> > postfix: fatal: could not find any active network interfaces
> > *** Error code 1
> 
> How do you want to proceed: wait until I have time to reproduce
> your IPv6-only setup for which I have no specification, or spend
> all of next year doing blind testing?

No offense and not intending to rush things. I just thought that the
mentioned entry in HISTORY may indicate that you considered it
done.

If you want to test it by yourself, either fetch a pre-built 9.0-RC3
inet6-only installation ISO from:

  http://wiki.freebsd.org/IPv6Only

or re-build a 9.0 kernel by giving it the following KERNCONF file:

  include GENERIC
  ident GENERIC-IPV6ONLY
  makeoptions MKMODULESENV+="WITHOUT_INET_SUPPORT="
  nooptions INET
  nodevice gre

It is all documented in:

  http://www.freebsd.org/ipv6/ipv6only.html


Or I can make available a small VirtualBox disk image with the
necessary ports already installed, or provide a ssh root access to such.

  Mark

Re: post-install, IPv6-only: could not find any active network interfaces (again)

[Wietse Venema]

Wietse Venema:
> Mark Martinec:
> > Trying to install postfix-2.9-20111219 from ports on FreeBSD 9.0
> > (with an inet6-only kernel), the installation fails as before:
> > 
> > postfix-current$ make install
> > ...
> > Skipping /usr/local/share/doc/postfix/postfix-power.png...
> > Skipping /usr/local/share/doc/postfix/scache.8.html...
> > Skipping /usr/local/share/doc/postfix/tlsmgr.8.html...
> > postfix: fatal: could not find any active network interfaces
> > *** Error code 1
> 
> How do you want to proceed: wait until I have time to reproduce
> your IPv6-only setup for which I have no specification, or spend
> all of next year doing blind testing?

I'm assuming that you have "inet_protocols=ipv6" in main.cf, instead
of the backwards-compatibility "inet_protocols=ipv4" workaround,
because that would not work on your machine.

Wietse

Re: Loadbalancing+failover solution

[Michael Maymann]

Hi Lorens,

thanks for your kind reply...:-) !
yes this is exactly the case... and my internal local-mailers consist on
standard RHEL5+6 servers and NetApp's.
Our ISP is restricting mail from only 1 of our sites, so we need to relay
all our internal mail globally through this site.

We can't prevent non-mail applications, as we don't have 100% control of
all hosts (LAB equipment etc.), so I guess it makes sense to still keep
local-mailer, at-least just to keep consistency.
Thanks for clarifying...:-)

Do you have a howto for this setup laying around somewhere (local-mailer ->
HA postfix relay) ?:


Thanks in advance :-) !

~maymann


2011/12/27 Lorens Kockum 

> On Tue, Dec 27, 2011 at 06:12:12PM +0100, Michael Maymann wrote:
> > Hi all,
> >
> > Thanks Peter, for you kind reply - some setup you have there... sounds
> very
> > nice indeed...:-) !
> > - If i have a lower budget, can this then be achieved without the
> > loadbalancers and still have same redundancy/flexibility (using e.g. "DNS
> > RR"/"MX with equal value") - if so what is for/against/preferred ?:
>
> I looked over the rest of the thread and I suspect people are
> talking about different things.
>
> If I understand correctly, you want a relay. You have a lot
> of servers with a primary function that is not sending mail,
> but which do send mail, and you want to relay all the mail out
> through a set of controlled dedicated mail servers. Am I right?
>
> If so, the basic question is *how* the servers send mail. Either
> the applications send mail directly to a hostname (Java Mail
> or PHP for example), or they use the local mailer, which would
> be postfix, I suppose, with a default smarthost configuration
> pointing to your dedicated mail servers.
>
> Pros and Cons:
>
> - Not using local mailer wil permit loadbalancing mail sent from
> a single host over several postfix instances.
>
> - Using local mailer will always work for all applications
> (since applications that send to a hostname can send to
> 127.0.0.1)
>
> - Using local mailer forces you to monitor the daemon and the
> queues on all the machines, and takes up (probable negligable)
> system resources
>
> - Using local mailers will give you the UID of the sending
> process in the headers
>
> - Using local mailer protects you from a short outage of the
> dedicated servers or some part of the network. Mail will be
> spooled locally until the dedicated machines come back on line.
>
> - Conversely, not using a local mailer will protect you from
> local failures such as full disks or postfix not running,
> but expose you more to network problems and availability
> problems. That will cause you to look at redundant load
> balancers.
>
> - Using a load balancer will probably require you to mask source
> IPs. That doesn't matter if you trust your servers or if you run
> local firewalls forcing mail to run through the local mailer. If
> you worry about client-written forms being exploited to send
> spam you need to think about that.
>
> > DNS RR: so just have like load-sharing (mail1->postfix1, mail2->postfix2,
> > mail3->postfix1, etc.). But if one postfix servers goes down, will all
> DNS
> > replies then be only for alive-postfix - or will there also be
> dead-postfix
> > replies that needs to timeout, before it retries (and for how many
> times?)
> > and potentially end up dropping the mail if it is so unlucky to get
> replies
> > for dead-postfix on all retries ?
> > "MX with equal value": is this handling differently? does a request load
> > all MX records for the domain, and then sort them by value and then
> > alphabetically, ending up with: if one postfix is down it will
> > automatically try the next one in the sorted list...?
>
> If you use a redundant load balancer, it will take care of
> all that and "always" reply. Unless the network goes down, of
> course.
>
> If you do not, then there will be timeouts if something goes
> down. You can specify relayhosts with or without brackets; the
> brackets stop MX lookups. I seem to remember that in postfix
> a relayhost that resolves to several IP addresses will be
> handled more or less the same as a relayhost the has several MX
> records. I think that wondering about which is more efficient is
> not very useful since the difference is certainly vanishingly
> small. Using MX permits you to specify main servers and backup
> servers, but that's about it. However, non-mail applications
> that send mail directly will probably not be able to handle
> anything else than a single host/IP correctly.
>
> So . . . is there a unique answer . . . probably not, need more
> info on your situation and needs :-)
>

Re: post-install, IPv6-only: could not find any active network interfaces (again)

[Wietse Venema]

Mark Martinec:
> Trying to install postfix-2.9-20111219 from ports on FreeBSD 9.0
> (with an inet6-only kernel), the installation fails as before:
> 
> postfix-current$ make install
> ...
> Skipping /usr/local/share/doc/postfix/postfix-power.png...
> Skipping /usr/local/share/doc/postfix/scache.8.html...
> Skipping /usr/local/share/doc/postfix/tlsmgr.8.html...
> postfix: fatal: could not find any active network interfaces
> *** Error code 1

How do you want to proceed: wait until I have time to reproduce
your IPv6-only setup for which I have no specification, or spend
all of next year doing blind testing?

Wietse

post-install, IPv6-only: could not find any active network interfaces (again)

[Mark Martinec]

Reviving an old thread from 2011-09:

Mark Martinec:
> Trying to install postfix on an IPv6-only host
>   FreeBSD 9.0B1, http://wiki.freebsd.org/IPv6Only
>   ports: mail/postfix-current,
> but the installation chokes in the post-install phase.
> Running that failing command manually (in the ports work directory)
> gives:
>   # bin/postfix -v post-install
>   postfix: name_mask: ipv4
>   postfix: name_mask: host
>   postfix: inet_addr_local: configured 0 IPv4 addresses
>   postfix: fatal: could not find any active network interfaces

Wietse Venema wrote:
> The built-in default enables IPv4 only, to avoid headaches with
> systems that have IPv6 support but no external IPv6 connectivity.
> Lookup up  addresses would be wasteful, and trying to connect
> to them would be pointless.
> 
> A workaround is to do the same thing as when local_recipient_maps
> was introduced: the inet_protocols built-in default different from
> the installed configuration.
> 
> In this case, the built-in default would enable IPv6, while the
> post-install installed configuration is IPv4 only (but post-install
> would not change an explicit inet_protocols main.cf setting).

> > I was hoping this approach would make its way into current eventually ...
>It will. I have added the note to the wishlist.


I thought this was implemented in current by:

| HISTORY
| 20110914
|   Incompatibility: the default inet_protocols value is now
| "all" instead of "ipv4", meaning use both IPv4 and IPv6.
| As a compatibility workaround for sites without global IPv6
| connectivity, the commands "make upgrade" and "postfix
| upgrade-configuration" append "inet_protocols = ipv4" to
| main.cf when no explicit setting is present.  This compatibility
| workaround will be phased out in a future release.  Files:
| util/sys_defs.h, conf/post-install, proto/postconf.proto.
|
| Incompatibility: the default smtp_address_preference value
| is now "any" instead of "ipv6", meaning choose randomly
| between IPv6 and IPv4.  With this the Postfix SMTP client
| will have more success delivering mail to sites that have
| problematic IPv6 configurations.  Files: global/mail_params.h,
| proto/postconf.proto.

... but apparently it was not in its entirety.

Trying to install postfix-2.9-20111219 from ports on FreeBSD 9.0
(with an inet6-only kernel), the installation fails as before:

postfix-current$ make install
...
Skipping /usr/local/share/doc/postfix/postfix-power.png...
Skipping /usr/local/share/doc/postfix/scache.8.html...
Skipping /usr/local/share/doc/postfix/tlsmgr.8.html...
postfix: fatal: could not find any active network interfaces
*** Error code 1
Stop in /usr/ports/mail/postfix-current.

or manually in the /usr/ports/mail/postfix-current/work/postfix-2.9-20111219 :
# bin/postfix -v post-install
postfix: name_mask: ipv4
postfix: name_mask: host
postfix: inet_addr_local: configured 0 IPv4 addresses
postfix: fatal: could not find any active network interfaces


> It will. I have added the note to the wishlist.

So ... Dear Santa ...  :)

  Mark

Re: Loadbalancing+failover solution

[Lorens Kockum]

On Tue, Dec 27, 2011 at 06:12:12PM +0100, Michael Maymann wrote:
> Hi all,
> 
> Thanks Peter, for you kind reply - some setup you have there... sounds very
> nice indeed...:-) !
> - If i have a lower budget, can this then be achieved without the
> loadbalancers and still have same redundancy/flexibility (using e.g. "DNS
> RR"/"MX with equal value") - if so what is for/against/preferred ?:

I looked over the rest of the thread and I suspect people are
talking about different things.

If I understand correctly, you want a relay. You have a lot
of servers with a primary function that is not sending mail,
but which do send mail, and you want to relay all the mail out
through a set of controlled dedicated mail servers. Am I right?

If so, the basic question is *how* the servers send mail. Either
the applications send mail directly to a hostname (Java Mail
or PHP for example), or they use the local mailer, which would
be postfix, I suppose, with a default smarthost configuration
pointing to your dedicated mail servers.

Pros and Cons:

- Not using local mailer wil permit loadbalancing mail sent from
a single host over several postfix instances.

- Using local mailer will always work for all applications
(since applications that send to a hostname can send to
127.0.0.1)

- Using local mailer forces you to monitor the daemon and the
queues on all the machines, and takes up (probable negligable)
system resources

- Using local mailers will give you the UID of the sending
process in the headers

- Using local mailer protects you from a short outage of the
dedicated servers or some part of the network. Mail will be
spooled locally until the dedicated machines come back on line.

- Conversely, not using a local mailer will protect you from
local failures such as full disks or postfix not running,
but expose you more to network problems and availability
problems. That will cause you to look at redundant load
balancers.

- Using a load balancer will probably require you to mask source
IPs. That doesn't matter if you trust your servers or if you run
local firewalls forcing mail to run through the local mailer. If
you worry about client-written forms being exploited to send
spam you need to think about that.

> DNS RR: so just have like load-sharing (mail1->postfix1, mail2->postfix2,
> mail3->postfix1, etc.). But if one postfix servers goes down, will all DNS
> replies then be only for alive-postfix - or will there also be dead-postfix
> replies that needs to timeout, before it retries (and for how many times?)
> and potentially end up dropping the mail if it is so unlucky to get replies
> for dead-postfix on all retries ?
> "MX with equal value": is this handling differently? does a request load
> all MX records for the domain, and then sort them by value and then
> alphabetically, ending up with: if one postfix is down it will
> automatically try the next one in the sorted list...?

If you use a redundant load balancer, it will take care of
all that and "always" reply. Unless the network goes down, of
course.

If you do not, then there will be timeouts if something goes
down. You can specify relayhosts with or without brackets; the
brackets stop MX lookups. I seem to remember that in postfix
a relayhost that resolves to several IP addresses will be
handled more or less the same as a relayhost the has several MX
records. I think that wondering about which is more efficient is
not very useful since the difference is certainly vanishingly
small. Using MX permits you to specify main servers and backup
servers, but that's about it. However, non-mail applications
that send mail directly will probably not be able to handle
anything else than a single host/IP correctly.

So . . . is there a unique answer . . . probably not, need more
info on your situation and needs :-)

Re: Loadbalancing+failover solution

[Noel Jones]

On 12/27/2011 11:26 AM, Michael Maymann wrote:
> Hi all,
> 
> Reindl: Thanks for your reply.
> I guess this is for sending mails from postfix... my setup is
> regarding "linux server->postfix" (so receiving mails, seen from
> postfix point-of-view).
> - how many retries total/per day ?

Retries are controlled by the sending side.  The (postfix) receiver
cannot initiate a retry.


> - what is the difference if I do it "DNS RR"/"MX equal value", do
> you know ?

This affects the sender, not the receiver.  With postfix sending,
there is no difference.

Other software could possibly treat them differently.  There is
anecdotal evidence that some non-postfix software assumes {one MX
hostname, multiple A records} is a single multihome host, and won't
try the second IP if the first is down.



  -- Noel Jones

Re: Loadbalancing+failover solution

[Michael Maymann]

Hi all,

Reindl: Thanks for your reply.
I guess this is for sending mails from postfix... my setup is regarding
"linux server->postfix" (so receiving mails, seen from postfix
point-of-view).
- how many retries total/per day ?
- what is the difference if I do it "DNS RR"/"MX equal value", do you know ?

Thanks in advance :-) !
~maymann

2011/12/27 Reindl Harald 

>
>
> Am 27.12.2011 18:12, schrieb Michael Maymann:
> > But if one postfix servers goes down, will all DNS replies then be only
> for alive-postfix
> > or will there also be dead-postfix replies that needs to timeout, before
> it retries
> > (and for how many times?) and potentially end up dropping the mail
> > if it is so unlucky to get replies for dead-postfix on all retries ?
>
> normally a mailserver tries up to five days to deliver a message
>
>
>
>

Re: Ok. I'm finding a small issue on my server.

[/dev/rob0]

On Tuesday 27 December 2011 07:07:22 Jeroen Geilman wrote:
> On 2011-12-27 06:45, Glenn Sieb wrote:
> > While I have SASL set up on port 587, I recently found that
> > foreign IPs can connect, pretend to be, say, me, and send mail
> > to my users. SPF can catch this, but I think it's something that
> > should/can be caught by Postfix, no? So I conclude I have
> > fubar'd my SMTP config somehow.
> > 
> > How do I make it so this kind of transcript won't work unless
> > you're authenticating using SASL on port 587?
> > 
> > (connect not from my server to my server port 25)
> > ehlo example.org

Bjørn pointed out the use of HELO checks which can eliminate much of 
this, but does not affect the envelope sender issue, which may or may 
not come from a spoofed HELO host.

Both failed to point out that blocking your senders from outside will 
affect some same-envelope mail forwarding that might otherwise be 
considered legitimate. Another case might be one of your users, 
relaying through some remote ISP mailserver. You can set a policy to 
enforce this if you choose, but you need to understand what all it 
means, and you might need to communicate the policy to your users.

> > mail from:m...@example.org
> > rcpt to:m...@example.org
> > data
> > subject:Testing
> > 
> > testing
> 
> You may want to investigate the SASL login restrictions:
> 
>  sender_login_maps defines which from: addresses correspond to
> which SASL users.

That should be:
http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps

>  Adding reject_auth_login_mismatch to smtpd_mumble_restrictions

That should be:
http://www.postfix.org/postconf.5.html#reject_sender_login_mismatch
See also reject_authenticated_sender_login_mismatch and 
reject_unauthenticated_sender_login_mismatch

> [1] will then reject any attempt to send mail using those from:
> addresses unless the remote client is logged in with the
> corresponding SASL user.
> 
> [1] Where "mumble" is one of _client_ or _recipient_ ; it doesn't
> make much sense to use _helo_, and using _sender_ will actually
> increase the chances that you're doing it wrong; the sequence of
> restrictions is VERY important.
snip
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Loadbalancing+failover solution

[Reindl Harald]

Am 27.12.2011 18:12, schrieb Michael Maymann:
> But if one postfix servers goes down, will all DNS replies then be only for 
> alive-postfix 
> or will there also be dead-postfix replies that needs to timeout, before it 
> retries 
> (and for how many times?) and potentially end up dropping the mail
> if it is so unlucky to get replies for dead-postfix on all retries ?

normally a mailserver tries up to five days to deliver a message





signature.asc
Description: OpenPGP digital signature

Re: Loadbalancing+failover solution

[Michael Maymann]

Hi all,

Thanks Peter, for you kind reply - some setup you have there... sounds very
nice indeed...:-) !
- If i have a lower budget, can this then be achieved without the
loadbalancers and still have same redundancy/flexibility (using e.g. "DNS
RR"/"MX with equal value") - if so what is for/against/preferred ?:
DNS RR: so just have like load-sharing (mail1->postfix1, mail2->postfix2,
mail3->postfix1, etc.). But if one postfix servers goes down, will all DNS
replies then be only for alive-postfix - or will there also be dead-postfix
replies that needs to timeout, before it retries (and for how many times?)
and potentially end up dropping the mail if it is so unlucky to get replies
for dead-postfix on all retries ?
"MX with equal value": is this handling differently? does a request load
all MX records for the domain, and then sort them by value and then
alphabetically, ending up with: if one postfix is down it will
automatically try the next one in the sorted list...?

Thanks in advance :-) !
~maymann

Den 27. dec. 2011 10.29 skrev Peter Sørensen :

> Hi Michael,
>
> ** **
>
> We use a solution with 2 loadbalancers in front of 3+ postfix servers
>
> All MX records ( for around 100 domains ) are directed to the same address
> – the 
>
> address of the loadbalancers. Based on statistics for each server the
>
> mail is redirected to one of the 3-6 postfix servers we have running.
>
> Statistics for each server is written to Our Mysql Backend cluster where
> all postfix
>
> related files are located 
>
> ** **
>
> As long as just one postfix server is running - mail is in function. We
> are able to add
>
> more servers on the fly depending on load.
>
> ** **
>
> Best regards
>
> ** **
>
> ** **
>
> Peter Sørensen/Univ.Of.South.Denmark/email:mas...@sdu.dk 
>
> * *
>
> *Fra:* owner-postfix-us...@postfix.org [mailto:
> owner-postfix-us...@postfix.org] *På vegne af *Michael Maymann
> *Sendt:* 27. december 2011 08:47
> *Til:* Postfix users
> *Emne:* Re: Loadbalancing+failover solution
>
> ** **
>
> Hi All,
> Wietse: thanks for your replies - and sorry for not really knowing what
> I'm asking...:-)
> I guess my question is regarding receiving mail to PostFix: Linux
> servers->PostFix.
> is "DNS RoundRobin" or "MX record with equal value" preferred
>
>
> thanks in advance :-) !
>
> ~maymann
>
> 2011/12/23 Wietse Venema 
>
> Wietse:
>
> > According to these:
> >
> > http://www.postfix.org/postconf.5.html#smtp_mx_address_limit
> > http://www.postfix.org/postconf.5.html#smtp_mx_session_limit
> >
> > The Postfix SMTP client will try at least five IP addresses or two
> > SMTP sessions, When it reaches either limit, Postfix will
> > try another delivery later for several days.
> >
> > The retry schedule behaves as documented at:
> >
> > http://www.postfix.org/TUNING_README.html#hammer
>
> Michael Maymann:
>
> > Hi Wietse,
> >
> > thanks for your nice comments.
> >
> > I guess what you mention is valid for "my internal postfix relay
> > server"->"ISP mailserver" - or am I mistaken ?
>
> What I write is valid for the Postfix SMTP client, whether
> it sends mail to your ISP, or to your internal mail server.
>
>Wietse
>
> ** **
>

maildir postfix virtual domains

[Alex Vilceloiu]

Hello,

I have a mail server with postfix (mysql virtual 
users/domains)+courier+amavis-spamassassin-clamd.
It is possible to change the virtual mailbox path, currentl I have 
"virtual_mailbox_base = /mail"?
The mails are stored like "/mail/domain1/user1" "/mail/domain2/user1".
I want to be like "/home/$username/domainX/mailbox/.." where "$username" is a 
unix account.
Thank you.

Kind regards,
Alex.

Re: maildir postfix virtual domains

[/dev/rob0]

On Tuesday 27 December 2011 10:11:37 Alex Vilceloiu wrote:
> I have a mail server with postfix (mysql virtual
> users/domains)+courier+amavis-spamassassin-clamd. It is possible

Everything after the ")+" is mostly/probably irrelevant here.

> to change the virtual mailbox path, currentl I have
> "virtual_mailbox_base = /mail"? The mails are stored like
> "/mail/domain1/user1" "/mail/domain2/user1". I want to be like
> "/home/$username/domainX/mailbox/.." where "$username" is a unix
> account. Thank you.

It sounds like what you really wanted was local(8) delivery rather 
than virtual(8). Is there just one "$username" involved, or is that 
varied per recipient?

Surely, whatever you want to do can be done, but you should not be 
ambiguous in what you are asking. You must clarify before I can 
proceed. The generic answer is to cp(1)/mv(1) your mailstores to the 
proper locations, and to chown(1) them to the proper owners. Then set 
virtual_mailbox_base as needed, and adjust your virtual_mailbox_maps 
such that the desired locations are returned for each address.

If you want to reformulate your question, by all means, do so. But in 
the meantime see also these links:

Overview of your address class choices:
http://www.postfix.org/ADDRESS_CLASS_README.html
Choices for virtual domains and how to implement them:
http://www.postfix.org/VIRTUAL_README.html
If you decide to go for local(8) delivery, it is simple to set up:
http://www.postfix.org/BASIC_CONFIGURATION_README.html
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: maildir postfix virtual domains

[Wietse Venema]

Alex Vilceloiu:
> I want to be like "/home/$username/domainX/mailbox/.." where
> "$username" is a unix account.

Something like this:

virtual_mailbox_base = /home
virtual_mailbox_maps = 
.. some Postfix-SQL map that replies with username/domainX/mailbox/ ..
virtual_uid_maps = some Postfix-SQL map that replies with the user's UID
virtual_gid_maps = some Postfix-SQL map that replies with the user's GID

Wietse

Re: Ok. I'm finding a small issue on my server.

[Jeroen Geilman]

On 2011-12-27 06:45, Glenn Sieb wrote:

Dear list,

While I have SASL set up on port 587, I recently found that foreign
IPs can connect, pretend to be, say, me, and send mail to my users.
SPF can catch this, but I think it's something that should/can be
caught by Postfix, no? So I conclude I have fubar'd my SMTP config
somehow.

How do I make it so this kind of transcript won't work unless you're
authenticating using SASL on port 587?

(connect not from my server to my server port 25)
ehlo example.org
mail from:m...@example.org
rcpt to:m...@example.org
data
subject:Testing

testing


You may want to investigate the SASL login restrictions:

sender_login_maps defines which from: addresses correspond to which 
SASL users.


Adding reject_auth_login_mismatch to smtpd_mumble_restrictions [1] 
will then reject any attempt to send mail using those from: addresses 
unless the remote client is logged in with the corresponding SASL user.


[1] Where "mumble" is one of _client_ or _recipient_ ; it doesn't make 
much sense to use _helo_, and using _sender_ will actually increase the 
chances that you're doing it wrong; the sequence of restrictions is VERY 
important.


It often helps to apply the restrictions explicitly to the submission 
service, too:


submission inet - - - - smtpd
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

Coupled with the SASL sender restrictions above, this will do what you 
asked.



when I issue the ehlo,
I get this reply:

250-wingfoot.org
250-PIPELINING
250-SIZE 204800
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN


You may also want to consider adding

smtpd_tls_auth_only = yes

to main.cf; otherwise, all authentication communication is sent "in the 
clear".


--
J.

SV: Loadbalancing+failover solution

[Peter Sørensen]

Hi Michael,

We use a solution with 2 loadbalancers in front of 3+ postfix servers
All MX records ( for around 100 domains ) are directed to the same address - the
address of the loadbalancers. Based on statistics for each server the
mail is redirected to one of the 3-6 postfix servers we have running.
Statistics for each server is written to Our Mysql Backend cluster where all 
postfix
related files are located

As long as just one postfix server is running - mail is in function. We are 
able to add
more servers on the fly depending on load.

Best regards


Peter Sørensen/Univ.Of.South.Denmark/email:mas...@sdu.dk

Fra: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
På vegne af Michael Maymann
Sendt: 27. december 2011 08:47
Til: Postfix users
Emne: Re: Loadbalancing+failover solution

Hi All,
Wietse: thanks for your replies - and sorry for not really knowing what I'm 
asking...:-)
I guess my question is regarding receiving mail to PostFix: Linux 
servers->PostFix.
is "DNS RoundRobin" or "MX record with equal value" preferred


thanks in advance :-) !

~maymann
2011/12/23 Wietse Venema mailto:wie...@porcupine.org>>
Wietse:
> According to these:
>
> http://www.postfix.org/postconf.5.html#smtp_mx_address_limit
> http://www.postfix.org/postconf.5.html#smtp_mx_session_limit
>
> The Postfix SMTP client will try at least five IP addresses or two
> SMTP sessions, When it reaches either limit, Postfix will
> try another delivery later for several days.
>
> The retry schedule behaves as documented at:
>
> http://www.postfix.org/TUNING_README.html#hammer
Michael Maymann:
> Hi Wietse,
>
> thanks for your nice comments.
>
> I guess what you mention is valid for "my internal postfix relay
> server"->"ISP mailserver" - or am I mistaken ?
What I write is valid for the Postfix SMTP client, whether
it sends mail to your ISP, or to your internal mail server.

   Wietse