Backup MX
Hello, is there a Tutorial somewhere to install opensmtpd as Backup MX? I find nothing really about it or I be blind. Thank you Silvio pgpdLMKXwMU7d.pgp Description: PGP signature
Re: Question about backup mx
Ok, thanks for the clarification. I guess one way to avoid the wait is to just manually schedule all. On Wed, Oct 31, 2018, 8:48 AM Gilles Chehade On Mon, Oct 22, 2018 at 01:36:07PM -0400, Matt Schwartz wrote: > > If I have two mail exchange servers and the primary one goes down, do > > I then have to manually issue an smtpctl schedule all to resume > > delivery from the backup to the primary? > > > > no, you just have to way for the backup one to realize the primary is up > which may take some time depending how long the primary was down. > > > > -- > Gilles Chehade > > https://www.poolp.org @poolpOrg >
Re: Question about backup mx
On Mon, Oct 22, 2018 at 01:36:07PM -0400, Matt Schwartz wrote: > If I have two mail exchange servers and the primary one goes down, do > I then have to manually issue an smtpctl schedule all to resume > delivery from the backup to the primary? > no, you just have to way for the backup one to realize the primary is up which may take some time depending how long the primary was down. -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Question about backup mx
If I have two mail exchange servers and the primary one goes down, do I then have to manually issue an smtpctl schedule all to resume delivery from the backup to the primary? -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: backup mx -- delivery loop
Michael Morak @ 2015-11-02T11:36:18 +0100: > Hi, > > I meant that you specify a value as a *number* like this: > > "relay backup 20" That is really meant to be a server name, not a number: /usr/src/usr.sbin/smtpd/parse.y:645 opt_relay : BACKUP STRING { rule->r_value.relayhost.flags |= F_BACKUP; if (strlcpy(rule->r_value.relayhost.hostname, $2, ^ sizeof (rule->r_value.relayhost.hostname)) >= sizeof (rule->r_value.relayhost.hostname)) { [...] Daniel -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: backup mx -- delivery loop
Hi, I meant that you specify a value as a *number* like this: "relay backup 20" and then, the backup server would relay to all MXs where the value is lower than 20. However, since you didn't specify a value (which, as I read it, should be a number), all mail gets relayed via the default server name. Cheers, Michael On 2 November 2015 at 09:25, LÉVAI Dániel wrote: > Michael Morak @ 2015-11-01T18:40:01 +0100: >> Hi Daniel, >> >> as far as I've seen from the manual, the syntax is "relay [backup >> [mx]]" and the description says: "Accepted mails are only relayed >> through servers with a lower preference value in the MX record for the >> domain than the one specified in mx. If mx is not specified, the >> default server name will be assumed." <- I read this to say "If mx is >> not specified, relay to the default server name." > > Hm, not quite. It says that it relays the mail to a server *with a lower > preference value* than the one specified as mx, or got from other sources > (mailname, gethostname(3), etc...). And that is what it should do, because > the mx1 will have a lower preference, than the mx2 (and I'm configuring > the mx2). > Unfortunately, it doesn't act per the man page; it seems it doesn't do > the MX lookup, and relays through itself again and again... > >> >> Further on in the manual it says this: >> >> "/etc/mail/mailname If this file exists, the first line is used as >> the server name. Otherwise, the server name is derived from the local >> hostname returned by gethostname(3), either directly if it is a fully >> qualified domain name, or by retrieving the associated canonical name >> through getaddrinfo(3)." >> >> I guess, since you didn't supply an mx value, OpenSMTPD tries to relay >> mail to the default server name, which in your case seems to resolve >> to the server running the backup MX (which is not unusual, and one can >> argue whether this is therefore a good default for the "backup" option >> without an "mx" value supplied). >> >> TL;DR: I guess you need to supply an mx value in your smtpd.conf for >> this to work as intended. > > Again, even if I had specified a value for 'mx', it must've only routed > the the mail through a server with a lower preference number. So if I > had specified mx1, then there wouldn't have been any servers that are > with a lower pref. value, in turn, if I had specified the mx2, it > would've acted like the same as with the default value. > > Daniel > >> On 1 November 2015 at 13:57, LÉVAI Dániel wrote: >> > LÉVAI Dániel @ 2015-10-31T10:24:35 +0100: >> >> Hi! >> >> >> >> I'm trying to setup a simple backup mx on OpenBSD 5.8-stable, but so far >> >> it seems more of a burden than a "simple" task :) >> >> >> >> smtpd.conf: >> >> 8< >> >> pki hostname certificate "/etc/ssl/smtpd_cert.pem" >> >> pki hostname key "/etc/ssl/private/smtpd_key.pem" >> >> >> >> listen on pppoe0 tls pki hostname >> >> >> >> table aliases db:/etc/mail/aliases.db >> >> >> >> accept for local alias deliver to mbox >> >> >> >> accept from any for domain "example.com" relay backup tls verify expire >> >> 30d >> >> >> >> accept from local for any relay >> >> 8< >> > >> > Alright, so the backup mx handling is clearly broken in opensmtpd. >> > Using "relay via" instead of "relay backup" works: >> > >> > accept from any for domain "example.com" \ >> > relay via "tls://mx1.example.com" pki hostname verify \ >> > expire 30d >> > >> > >> > Anyway, it would nice to hear some words on this from one of the devs. >> > Is this intended? How can one debug this further? >> > >> > >> > Daniel >> > >> > -- >> > You received this mail because you are subscribed to misc@opensmtpd.org >> > To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org >> > >> >> -- >> You received this mail because you are subscribed to misc@opensmtpd.org >> To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org >> > > -- > LÉVAI Dániel > PGP key ID = 0x83B63A8F > Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F > > -- > You received this mail because you are subscribed to misc@opensmtpd.org > To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org > -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: backup mx -- delivery loop
Michael Morak @ 2015-11-01T18:40:01 +0100: > Hi Daniel, > > as far as I've seen from the manual, the syntax is "relay [backup > [mx]]" and the description says: "Accepted mails are only relayed > through servers with a lower preference value in the MX record for the > domain than the one specified in mx. If mx is not specified, the > default server name will be assumed." <- I read this to say "If mx is > not specified, relay to the default server name." Hm, not quite. It says that it relays the mail to a server *with a lower preference value* than the one specified as mx, or got from other sources (mailname, gethostname(3), etc...). And that is what it should do, because the mx1 will have a lower preference, than the mx2 (and I'm configuring the mx2). Unfortunately, it doesn't act per the man page; it seems it doesn't do the MX lookup, and relays through itself again and again... > > Further on in the manual it says this: > > "/etc/mail/mailname If this file exists, the first line is used as > the server name. Otherwise, the server name is derived from the local > hostname returned by gethostname(3), either directly if it is a fully > qualified domain name, or by retrieving the associated canonical name > through getaddrinfo(3)." > > I guess, since you didn't supply an mx value, OpenSMTPD tries to relay > mail to the default server name, which in your case seems to resolve > to the server running the backup MX (which is not unusual, and one can > argue whether this is therefore a good default for the "backup" option > without an "mx" value supplied). > > TL;DR: I guess you need to supply an mx value in your smtpd.conf for > this to work as intended. Again, even if I had specified a value for 'mx', it must've only routed the the mail through a server with a lower preference number. So if I had specified mx1, then there wouldn't have been any servers that are with a lower pref. value, in turn, if I had specified the mx2, it would've acted like the same as with the default value. Daniel > On 1 November 2015 at 13:57, LÉVAI Dániel wrote: > > LÉVAI Dániel @ 2015-10-31T10:24:35 +0100: > >> Hi! > >> > >> I'm trying to setup a simple backup mx on OpenBSD 5.8-stable, but so far > >> it seems more of a burden than a "simple" task :) > >> > >> smtpd.conf: > >> 8< > >> pki hostname certificate "/etc/ssl/smtpd_cert.pem" > >> pki hostname key "/etc/ssl/private/smtpd_key.pem" > >> > >> listen on pppoe0 tls pki hostname > >> > >> table aliases db:/etc/mail/aliases.db > >> > >> accept for local alias deliver to mbox > >> > >> accept from any for domain "example.com" relay backup tls verify expire 30d > >> > >> accept from local for any relay > >> 8< > > > > Alright, so the backup mx handling is clearly broken in opensmtpd. > > Using "relay via" instead of "relay backup" works: > > > > accept from any for domain "example.com" \ > > relay via "tls://mx1.example.com" pki hostname verify \ > > expire 30d > > > > > > Anyway, it would nice to hear some words on this from one of the devs. > > Is this intended? How can one debug this further? > > > > > > Daniel > > > > -- > > You received this mail because you are subscribed to misc@opensmtpd.org > > To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org > > > > -- > You received this mail because you are subscribed to misc@opensmtpd.org > To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org > -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: backup mx -- delivery loop
Hi Daniel, as far as I've seen from the manual, the syntax is "relay [backup [mx]]" and the description says: "Accepted mails are only relayed through servers with a lower preference value in the MX record for the domain than the one specified in mx. If mx is not specified, the default server name will be assumed." <- I read this to say "If mx is not specified, relay to the default server name." Further on in the manual it says this: "/etc/mail/mailname If this file exists, the first line is used as the server name. Otherwise, the server name is derived from the local hostname returned by gethostname(3), either directly if it is a fully qualified domain name, or by retrieving the associated canonical name through getaddrinfo(3)." I guess, since you didn't supply an mx value, OpenSMTPD tries to relay mail to the default server name, which in your case seems to resolve to the server running the backup MX (which is not unusual, and one can argue whether this is therefore a good default for the "backup" option without an "mx" value supplied). TL;DR: I guess you need to supply an mx value in your smtpd.conf for this to work as intended. -- Michael On 1 November 2015 at 13:57, LÉVAI Dániel wrote: > LÉVAI Dániel @ 2015-10-31T10:24:35 +0100: >> Hi! >> >> I'm trying to setup a simple backup mx on OpenBSD 5.8-stable, but so far >> it seems more of a burden than a "simple" task :) >> >> smtpd.conf: >> 8< >> pki hostname certificate "/etc/ssl/smtpd_cert.pem" >> pki hostname key "/etc/ssl/private/smtpd_key.pem" >> >> listen on pppoe0 tls pki hostname >> >> table aliases db:/etc/mail/aliases.db >> >> accept for local alias deliver to mbox >> >> accept from any for domain "example.com" relay backup tls verify expire 30d >> >> accept from local for any relay >> 8< > > Alright, so the backup mx handling is clearly broken in opensmtpd. > Using "relay via" instead of "relay backup" works: > > accept from any for domain "example.com" \ > relay via "tls://mx1.example.com" pki hostname verify \ > expire 30d > > > Anyway, it would nice to hear some words on this from one of the devs. > Is this intended? How can one debug this further? > > > Daniel > > -- > You received this mail because you are subscribed to misc@opensmtpd.org > To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org > -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: backup mx -- delivery loop
LÉVAI Dániel @ 2015-10-31T10:24:35 +0100: > Hi! > > I'm trying to setup a simple backup mx on OpenBSD 5.8-stable, but so far > it seems more of a burden than a "simple" task :) > > smtpd.conf: > 8< > pki hostname certificate "/etc/ssl/smtpd_cert.pem" > pki hostname key "/etc/ssl/private/smtpd_key.pem" > > listen on pppoe0 tls pki hostname > > table aliases db:/etc/mail/aliases.db > > accept for local alias deliver to mbox > > accept from any for domain "example.com" relay backup tls verify expire 30d > > accept from local for any relay > 8< Alright, so the backup mx handling is clearly broken in opensmtpd. Using "relay via" instead of "relay backup" works: accept from any for domain "example.com" \ relay via "tls://mx1.example.com" pki hostname verify \ expire 30d Anyway, it would nice to hear some words on this from one of the devs. Is this intended? How can one debug this further? Daniel -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
backup mx -- delivery loop
Hi! I'm trying to setup a simple backup mx on OpenBSD 5.8-stable, but so far it seems more of a burden than a "simple" task :) smtpd.conf: 8< pki hostname certificate "/etc/ssl/smtpd_cert.pem" pki hostname key "/etc/ssl/private/smtpd_key.pem" listen on pppoe0 tls pki hostname table aliases db:/etc/mail/aliases.db accept for local alias deliver to mbox accept from any for domain "example.com" relay backup tls verify expire 30d accept from local for any relay 8< The MX records are set for example.com correctly, with the priority set to 10 for the primary MX, and 20 for this, the secondary. The $(hostname) is the same as in the MX record. So what this configuration does currently, is it loops the mail back to itself [1], like it had never done an actual MX lookup for example.com, and determined that there are MX servers with higher priority to relay the mail to. I thought it would work like this: -> accepting the mail from outside of the box, if the rcpt is the domain @example.com -> DNS lookup for MX record, check if there are higher priority servers -> relay mail to MX server with higher priority ... -> ... otherwise if it cannot do it, queue it for 30 days. Clearly I am missing something, but what? Daniel [1]: Oct 31 09:09:13 host smtpd[1612]: smtp-in: New session f7f7a554f37e98c7 from host client [client_ip] Oct 31 09:09:13 host smtpd[1612]: smtp-in: Started TLS on session f7f7a554f37e98c7: version=TLSv1/SSLv3, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256 Oct 31 09:09:26 host smtpd[1612]: smtp-in: Accepted message 99f80132 on session f7f7a554f37e98c7: from=, to=, size=66, ndest=1, proto=ESMTP Oct 31 09:09:26 host smtpd[1612]: smtp-out: Connecting to tls://ip:25 (hostname) on session f7f7a55764209204... Oct 31 09:09:26 host smtpd[1612]: smtp-out: Connected on session f7f7a55764209204 Oct 31 09:09:26 host smtpd[1612]: smtp-in: New session f7f7a558578d8e10 from host hostname [ip] Oct 31 09:09:26 host smtpd[1612]: smtp-in: Started TLS on session f7f7a558578d8e10: version=TLSv1/SSLv3, cipher=ECDHE-RSA-CHACHA20-POLY1305, bits=256 Oct 31 09:09:26 host smtpd[1612]: smtp-out: Started TLS on session f7f7a55764209204: version=TLSv1/SSLv3, cipher=ECDHE-RSA-CHACHA20-POLY1305, bits=256 Oct 31 09:09:26 host smtpd[1612]: smtp-in: Client certificate verification succeeded on session f7f7a558578d8e10 Oct 31 09:09:26 host smtpd[1612]: smtp-out: Server certificate verification succeeded on session f7f7a55764209204 Oct 31 09:09:26 host smtpd[1612]: smtp-in: Accepted message 31901619 on session f7f7a558578d8e10: from=, to=, size=346, ndest=1, proto=ESMTP Oct 31 09:09:26 host smtpd[1612]: relay: Ok for 99f80132578a8c22: session=f7f7a55764209204, from=, to=, rcpt=<->, source=ip, relay=ip (hostname), delay=6s, stat=250 2.0.0: 31901619 Message accepted for delivery Oct 31 09:09:27 host smtpd[1612]: smtp-in: Accepted message 1d0aeed4 on session f7f7a558578d8e10: from=, to=, size=632, ndest=1, proto=ESMTP Oct 31 09:09:27 host smtpd[1612]: relay: Ok for 31901619061e4baf: session=f7f7a55764209204, from=, to=, rcpt=<->, source=ip, relay=ip (hostname), delay=1s, stat=250 2.0.0: 1d0aeed4 Message accepted for delivery Oct 31 09:09:28 host smtpd[1612]: smtp-in: Accepted message 7263a1e6 on session f7f7a558578d8e10: from=, to=, size=918, ndest=1, proto=ESMTP Oct 31 09:09:28 host smtpd[1612]: relay: Ok for 1d0aeed4f9fac231: session=f7f7a55764209204, from=, to=, rcpt=<->, source=ip, relay=ip (hostname), delay=1s, stat=250 2.0.0: 7263a1e6 Message accepted for delivery Oct 31 09:09:29 host smtpd[1612]: smtp-in: Accepted message d74d740a on session f7f7a558578d8e10: from=, to=, size=1204, ndest=1, proto=ESMTP Oct 31 09:09:29 host smtpd[1612]: relay: Ok for 7263a1e6c37169f7: session=f7f7a55764209204, from=, to=, rcpt=<->, source=ip, relay=ip (hostname), delay=1s, stat=250 2.0.0: d74d740a Message accepted for delivery Oct 31 09:09:30 host smtpd[1612]: smtp-in: Accepted message 72bce114 on session f7f7a558578d8e10: from=, to=, size=1490, ndest=1, proto=ESMTP Oct 31 09:09:30 host smtpd[1612]: relay: Ok for d74d740acfc489b0: session=f7f7a55764209204, from=, to=, rcpt=<->, source=ip, relay=ip (hostname), delay=1s, stat=250 2.0.0: 72bce114 Message accepted for delivery Oct 31 09:09:31 host smtpd[1612]: smtp-in: Accepted message 86d4de5a on session f7f7a558578d8e10: from=, to=, size=1776, ndest=1, proto=ESMTP Oct 31 09:09:31 host smtpd[1612]: relay: Ok for 72bce114deb2a617: session=f7f7a55764209204, from=, to=, rcpt=<->, source=ip, relay=ip (hostname), delay=1s, stat=250 2.0.0: 86d4de5a Message accepted for delivery Oct 31 09:09:32 host smtpd[1612]: smtp-in: Accepted message b676ae8e on session f7f7a558578d8e10: from=, to=, size=2062, ndest=1, proto=ESMTP Oct 31 09:09:32 host smtpd[1612]: re
Re: OpenSMTPd as a backup MX
Hi Gilles, > > Is your machine named "mx2.backdom.fr" ? > Your guess is perfectly right :) The machine is not named "mx2.backdom.fr". > > The configuration file and logs are very important to debug this, there > is so much we can guess :-p > I will send these in private. Thank you, Denis -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: OpenSMTPd as a backup MX
On Thu, May 29, 2014 at 11:10:10PM +0200, Denis Fondras wrote: > Hi, > Hi, > I'd like some explanation on how opensmtpd works as a backup mx. I use > opensmtpd-201405202105p1 compiled myself on Debian7. > Can you share the configuration file ? I'm not sure I understand what happens. > First I had "accept from any for domain "dom.fr" relay backup" in my > config file. But after a few minutes I get a message back complaining > that there is a loop. > > No, this can't be. mx1 (weight 5) isn't the same as mx2 (weight 10). > Without the log it's tricky to debug but I'll throw a guess here: Is your machine named "mx2.backdom.fr" ? If you use: accept [...] relay backup OpenSMTPD will do a MX lookup and try to find a MX that matches its own hostname to determine its own weight. If your local hostname isn't in the list of entries returned, it will assume a very very low weight and will assume any of the results in the MX lookup are ok to deliver to. > So I went with "accept from any for domain "dom.fr" relay backup > mx2.backdom.fr" so it never tries to deliver to mx2 again (if I get the > man right). > Actually, that's not exactly what it means. It means "Nevermind my real hostname, I'm the backup mx2.backdom.fr" and so it'll pickup the weight of mx2.backdom.fr. This is equivalent to having: accept [...] relay backup if your hostname is mx2.backdom.fr > Why do I have to specify the mx, what is the point ? From my point of > view, a backup mx MUST (as in RFC MUST) always try to deliver to a lower > pref mx thank itself and keep it until it can deliver (or timeout). > You are right about what a backup MX must do and this is what it does as far as no bug is concerned. As for why you must specify the MX, this is simple: OpenSMTPD cannot guess what backup MX it is supposed to be unless it has the name it operates under. So it has two strategies: 1- either use its own local name (`hostname`) 2- or use a name you declare in the configuration file You're not required to declare a name in the configuration file but then your system must be configured so that 1- is valid. > So after adding the mx to backup, I don't have the loop-error but > opensmtpd tries to deliver not to mx1.domain.tld but to domain.tld > (which doesn't exist). I had to add a A record to have mails delivered. > That's strange, it typically attempts domain.tld if it fails to find any valid MX to handle the mail. > > $ host dom.fr > dom.fr mail is handled by 5 mx1.dom.fr. > dom.fr mail is handled by 10 mx2.backdom.fr. > dom.fr mail is handled by 15 mx3.backdom2.fr. > The configuration file and logs are very important to debug this, there is so much we can guess :-p -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
OpenSMTPd as a backup MX
Hi, I'd like some explanation on how opensmtpd works as a backup mx. I use opensmtpd-201405202105p1 compiled myself on Debian7. First I had "accept from any for domain "dom.fr" relay backup" in my config file. But after a few minutes I get a message back complaining that there is a loop. No, this can't be. mx1 (weight 5) isn't the same as mx2 (weight 10). So I went with "accept from any for domain "dom.fr" relay backup mx2.backdom.fr" so it never tries to deliver to mx2 again (if I get the man right). Why do I have to specify the mx, what is the point ? From my point of view, a backup mx MUST (as in RFC MUST) always try to deliver to a lower pref mx thank itself and keep it until it can deliver (or timeout). So after adding the mx to backup, I don't have the loop-error but opensmtpd tries to deliver not to mx1.domain.tld but to domain.tld (which doesn't exist). I had to add a A record to have mails delivered. $ host dom.fr dom.fr mail is handled by 5 mx1.dom.fr. dom.fr mail is handled by 10 mx2.backdom.fr. dom.fr mail is handled by 15 mx3.backdom2.fr. Thank you in advande, Denis -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org