Smart Host Round-Robin In Mailertable?
Tim Daneliuk
hosts in the sendmail mailertable for all traffic. (For a variety of
reasons, the client does not want this done in either the .mc file or
directly in the .cf file.)
Can some kind soul point me to a resource that explains the syntax for
doing this?
Thanks,
--
------------------------------------------------------------------------
Tim Daneliuk
tun...@tundraware.com
Andrzej Adam Filip
> I have a situation where I need to set up round-robin across several smart
> hosts in the sendmail mailertable for all traffic. (For a variety of
> reasons, the client does not want this done in either the .mc file or
> directly in the .cf file.)
>
> Can some kind soul point me to a resource that explains the syntax for
> doing this?
AFAIR you may use (specially created/crafted) DNS "MX" or "A" record to get
"round robin" in mailertable.
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
Our business in life is not to succeed but to continue to fail in high spirits.
-- Robert Louis Stevenson
Joacim Ekroth
> I have a situation where I need to set up round-robin across several smart
> hosts in the sendmail mailertable for all traffic. (For a variety of
> reasons, the client does not want this done in either the .mc file or
> directly in the .cf file.)
>
> Can some kind soul point me to a resource that explains the syntax for
> doing this?
>
>
>
> Thanks,
Found this info when Googling around:
http://www.brandonhutchinson.com/Multiple_RHS_mailertable_entries.html
example.com esmtp:MX_record_1:MX_record_2
example.com esmtp:[host1]:[host2]
example.com esmtp:[192.168.1.1]:[192.168.1.2]
And I guess if you want do route all traffic to a "fake" RR,
something like this may do the trick:
. esmtp:[192.168.1.1]:[192.168.1.2]:[192.168.1.3]
(note the dot, it's a catch-all thingy)
Hope this helps.
//Joacim
Loki Harfagr
but the OP asked for a round-robin and it was my understanding that the
x:y:z RH was a failsafe not a RR?
Tim Daneliuk
I believe that is correct. Supposedly [xxxxxx],[yyyyy] will randomly choose
one of the addresses for each outbound email, but I do not think this feature
is documented or supported. Even if that works, though, what happens if
it is RRing between them and one of the hosts is down? Will the message
get enqueued and then retried on the working host?
Loki Harfagr
to change that opinion I'd say you may look the op/op files, section 5.1.2 and 5.1.5 ;-)
Hence I'd insist on thinking that there's no random here, first is the leftmost then
followers are fail-overs, down one by one.
Tim Daneliuk
That's only true if you use the : separator. But the rumor is that
the , separator yields the behavior I described. I just don't have
the patience to wade through all the source to figure out ... call
me lazy ;)
>
>> Even if that works, though,
>> what happens if it is RRing between them and one of the hosts is down?
>> Will the message get enqueued and then retried on the working host?
>
Per Hedeland
<tun...@tundraware.com> writes:
>On 10/28/2010 12:02 PM, Loki Harfagr wrote:
>> Thu, 28 Oct 2010 08:11:54 -0500, Tim Daneliuk did cat :
>>
>>> On 10/28/2010 4:34 AM, Loki Harfagr wrote:
>>>>
>>>> but the OP asked for a round-robin and it was my understanding that the
>>>> x:y:z RH was a failsafe not a RR?
>>>
>>> I believe that is correct. Supposedly [xxxxxx],[yyyyy] will randomly
>>> choose one of the addresses for each outbound email, but I do not think
>>> this feature is documented or supported.
>>
>> to change that opinion I'd say you may look the op/op files, section
>5.1.2 and 5.1.5 ;-)
>> Hence I'd insist on thinking that there's no random here, first is the
>leftmost then
>> followers are fail-overs, down one by one.
>
>That's only true if you use the : separator. But the rumor is that
>the , separator yields the behavior I described. I just don't have
>the patience to wade through all the source to figure out ... call
>me lazy ;)
Indeed you're correct - I did wade through a small subset of the 8.14.2
sources to figure that out:-), its actually in deliver.c:
if (sep == ':')
curpref++;
(elsewhere ':' or ',' is allowed as separator). And I certainly can't
find it in the documentation either (','-separation can be created
internally though, so mabye "not supported" is right).
>>> Even if that works, though,
>>> what happens if it is RRing between them and one of the hosts is down?
>>> Will the message get enqueued and then retried on the working host?
No, this stuff works just like MX records (equal-pref if ',' is used) -
all of them (well there is an upper limit) are tried in (random for
equal-pref) order at connect time until one succeeds, only if all of
them fail will the message be queued.
For "interesting" effects, you should also be able to combine use of ':'
and ',' as separators in the list - and of course the items in the list
can also be normal "host names", which are subject to normal MX lookup.
--Per Hedeland
p...@hedeland.org
Andrzej Adam Filip
Do you think "," separator should achieve "officially documented" status?
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
http://open-sendmail.sourceforge.net/ http://anfi.homeunix.org/
Thank goodness modern convenience is a thing of the remote future.
-- Pogo, by Walt Kelly
Tim Daneliuk
Yes! ... along with an explanation of its exact semantics for rollover,
recovery etc.
--
----------------------------------------------------------------------------
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
Andrzej Adam Filip
> On 10/29/2010 2:22 AM, Andrzej Adam Filip wrote:
>> p...@hedeland.org (Per Hedeland) wrote:
>>> Indeed you're correct - I did wade through a small subset of the 8.14.2
>>> sources to figure that out:-), its actually in deliver.c:
>>>
>>> if (sep == ':')
>>> curpref++;
>>>
>>> (elsewhere ':' or ',' is allowed as separator). And I certainly can't
>>> find it in the documentation either (','-separation can be created
>>> internally though, so mabye "not supported" is right).
>>
>> Do you think "," separator should achieve "officially documented" status?
>
> Yes! ... along with an explanation of its exact semantics for rollover,
> recovery etc.
Do you want it enough to "petition" sendmail.org (via email)?
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
http://open-sendmail.sourceforge.net/ http://anfi.homeunix.org/
Television -- the longest amateur night in history.
-- Robert Carson
Loki Harfagr
> Tim Daneliuk <tun...@tundraware.com> wrote:
>> On 10/29/2010 2:22 AM, Andrzej Adam Filip wrote:
>>> p...@hedeland.org (Per Hedeland) wrote:
>>>> [...]
>>>> Indeed you're correct - I did wade through a small subset of the
>>>> 8.14.2 sources to figure that out:-), its actually in deliver.c:
>>>>
>>>> if (sep == ':')
>>>> curpref++;
>>>>
>>>> (elsewhere ':' or ',' is allowed as separator). And I certainly can't
>>>> find it in the documentation either (','-separation can be created
>>>> internally though, so mabye "not supported" is right). [...]
>>>
>>> Do you think "," separator should achieve "officially documented"
>>> status?
>>
>> Yes! ... along with an explanation of its exact semantics for rollover,
>> recovery etc.
>
> Do you want it enough to "petition" sendmail.org (via email)?
that'd be a good thing to try on, at least to have a final point on
what would be the fate of the undocumented (or loosely doc'd) features,
will they survive an upgrade?
I had no problem using the 'failsafe :' mailertable trick as it
was "somewhat" fully (though discreetly) described in the op.me but to use a trick only
borne through the source could lead to delusion any old day the new
devs make room or just cleanse the code.
So, yes, the RR/failover fatures through special seps would be a
great stuff to add but only as far as it is solid ground, then
let's go and raise that petition, Andrzej :-)
Tim Daneliuk
> Tim Daneliuk <tun...@tundraware.com> wrote:
>> On 10/29/2010 2:22 AM, Andrzej Adam Filip wrote:
>>> p...@hedeland.org (Per Hedeland) wrote:
>>>> [...]
>>>> Indeed you're correct - I did wade through a small subset of the 8.14.2
>>>> sources to figure that out:-), its actually in deliver.c:
>>>>
>>>> if (sep == ':')
>>>> curpref++;
>>>>
>>>> (elsewhere ':' or ',' is allowed as separator). And I certainly can't
>>>> find it in the documentation either (','-separation can be created
>>>> internally though, so mabye "not supported" is right).
>>>> [...]
>>>
>>> Do you think "," separator should achieve "officially documented" status?
>>
>> Yes! ... along with an explanation of its exact semantics for rollover,
>> recovery etc.
>
> Do you want it enough to "petition" sendmail.org (via email)?
>
Sure, if someone can explain exactly how to go about doing this...
Andrzej Adam Filip
> On 10/29/2010 11:05 AM, Andrzej Adam Filip wrote:
>> Tim Daneliuk <tun...@tundraware.com> wrote:
>>> On 10/29/2010 2:22 AM, Andrzej Adam Filip wrote:
>>>> p...@hedeland.org (Per Hedeland) wrote:
>>>>> [...]
>>>>> Indeed you're correct - I did wade through a small subset of the 8.14.2
>>>>> sources to figure that out:-), its actually in deliver.c:
>>>>>
>>>>> if (sep == ':')
>>>>> curpref++;
>>>>>
>>>>> (elsewhere ':' or ',' is allowed as separator). And I certainly can't
>>>>> find it in the documentation either (','-separation can be created
>>>>> internally though, so mabye "not supported" is right).
>>>>> [...]
>>>>
>>>> Do you think "," separator should achieve "officially documented" status?
>>>
>>> Yes! ... along with an explanation of its exact semantics for rollover,
>>> recovery etc.
>>
>> Do you want it enough to "petition" sendmail.org (via email)?
>
> Sure, if someone can explain exactly how to go about doing this...
I do not know it "in practice" :-)
I merely dislike+ seeing yet another outburst of opinions in c.m.sendmail
without practical effect even if the effect would be nothing more than
(somehow) *official* refusal by sendmail.org.
P.S. I am not personally interested in making this particular
"undocumented feature" officially documented. If you are
"personally interested" then push the issue.
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
The full potentialities of human fury cannot be reached until a friend
of both parties tactfully interferes.
-- G. K. Chesterton
Per Hedeland
Sounds like a good idea, though I can't say that I care a lot one way or
the other. Originally I thought this was just "accidentally"
undocumented, but per the "created internally" above, I think that's not
the case. Either way, if you really need this functionality, it is
probably within your power to create MX records in your local DNS, so
why not just do that?
I have to confess that I couldn't quite fit the pieces from the sources
together to get the whole picture (i.e. I didn't try hard enough - the
deliver.c:deliver() function is 2370 lines long...). I did however
discern that the result of MX lookup creates a list of host names
separated by ':' and/or ',', where equal-MX-pref gets ',' and
higher-MX-pref gets ':' - and as far as I could see, this list is
processed by the same code that processes the "host" part of e.g. a
mailertable entry. But there has to be more to it than that, since the
individual elements in that "host" part should be subject to MX lookup
(unless prevented by []), which could produce a new ':'/','-separated
list, where the elements must *not* be subject to MX lookup. Oh well...
--Per
Tim Daneliuk
Because that is most assuredly not always the case. In very
large data centers - of the sort my various clients run -
there is a very high complexity to any change and it's very
important to minimize inter-environment dependencies to the
degree possible. If they do not, they quickly find themselves
with a multi-thousand server environment that is very brittle -
subject to failure if any one small change or dependency goes bad.
In the case I'm dealing with at the moment, an existing internal
mail gateway needs to be pointed at a pair of outbound
appliances and the only way this can be done quickly is without
involving the change management process for DNS updates.
>
> I have to confess that I couldn't quite fit the pieces from the sources
> together to get the whole picture (i.e. I didn't try hard enough - the
> deliver.c:deliver() function is 2370 lines long...). I did however
> discern that the result of MX lookup creates a list of host names
> separated by ':' and/or ',', where equal-MX-pref gets ',' and
> higher-MX-pref gets ':' - and as far as I could see, this list is
> processed by the same code that processes the "host" part of e.g. a
> mailertable entry. But there has to be more to it than that, since the
> individual elements in that "host" part should be subject to MX lookup
> (unless prevented by []), which could produce a new ':'/','-separated
> list, where the elements must *not* be subject to MX lookup. Oh well...
>
> --Per
I believe that the semantics work like this:
# Active Passive Failover
.foo relay:[quad1]:[quad2]:quad3]...
This appears to mean: Use the first smarthost that works,
beginning the search with quad1 and moving to the right.
This means that if host quadN isn't available, the attempt
fails over to quadN+1 until there is either a successful
delivery or - if all of them fail - the message is enqueued
for retry later.
# Round Robin / Load Balancing
.foo relay:[quad1],[quad2],quad3]...
Randomly select a smarthost for each outbound from quad1 .. quadX.
If the randomly selected host isn't available, choose again. If none
are available, enqueue the message for retry later.
At least I *think* this is how it works.
If this is correct, I'll try an put something together for Claus
and the sendmail team to include in the op document, but I need
confirmation that this is the way things work ...
Joe Zeff
> One way would be to use the SWIFT protocol. ;-)
Either that or you could always use IPoAC, as described in RFC 1194.
--
Joe Zeff -- The Guy With The Sideburns:
http://www.zeff.us http://www.lasfs.info
All property is theft, except mine.
Per Hedeland
<tun...@tundraware.com> writes:
>On 10/30/2010 1:25 PM, Per Hedeland wrote:
>>
>> Sounds like a good idea, though I can't say that I care a lot one way or
>> the other. Originally I thought this was just "accidentally"
>> undocumented, but per the "created internally" above, I think that's not
>> the case. Either way, if you really need this functionality, it is
>> probably within your power to create MX records in your local DNS, so
>> why not just do that?
>
>Because that is most assuredly not always the case. In very
>large data centers - of the sort my various clients run -
>there is a very high complexity to any change and it's very
>important to minimize inter-environment dependencies to the
>degree possible. If they do not, they quickly find themselves
>with a multi-thousand server environment that is very brittle -
>subject to failure if any one small change or dependency goes bad.
Well, on the other hand, from the maintenance perspective of a large
data center, it is generally an advantage to have this kind of config in
one place (DNS) instead of sprinkled over multi-thousand individual
sendmail.cf files.
>I believe that the semantics work like this:
>
># Active Passive Failover
>
>.foo relay:[quad1]:[quad2]:quad3]...
>
>This appears to mean: Use the first smarthost that works,
>beginning the search with quad1 and moving to the right.
>This means that if host quadN isn't available, the attempt
>fails over to quadN+1 until there is either a successful
>delivery or - if all of them fail - the message is enqueued
>for retry later.
Correct - this *is* documented, twice, as pointed out earlier in the
thread.
># Round Robin / Load Balancing
>
>.foo relay:[quad1],[quad2],quad3]...
>
>Randomly select a smarthost for each outbound from quad1 .. quadX.
>If the randomly selected host isn't available, choose again. If none
>are available, enqueue the message for retry later.
Yes - though I'd describe it as trying the hosts in a (single) random
order rather than making multiple random selections. The order will
differ between connection attempts, but for each connection attempt, a
random order is chosen and the hosts are tried in that order - exactly
as with equal-preference MX records.
>If this is correct, I'll try an put something together for Claus
>and the sendmail team to include in the op document, but I need
>confirmation that this is the way things work ...
It's easy enough to try it out, by specifying a list of unreachable/down
hosts or IP addresses and running sendmail with debug. E.g.
date | sendmail -Am -odi -d -O Timeout.connect=10s <address>
Where it gets "interesting" is if you have
relay:host1,host2
and each of host1 and host2 have multiple MX records, perhaps some of
them with the same preference...
And none of the above is a property of mailertable entries (which don't
have a leading dot in the LHS btw), but of IPC mailers. I.e. it works
also for e.g. SMART_HOST and all the other relays you can specify, and
for all the SMTP mailers.
--Per Hedeland
p...@hedeland.org
Tim Daneliuk
>> Because that is most assuredly not always the case. In very
>> large data centers - of the sort my various clients run -
>> there is a very high complexity to any change and it's very
>> important to minimize inter-environment dependencies to the
>> degree possible. If they do not, they quickly find themselves
>> with a multi-thousand server environment that is very brittle -
>> subject to failure if any one small change or dependency goes bad.
>>
>> In the case I'm dealing with at the moment, an existing internal
>> mail gateway needs to be pointed at a pair of outbound
>> appliances and the only way this can be done quickly is without
>> involving the change management process for DNS updates.
>
> virtual smarthost consisting of the real smarthosts (thos that are
> currently working). In a large datacenter this should be simple to set
> up as a new service - no impact to existing services.
>
> Ralf
That's a nice way to do it ... if you have budget and permission. In
this particular case, the task assigned is "make our internal sendmail
server point at the new security appliances instead of the outside
boundary mail machine". It is simply not practical to always
rearchitect an existing environment optimally. Many/most clients
prefer to incrementally change things.
--