Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/16/apt-mirror-1.html

Working for a small non-profit, everyone has to wear lots of hats, and
one that I have to wear from time to time (since no one else here can)
is “sysadmin”. One of the perennial rules of system
administration is: you can never give users enough bandwidth. The
problem is, they eventually learn how fast your connection to the
outside is, and then complain any time a download doesn’t run at that
speed. Of course, if you have a T1 or better, it’s usually the other
side that’s the problem. So, I look to use our extra bandwidth during
off hours to cache large pools of data that are often downloaded. With
a organization full of Ubuntu machines, the Ubuntu repositories are an
important target for caching.

apt-mirror is a
program that mirrors large Debian-based repositories, including the
Ubuntu ones. There
are already
tutorials
available on how to set it up. What I’m writing about here is a way to
“force” users to use that repository.

The obvious way, of course, is to make
everyone’s /etc/apt/sources.list point at the mirrored
repository. This often isn’t a good option. Save the servers, the user
base here is all laptops, which means that they will often be on
networks that may actually be closer to another package repository and
perhaps I want to avoid interfering with that. (Although given that I
can usually give almost any IP number in the world better than the
30kbs/sec that ubuntu.com’s servers seem to quickly throttle to, that
probably doesn’t matter so much).

The bigger problem is that I don’t want to be married to the idea that
the apt-mirror is part of our essential 24/7 infrastructure. I don’t
want an angry late-night call from a user because they can’t install a
package, and I want the complete freedom to discontinue the server at
any time, if I find it to be unreliable. I can’t do this easily if
sources.list files on traveling machines are hard-coded with
the apt-mirror server’s name or address, especially when I don’t know
when exactly they’ll connect back to our VPN.

The easier solution is to fake out the DNS lookups via the DNS server
used by the VPN and the internal network. This way, user only get the
mirror when they are connected to the VPN or in the office; otherwise,
the get the normal Ubuntu servers. I had actually forgotten you could
fake out DNS on a per host basis, but asking my friend Paul reminded me
quickly. In /etc/bin/named.conf.local (on Debian/Ubuntu), I
just add:

        zone "archive.ubuntu.com"      {
                type master;
                file "/etc/bind/db.archive.ubuntu-fake";
        };
        

And in /etc/bind/db.archive.ubuntu-fake:

        $TTL    604800
        @ IN SOA archive.ubuntu.com.  root.vpn. (
               2008011001  ; serial number                                              
               10800 3600 604800 3600)
             IN NS my-dns-server.vpn.
        
        ;                                                                               
        ;  Begin name records                                                           
        ;                                                                               
        archive.ubuntu.com.  IN A            MY.EXTERNAL.FACING.IP
        

And there I have it; I just do one of those for each address I want to
replace (e.g., security.ubuntu.com). Now, when client machines
lookup archive.ubuntu.com (et al), they’ll
get MY.EXTERNAL.FACING.IP, but only
when my-dns-server.vpn is first in their resolv.conf.

Next time, I’ll talk about some other ideas on how I make the
apt-mirror even better.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/16/apt-mirror-1.html

Working for a small non-profit, everyone has to wear lots of hats, and
one that I have to wear from time to time (since no one else here can)
is “sysadmin”. One of the perennial rules of system
administration is: you can never give users enough bandwidth. The
problem is, they eventually learn how fast your connection to the
outside is, and then complain any time a download doesn’t run at that
speed. Of course, if you have a T1 or better, it’s usually the other
side that’s the problem. So, I look to use our extra bandwidth during
off hours to cache large pools of data that are often downloaded. With
a organization full of Ubuntu machines, the Ubuntu repositories are an
important target for caching.

apt-mirror is a
program that mirrors large Debian-based repositories, including the
Ubuntu ones. There
are already
tutorials
available on how to set it up. What I’m writing about here is a way to
“force” users to use that repository.

