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 <[email protected]> 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 <[email protected]> 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 <aliases> 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 [email protected] >> > To unsubscribe, send a mail to: [email protected] >> > >> >> -- >> You received this mail because you are subscribed to [email protected] >> To unsubscribe, send a mail to: [email protected] >> > > -- > 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 [email protected] > To unsubscribe, send a mail to: [email protected] > -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
