Us1.workspace issue

Comments

• bikegremlin Member

  January 2

  @Francisco said:

  @kooky said:

  @bikegremlin said:

  @czed said:

  @Francisco said:

  @optisoft said: Some option to add high availability , add another machine to have a cluster ? or some figure that if some machine fail, not have everything down ?

  >

  We played with some sort of HA setup when we originally launched but it caused a lot of performance issues due to IO.

  The big fault earlier in the month was software related so HA wouldn't have fixed that. They put out a bad update, so we downgraded as we've done in the past. Downgrading caused bigger issues though.

  Ultimately they added a note to that release that downgrading is a BAD IDEA and will break things. If that notice was there at the start we wouldn't have attempted it.

  Past that hardware hasn't been an issue at all. If it wasn't for a pair of crappy OS drives this wouldn't have been an issue either.

  Still, we'll research to see what we can do w/o nuking our IO performance.

  Francisco

  Is it possible to setup a round-robin configuration to handle outgoing mail? If the main outgoing server is down, resend on backup server?

  I guess such a feature would need to be optional, opt-in, maybe with a custom outgoing host. But for things like no-reply emails (the bulk of what I send), it would be perfect.

  Namecrane also needs more MX records. Incoming mail should always have a fallback.

  Enabling SpamExperts gives you 4 MX records to add to your DNS.
  I don't know about the rest of the infrastructure or running without that spam filter, but that's what I saw as a user.

  I agree that sending out should be more stable for transactional emails - but not sure what the best way to handle that would be.

  mx1.mxfilter.net and mx3.mxfilter.net both resolve to 23.147.8.11, while mx2.mxfilter.net and mx4.mxfilter.net both resolve to 162.244.95.10.

  Although four MX records are published, they effectively map to only two unique mail hosts. From a redundancy and routing perspective, enabling SpamExperts results in two active endpoints, not four distinct servers.

  This was done so we can slot in other servers when needed without requiring end user changes

  Still, they’re in different regions.

  Francisco

  Yes - that sounds like good and prudent long-term planning.

  I will also add (correct me if I'm wrong) that the current recommended priorities (10 for mx1 and mx2 - and 20 for mx3 and mx4) are configured to assure that both receiving servers get evenly distributed number of incoming emails, based on their location.

  I see no faults in that setup, quite the countrary.

  Thanked by 1Intelpentiumm
• Intelpentiumm Member

  January 3

  Namecrane also needs more MX records. Incoming mail should always have a fallback.

  I plan to do this by adding second MX record for a service from Mxroute. I will just add a catch-all (like [email protected]) so that whenever NC email is down, it will land in @jar mail. But for a client with 36 inboxes, its hard to recreate all IDs in MXRoute server. If Jar doesnt support transport-map forward, i have to think about a catchall inbox. For emergency, sending still it can be used with a reply-to field to [email protected]
  if the original inbox at NC is up, it will receive the reply in it. Else it will get delivered at the catch-all address.

  @jar can you enable transport-map forward?
• jar Patron Provider, Top Host, Veteran

  January 3

  @Intelpentiumm said:
  

  Namecrane also needs more MX records. Incoming mail should always have a fallback.

  I plan to do this by adding second MX record for a service from Mxroute. I will just add a catch-all (like [email protected]) so that whenever NC email is down, it will land in @jar mail. But for a client with 36 inboxes, its hard to recreate all IDs in MXRoute server. If Jar doesnt support transport-map forward, i have to think about a catchall inbox. For emergency, sending still it can be used with a reply-to field to [email protected]
  if the original inbox at NC is up, it will receive the reply in it. Else it will get delivered at the catch-all address.

  @jar can you enable transport-map forward?

  Nah that's not among my priorities.

  Thanked by 1bikegremlin
• bikegremlin Member

  January 3

  @Intelpentiumm said:
  

  Namecrane also needs more MX records. Incoming mail should always have a fallback.

  I plan to do this by adding second MX record for a service from Mxroute. I will just add a catch-all (like [email protected]) so that whenever NC email is down, it will land in @jar mail. But for a client with 36 inboxes, its hard to recreate all IDs in MXRoute server. If Jar doesnt support transport-map forward, i have to think about a catchall inbox. For emergency, sending still it can be used with a reply-to field to [email protected]
  if the original inbox at NC is up, it will receive the reply in it. Else it will get delivered at the catch-all address.

  @jar can you enable transport-map forward?

  I haven't managed to "catch" any emails failing to be delivered to Cranemail.
  They do have two separate MX servers AFAIK.

  Transactional sending is more likely to be affected by the outages - and that is a problem IMO (and the reason why I don't rely on Cranemail for transactional emails).

  But failing to get emails is not really an issue.

  Catchall inbox sounds like a potential spam magnet and I fear enabling that for any use - colour me conservative.

  Relja

  Thanked by 1Intelpentiumm
• TimboJones Member

  January 3

  @bikegremlin said:

  @Intelpentiumm said:
  

  Namecrane also needs more MX records. Incoming mail should always have a fallback.

  I plan to do this by adding second MX record for a service from Mxroute. I will just add a catch-all (like [email protected]) so that whenever NC email is down, it will land in @jar mail. But for a client with 36 inboxes, its hard to recreate all IDs in MXRoute server. If Jar doesnt support transport-map forward, i have to think about a catchall inbox. For emergency, sending still it can be used with a reply-to field to [email protected]
  if the original inbox at NC is up, it will receive the reply in it. Else it will get delivered at the catch-all address.

  @jar can you enable transport-map forward?

  I haven't managed to "catch" any emails failing to be delivered to Cranemail.
  They do have two separate MX servers AFAIK.

  Transactional sending is more likely to be affected by the outages - and that is a problem IMO (and the reason why I don't rely on Cranemail for transactional emails).

  But failing to get emails is not really an issue.

  Catchall inbox sounds like a potential spam magnet and I fear enabling that for any use - colour me conservative.

  Relja

  A catchall on a business domain is likely a shitty experience, but it's fine for personal use.

  Thanked by 1Intelpentiumm