Fallback

jlasman

Phfeww.. a lot of repeation there ;) I hope he will now understand it!

Icheb

Great idea and probably the best solution ;) (Don't really now what gain you'll get with that kind of fallback)

I would like to see something like, while it's in queue you can somehow POP into the queue and pull out your messages. This would be great when a server is down and you'll have one of those companies that need their mail every business hour ;)

I've seen a Qmail setup working like that and those scripts weren't pretty ;)
 
jlasman said:
So I don't see any advantage.

Jeff
Click to expand...

I'll try it one last time then:

You won't miss a single email.

What I meant with my statement about 'not intending to solve that problem', was that I don't expect the main server (high priority) to be down often, so I'll take the extra spam during downtime for granted.
However, that is before Sebastian pointed out the fact that spammers can also simply target the secondary server (low priority).

About the RR-case, I simply picked a few hosts which had multiple MX records, didn't quite check for fallback or not.
If however you take a look at ev1 & google, you'll see that they do in fact utilise fallback mx.
But you're right, bad-picked examples ;)

@fusionictnl, repetition from both sides, mere mis-interpretation/communication if you ask me.
 
PeterT said:
I'll try it one last time then:

You won't miss a single email.

What I meant with my statement about 'not intending to solve that problem', was that I don't expect the main server (high priority) to be down often, so I'll take the extra spam during downtime for granted.
However, that is before Sebastian pointed out the fact that spammers can also simply target the secondary server (low priority).

About the RR-case, I simply picked a few hosts which had multiple MX records, didn't quite check for fallback or not.
If however you take a look at ev1 & google, you'll see that they do in fact utilise fallback mx.
But you're right, bad-picked examples ;)

@fusionictnl, repetition from both sides, mere mis-interpretation/communication if you ask me.
Click to expand...

It was just a small joke ;) You both try to explain yourselfs pretty repeatetly to each other ;)
 
In my position I'd like secundairy (fallback) MX for just one reason:
It sometimes happens a server is down, not all mailsenders' servers retry, so there has to be something catching the mails.

It's not a loadbalancing solution. I don't need mail loadbalacing (at the moment), I don't want clusters for one simple reason: If the cluster goes down, your company is down, if one server goes down some customers are down, the rest won't notice a thing.

If you need loadbalancing, you need to set up some kind of 'same level MX' thingy, and accept mail for everything, and write it directly to the right target location, I don't see that happening with DA any time soon.

I've seen a Qmail setup working like that and those scripts weren't pretty
Click to expand...
Most Qmail scripts aren't pretty[/flame] ;)
Problem is, this could be seen as a flaw in the SMTP protocol, a server should try the high priority MX first, if that fails (for reasons like 'overload' or 'temp local problem'), it should try the lower priority to handle it. Instead of saving it back to queue and retry or consider it failed (in my opinion, that is).

So if you want loadbalancing, this ain't the way to go, if you want backups (for when primairy is physically down), backup MX is the way to go.

p.s. I know this message doesn't have an logical structure, it's too hot here, can't think...
 
You must log in or register to reply here.
Back
Top