The obvious way, of course, is to make
everyone’s /etc/apt/sources.list point at the mirrored
repository. This often isn’t a good option. Save the servers, the user
base here is all laptops, which means that they will often be on
networks that may actually be closer to another package repository and
perhaps I want to avoid interfering with that. (Although given that I
can usually give almost any IP number in the world better than the
30kbs/sec that ubuntu.com’s servers seem to quickly throttle to, that
probably doesn’t matter so much).

The bigger problem is that I don’t want to be married to the idea that
the apt-mirror is part of our essential 24/7 infrastructure. I don’t
want an angry late-night call from a user because they can’t install a
package, and I want the complete freedom to discontinue the server at
any time, if I find it to be unreliable. I can’t do this easily if
sources.list files on traveling machines are hard-coded with
the apt-mirror server’s name or address, especially when I don’t know
when exactly they’ll connect back to our VPN.

The easier solution is to fake out the DNS lookups via the DNS server
used by the VPN and the internal network. This way, user only get the
mirror when they are connected to the VPN or in the office; otherwise,
the get the normal Ubuntu servers. I had actually forgotten you could
fake out DNS on a per host basis, but asking my friend Paul reminded me
quickly. In /etc/bin/named.conf.local (on Debian/Ubuntu), I
just add:

        zone "archive.ubuntu.com"      {
                type master;
                file "/etc/bind/db.archive.ubuntu-fake";
        };
        

And in /etc/bind/db.archive.ubuntu-fake:

        $TTL    604800
        @ IN SOA archive.ubuntu.com.  root.vpn. (
               2008011001  ; serial number                                              
               10800 3600 604800 3600)
             IN NS my-dns-server.vpn.
        
        ;                                                                               
        ;  Begin name records                                                           
        ;                                                                               
        archive.ubuntu.com.  IN A            MY.EXTERNAL.FACING.IP
        

And there I have it; I just do one of those for each address I want to
replace (e.g., security.ubuntu.com). Now, when client machines
lookup archive.ubuntu.com (et al), they’ll
get MY.EXTERNAL.FACING.IP, but only
when my-dns-server.vpn is first in their resolv.conf.

Next time, I’ll talk about some other ideas on how I make the
apt-mirror even better.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/16/apt-mirror-1.html

Working for a small non-profit, everyone has to wear lots of hats, and
one that I have to wear from time to time (since no one else here can)
is “sysadmin”. One of the perennial rules of system
administration is: you can never give users enough bandwidth. The
problem is, they eventually learn how fast your connection to the
outside is, and then complain any time a download doesn’t run at that
speed. Of course, if you have a T1 or better, it’s usually the other
side that’s the problem. So, I look to use our extra bandwidth during
off hours to cache large pools of data that are often downloaded. With
a organization full of Ubuntu machines, the Ubuntu repositories are an
important target for caching.

apt-mirror is a
program that mirrors large Debian-based repositories, including the
Ubuntu ones. There
are already
tutorials
available on how to set it up. What I’m writing about here is a way to
“force” users to use that repository.

The obvious way, of course, is to make
everyone’s /etc/apt/sources.list point at the mirrored
repository. This often isn’t a good option. Save the servers, the user
base here is all laptops, which means that they will often be on
networks that may actually be closer to another package repository and
perhaps I want to avoid interfering with that. (Although given that I
can usually give almost any IP number in the world better than the
30kbs/sec that ubuntu.com’s servers seem to quickly throttle to, that
probably doesn’t matter so much).

The bigger problem is that I don’t want to be married to the idea that
the apt-mirror is part of our essential 24/7 infrastructure. I don’t
want an angry late-night call from a user because they can’t install a
package, and I want the complete freedom to discontinue the server at
any time, if I find it to be unreliable. I can’t do this easily if
sources.list files on traveling machines are hard-coded with
the apt-mirror server’s name or address, especially when I don’t know
when exactly they’ll connect back to our VPN.

The easier solution is to fake out the DNS lookups via the DNS server
used by the VPN and the internal network. This way, user only get the
mirror when they are connected to the VPN or in the office; otherwise,
the get the normal Ubuntu servers. I had actually forgotten you could
fake out DNS on a per host basis, but asking my friend Paul reminded me
quickly. In /etc/bin/named.conf.local (on Debian/Ubuntu), I
just add:

        zone "archive.ubuntu.com"      {
                type master;
                file "/etc/bind/db.archive.ubuntu-fake";
        };
        

