Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously
On 8/9/2011 9:28 PM, Ben Kennedy wrote: Bowie Bailey wrote at 9:47 AM (-0400) on 6/10/11: My solution to this problem is to take the secondary server offline. If the primary server goes down, the sending servers will queue the mail for you for a reasonable amount of time (generally at least 24 hours, although I think 3-5 days is most common). This should give you plenty of time to repair the primary server or activate the secondary as a temporary replacement. Since mail is not being delivered while the primary server is down in either case, does it really matter whose queue the mail sits in? That's a good point. On reflection, this is probably the most sensible solution. You've unearthed the nut of it in the final sentence above. Frankly, aside from expediting the delivery of mail following a failure of the primary, I can't think of a good reason why I've been adamant about accepting mail on two machines. You can leave the secondary MX record in place even if the server is offline. This will not have any negative side effects and may even help to reduce spam since spammers frequently try the lower-priority server first. In that case, I think what I may do is leave my configuration as it is, but simply shut down courier on the secondary machine. In a pinch I can simply start up courier again to begin queueing mail, or switch the secondary over to primary mode. This solution is so simple and obvious, I'm a bit flummoxed why it has taken me so long (several years) to come to this conclusion. Obviously, at various points in time, I've seen merit in having more than one machine online and capable of receiving mail, but I seem to have now forgotten what I thought they were. Just be careful with the second server. If there is something responding to port 25, it may cause problems. Make sure that a connection to that port simply fails and is not rejected in some manner. However, on second thought, since this is a secondary MX record, it should not be a major issue. Legitimate servers should try the primary first, so as long as the primary is running, the second server should see very few non-spam connection attempts. -- Bowie -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously
Ben Kennedy writes: u...@example.com: u...@mailhost.example.com That's an interesting and clever approach. Would this properly pass through ad hoc local-part extensions, e.g. for mail addressed to user- someth...@example.com - user-someth...@mailhost.example.com? No, it wouldn't. pgpCNdUQKpurU.pgp Description: PGP signature -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously
Sam Varshavchik wrote at 7:07 AM (-0400) on 8/10/11: That's an interesting and clever approach. Would this properly pass through ad hoc local-part extensions, e.g. for mail addressed to user- someth...@example.com - user-someth...@mailhost.example.com? No, it wouldn't. Well, that rules out that approach, then. thanks, -ben -- Ben Kennedy, chief magician Zygoat Creative Technical Services http://www.zygoat.ca -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously
Ben Kennedy writes: Sam Varshavchik wrote at 7:07 AM (-0400) on 8/10/11: That's an interesting and clever approach. Would this properly pass through ad hoc local-part extensions, e.g. for mail addressed to user- someth...@example.com - user-someth...@mailhost.example.com? No, it wouldn't. Well, that rules out that approach, then. thanks, Well, it depends on how much work you want to do. If there's only a handful of email addresses in that domain, you can set it up as a virtual domain, which simply maps it to a local mailbox, and you set up forwarding addresses via .courier files. With a careful arrangement of .courier-x-default files, and with careful usage of environment variable, you should be able to craft fairly sophisticated forwarding rules. pgpjsFoEJhZ1J.pgp Description: PGP signature -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously
Hey all, I'm folloiwng up on this thread I started about two months ago. I haven't had time to revisit it or implement any of your suggestions until now. So this is a delayed response, but thank you for the ideas, Bowe and Sam! Sam Varshavchik wrote at 10:05 PM (-0400) on 6/9/11: One thing you can do is redefine a local domain. If you are example.com, rather than defining example.com as a local domain, define instead mailhost.example.com as a hosted domain, and install an alias u...@example.com: u...@mailhost.example.com That's an interesting and clever approach. Would this properly pass through ad hoc local-part extensions, e.g. for mail addressed to user-someth...@example.com - user-someth...@mailhost.example.com? Bowie Bailey wrote at 9:47 AM (-0400) on 6/10/11: My solution to this problem is to take the secondary server offline. If the primary server goes down, the sending servers will queue the mail for you for a reasonable amount of time (generally at least 24 hours, although I think 3-5 days is most common). This should give you plenty of time to repair the primary server or activate the secondary as a temporary replacement. Since mail is not being delivered while the primary server is down in either case, does it really matter whose queue the mail sits in? That's a good point. On reflection, this is probably the most sensible solution. You've unearthed the nut of it in the final sentence above. Frankly, aside from expediting the delivery of mail following a failure of the primary, I can't think of a good reason why I've been adamant about accepting mail on two machines. You can leave the secondary MX record in place even if the server is offline. This will not have any negative side effects and may even help to reduce spam since spammers frequently try the lower-priority server first. In that case, I think what I may do is leave my configuration as it is, but simply shut down courier on the secondary machine. In a pinch I can simply start up courier again to begin queueing mail, or switch the secondary over to primary mode. This solution is so simple and obvious, I'm a bit flummoxed why it has taken me so long (several years) to come to this conclusion. Obviously, at various points in time, I've seen merit in having more than one machine online and capable of receiving mail, but I seem to have now forgotten what I thought they were. cheers, -ben -- Ben Kennedy, chief magician Zygoat Creative Technical Services http://www.zygoat.ca -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously
Hello Sam, your suggestion is genearaly working but if you have two mails like linux4miche...@tamay-dogan.net linux4miche...@tdexample.net then you run into problems wbch can be solved IF the whole lenght of the LOCALPART@DOMAIN does not exceed 32 characters. :-D If you have already an account linux4michelle on the Server like /home/linux4michelle/ which does the Backup-MX for the first server, create an account of /home/linux4miche...@tdexample.net/ and it just works! Please remeber, that this does ONLY work, if the name is maximum 32 characters long. Thanks, Greetings and nice Day/Evening Michelle Konzack -- # Debian GNU/Linux Consultant ## Development of Intranet and Embedded Systems with Debian GNU/Linux itsystems@tdnet Franceitsystems@tdnet Owner Michelle KonzackOwner Michelle Konzack Apt. 917 (homeoffice) Gewerbe Straße 3 50, rue de Soultz 77694 Kehl/Germany 67100 Strasbourg/France Tel: +49-177-9351947 mobil Tel: +33-6-61925193 mobil Tel: +49-176-86004575 office http://www.itsystems.tamay-dogan.net/ http://www.flexray4linux.org/ http://www.debian.tamay-dogan.net/ http://www.can4linux.org/ Jabber linux4miche...@jabber.ccc.de ICQ#328449886 Linux-User #280138 with the Linux Counter, http://counter.li.org/ signature.pgp Description: Digital signature -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously
On 6/9/2011 8:45 PM, Ben Kennedy wrote: Hey folks, Some of you may recall this discussion from last fall. I've got a problem, one that I guess my servers have exhibited for years, and I want to fix it. I have two machines, which I'll call primary and secondary. They are both MX for a number of domains; primary has a lower priority number (i.e. is a first choice for delivery), and holds the canonical backing store (maildirs, POP3/IMAP service, etc). Secondary is designed to also accept mail for these domains, and shunt any it happens to receive (by virtue of esmtproutes) to primary. Both have mailbox configuration provided by authmysql from a local replicated MySQL database. In case primary goes down, secondary will continue to queue mail and, at my option, may be quickly switched into primary behvaiour (to deliver locally and provide POP3/IMAP service) in the event that the original primary cannot be brought online in a timely fashion. I have used this pattern for several years now, with general success. The gaping hole, of course, is that the secondary will accept any mail for any mailbox on any of the domains. For domains with alias@... style catch-alls, this is fine. For the rest, it induces the primary into spewing out backscatter for any undliverable addresses. As I said, both machines share the mailbox config, and therefore have the capability of knowing what is a legitimate address and what isn't. But on the secondary, which has empty hosteddomains and esmtproutes pointing to the primary, it never bothers to do an account lookup (it only looks at the domain). How do I fix this? My solution to this problem is to take the secondary server offline. If the primary server goes down, the sending servers will queue the mail for you for a reasonable amount of time (generally at least 24 hours, although I think 3-5 days is most common). This should give you plenty of time to repair the primary server or activate the secondary as a temporary replacement. Since mail is not being delivered while the primary server is down in either case, does it really matter whose queue the mail sits in? The only downside is that it will take longer for all of the queued mail to be delivered once the primary is back online, but I consider that to be an acceptable trade-off for not having to worry about synchronizing account lists or sending backscatter. After all, how frequently does your mail server crash? You can leave the secondary MX record in place even if the server is offline. This will not have any negative side effects and may even help to reduce spam since spammers frequently try the lower-priority server first. If you truly need to avoid any downtime, you might want to consider having two primary servers with shared storage for the mailboxes. -- Bowie -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously
Hey folks, Some of you may recall this discussion from last fall. I've got a problem, one that I guess my servers have exhibited for years, and I want to fix it. I have two machines, which I'll call primary and secondary. They are both MX for a number of domains; primary has a lower priority number (i.e. is a first choice for delivery), and holds the canonical backing store (maildirs, POP3/IMAP service, etc). Secondary is designed to also accept mail for these domains, and shunt any it happens to receive (by virtue of esmtproutes) to primary. Both have mailbox configuration provided by authmysql from a local replicated MySQL database. In case primary goes down, secondary will continue to queue mail and, at my option, may be quickly switched into primary behvaiour (to deliver locally and provide POP3/IMAP service) in the event that the original primary cannot be brought online in a timely fashion. I have used this pattern for several years now, with general success. The gaping hole, of course, is that the secondary will accept any mail for any mailbox on any of the domains. For domains with alias@... style catch-alls, this is fine. For the rest, it induces the primary into spewing out backscatter for any undliverable addresses. As I said, both machines share the mailbox config, and therefore have the capability of knowing what is a legitimate address and what isn't. But on the secondary, which has empty hosteddomains and esmtproutes pointing to the primary, it never bothers to do an account lookup (it only looks at the domain). How do I fix this? thanks, -ben Malcolm Weir wrote at 11:53 AM (-0700) on 9/24/10: -Original Message- From: Alessandro Vesely [mailto:ves...@tana.it] Sent: Friday, September 24, 2010 2:40 AM In my experience, enterprises of size actually operate dedicated boundary servers as their MX platforms, and final delivery is handled by an entirely different set of servers often totally invisible to the outside user. While that's correct, those invisible servers are not _primary_ MXes on the public Internet. So, it is still unanswered why large enterprises may want to operate _secondary_ MXes, i.e. MXes with a higher preference number. Ummm... the invisible servers are not actually any kind of MX on the public Internet, primary or otherwise. There is a certain amount of confusion in this area because a lot of the mindset is structured around the notion that the primary MX is final recipient (the MDA), and other MX nodes end up relaying traffic to that primary. But if you use a purpose designed boundary server whose sole job is scanning and filtering, then forwarding the scanned mail to distinct delivery nodes, you may well choose to implement multiple such systems attached to different network providers and/or points-of-presence. In this model, the MX is just another MTA, quite distinct from the MDA and MSA. For example: suppose you have campuses in Los Angeles and New York. Each campus has its own connection to the Internet, but also a private network between the two. Even if you want the bulk of outside traffic, and all mail, to go to LA, it may make sense to have an MX based in NY with a lower priority that routes its traffic to LA over the private network. That way a service outage on the LA campus would not bring down all external mail acceptance. I don't think we're in disagreement with anything, here, other than perhaps the issue created by the fact that MX server has been conflated with delivery server, a fact that should surprise no-one who's seen the separation, over time, of the MTA, MDA and MSA parts of the system. Malc. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users -- Ben Kennedy (chief magician) zygoat creative technical services http://www.zygoat.ca -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously
Ben Kennedy writes: Hey folks, Some of you may recall this discussion from last fall. I've got a problem, one that I guess my servers have exhibited for years, and I want to fix it. I have two machines, which I'll call primary and secondary. They are both MX for a number of domains; primary has a lower priority number (i.e. is a first choice for delivery), and holds the canonical backing store (maildirs, POP3/IMAP service, etc). Secondary is designed to also accept mail for these domains, and shunt any it happens to receive (by virtue of esmtproutes) to primary. Both have mailbox configuration provided by authmysql from a local replicated MySQL database. In case primary goes down, secondary will continue to queue mail and, at my option, may be quickly switched into primary behvaiour (to deliver locally and provide POP3/IMAP service) in the event that the original primary cannot be brought online in a timely fashion. I have used this pattern for several years now, with general success. The gaping hole, of course, is that the secondary will accept any mail for any mailbox on any of the domains. For domains with alias@... style catch-alls, this is fine. For the rest, it induces the primary into spewing out backscatter for any undliverable addresses. As I said, both machines share the mailbox config, and therefore have the capability of knowing what is a legitimate address and what isn't. But on the secondary, which has empty hosteddomains and esmtproutes pointing to the primary, it never bothers to do an account lookup (it only looks at the domain). How do I fix this? Only a machine which has a domain configured as a local/hosted domain can know which address in the domain exists, or not. One thing you can do is redefine a local domain. If you are example.com, rather than defining example.com as a local domain, define instead mailhost.example.com as a hosted domain, and install an alias u...@example.com: u...@mailhost.example.com Mail addressed to u...@example.com gets rewritten to be addressed to u...@mailhost.example.com, which would be a valid local mailbox. Nonexistent addres...@example.com get rejected because example.com is not a local domain. Adresses that exist get rewritten and delivered. It should be a simple matter to write a script to dump your list of mailboxes, generate an alias entry for each valid mailbox, then run makealiases. I believe that if you do that, you can install the same alias table on your secondary, and on the secondary put mailhost.example.com into esmtpacceptmailfor, so that mail for that domain gets accepted and queued. If you've got mail queued up on the secondary, and want to make it a primary, you will need to stop courier, remove mailhost.example.com from esmtpacceptmailfor, and put it into hosteddomain, and start courier, and it should then deliver the queued up mail into local mailboxes. You'll need to do some experimenting to verify this, but I'm fairly certain that it'll work. pgpdoOa65UWPs.pgp Description: PGP signature -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] Backup MX, was Courier::Filter rejecting over-zealously
On 23/Sep/10 01:00, Malcolm Weir wrote: From: Ben Kennedy [mailto:b...@zygoat.ca] With respect, I still find this argument somewhat specious. Virtually every enterprise of any size on the internet still runs multiple MX servers. While I appreciate that having a single point of reception means a simpler configuration, it also foregoes some measure of redundancy and versatility. Are Google and Apple and IBM and the White House out of their minds? I suppose that perhaps Courier is the wrong product for any such business, but if so, it seems an unfortunate design exclusion. In any case, that's getting off track. In my experience, enterprises of size actually operate dedicated boundary servers as their MX platforms, and final delivery is handled by an entirely different set of servers often totally invisible to the outside user. While that's correct, those invisible servers are not _primary_ MXes on the public Internet. So, it is still unanswered why large enterprises may want to operate _secondary_ MXes, i.e. MXes with a higher preference number. It is possible to have multiple primary MXes (each one possibly multi-homed). For example, the White House doesn't seem to have secondary MXes: ;; QUESTION SECTION: ;whitehouse.gov.IN MX ;; ANSWER SECTION: whitehouse.gov. 10800 IN MX 105 mail1.eop.gov. whitehouse.gov. 10800 IN MX 105 mail2.eop.gov. whitehouse.gov. 10800 IN MX 105 mail3.eop.gov. whitehouse.gov. 10800 IN MX 105 mail4.eop.gov. (The same is true for ibm.com, but not for apple.com and gmail.com.) I agree that out-of-the-box Courier is the wrong product for a businesses running backup MXes, just like any other standard compliant SMTP server. The reason is that the traditional (non-filtering) design of secondary MXes is broken. This rules out the possibility of outsourcing backup MXes, which would be the most interesting solution for servers confined within a single RIR. -- http://fixforwarding.org/wiki/Backup_MX -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously
-Original Message- From: Alessandro Vesely [mailto:ves...@tana.it] Sent: Friday, September 24, 2010 2:40 AM In my experience, enterprises of size actually operate dedicated boundary servers as their MX platforms, and final delivery is handled by an entirely different set of servers often totally invisible to the outside user. While that's correct, those invisible servers are not _primary_ MXes on the public Internet. So, it is still unanswered why large enterprises may want to operate _secondary_ MXes, i.e. MXes with a higher preference number. Ummm... the invisible servers are not actually any kind of MX on the public Internet, primary or otherwise. There is a certain amount of confusion in this area because a lot of the mindset is structured around the notion that the primary MX is final recipient (the MDA), and other MX nodes end up relaying traffic to that primary. But if you use a purpose designed boundary server whose sole job is scanning and filtering, then forwarding the scanned mail to distinct delivery nodes, you may well choose to implement multiple such systems attached to different network providers and/or points-of-presence. In this model, the MX is just another MTA, quite distinct from the MDA and MSA. For example: suppose you have campuses in Los Angeles and New York. Each campus has its own connection to the Internet, but also a private network between the two. Even if you want the bulk of outside traffic, and all mail, to go to LA, it may make sense to have an MX based in NY with a lower priority that routes its traffic to LA over the private network. That way a service outage on the LA campus would not bring down all external mail acceptance. I don't think we're in disagreement with anything, here, other than perhaps the issue created by the fact that MX server has been conflated with delivery server, a fact that should surprise no-one who's seen the separation, over time, of the MTA, MDA and MSA parts of the system. Malc. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