And in /etc/bind/db.archive.ubuntu-fake:

        $TTL    604800
        @ IN SOA archive.ubuntu.com.  root.vpn. (
               2008011001  ; serial number                                              
               10800 3600 604800 3600)
             IN NS my-dns-server.vpn.
        
        ;                                                                               
        ;  Begin name records                                                           
        ;                                                                               
        archive.ubuntu.com.  IN A            MY.EXTERNAL.FACING.IP
        

And there I have it; I just do one of those for each address I want to
replace (e.g., security.ubuntu.com). Now, when client machines
lookup archive.ubuntu.com (et al), they’ll
get MY.EXTERNAL.FACING.IP, but only
when my-dns-server.vpn is first in their resolv.conf.

Next time, I’ll talk about some other ideas on how I make the
apt-mirror even better.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/16/apt-mirror-1.html

Working for a small non-profit, everyone has to wear lots of hats, and
one that I have to wear from time to time (since no one else here can)
is “sysadmin”. One of the perennial rules of system
administration is: you can never give users enough bandwidth. The
problem is, they eventually learn how fast your connection to the
outside is, and then complain any time a download doesn’t run at that
speed. Of course, if you have a T1 or better, it’s usually the other
side that’s the problem. So, I look to use our extra bandwidth during
off hours to cache large pools of data that are often downloaded. With
a organization full of Ubuntu machines, the Ubuntu repositories are an
important target for caching.

apt-mirror is a
program that mirrors large Debian-based repositories, including the
Ubuntu ones. There
are already
tutorials
available on how to set it up. What I’m writing about here is a way to
“force” users to use that repository.

The obvious way, of course, is to make
everyone’s /etc/apt/sources.list point at the mirrored
repository. This often isn’t a good option. Save the servers, the user
base here is all laptops, which means that they will often be on
networks that may actually be closer to another package repository and
perhaps I want to avoid interfering with that. (Although given that I
can usually give almost any IP number in the world better than the
30kbs/sec that ubuntu.com’s servers seem to quickly throttle to, that
probably doesn’t matter so much).

The bigger problem is that I don’t want to be married to the idea that
the apt-mirror is part of our essential 24/7 infrastructure. I don’t
want an angry late-night call from a user because they can’t install a
package, and I want the complete freedom to discontinue the server at
any time, if I find it to be unreliable. I can’t do this easily if
sources.list files on traveling machines are hard-coded with
the apt-mirror server’s name or address, especially when I don’t know
when exactly they’ll connect back to our VPN.

The easier solution is to fake out the DNS lookups via the DNS server
used by the VPN and the internal network. This way, user only get the
mirror when they are connected to the VPN or in the office; otherwise,
the get the normal Ubuntu servers. I had actually forgotten you could
fake out DNS on a per host basis, but asking my friend Paul reminded me
quickly. In /etc/bin/named.conf.local (on Debian/Ubuntu), I
just add:

        zone "archive.ubuntu.com"      {
                type master;
                file "/etc/bind/db.archive.ubuntu-fake";
        };
        

And in /etc/bind/db.archive.ubuntu-fake:

        $TTL    604800
        @ IN SOA archive.ubuntu.com.  root.vpn. (
               2008011001  ; serial number                                              
               10800 3600 604800 3600)
             IN NS my-dns-server.vpn.
        
        ;                                                                               
        ;  Begin name records                                                           
        ;                                                                               
        archive.ubuntu.com.  IN A            MY.EXTERNAL.FACING.IP
        

And there I have it; I just do one of those for each address I want to
replace (e.g., security.ubuntu.com). Now, when client machines
lookup archive.ubuntu.com (et al), they’ll
get MY.EXTERNAL.FACING.IP, but only
when my-dns-server.vpn is first in their resolv.conf.

Next time, I’ll talk about some other ideas on how I make the
apt-mirror even better.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.