On Thursday, May 24 at 03:29 PM, quoth Matthew Yette:
I'm interested in setting up a disaster recovery/business continuity
function on the server. Meaning, if I am filtering mail for company
A (example.com), and Company A's mail server goes down, obviously my
filter box will continue to queue mail for 48 hours. In the
meantime, however, I wanted to give Company A access to that queued
mail via a webmail interface.
Be warned, this is a recipe for all kinds of confusion. (e.g so-and-so
thought they deleted that mail, and then it gets delivered, or they
can't remember if they replied to it, etc.) Make things too easy, and
you'll quickly be providing all their email needs (i.e. "why repair
the old broken server, when we can just use this other one?"). If
that's the plan, then cool. But it's something to consider.
Here comes the problem: While a user from company A can log into the
webmail interface, they can't reply to any emails that happen to be
in there, due to the fact that they'd be sending FROM a bogus domain
(user@example.backup) and many email servers will reject this. The
solution, it would seem, is to have the vpopmail domain match the
real world domain, example.com. However, if the example.com domain
lives on the actual filter box, then it ignores the smtproutes entry
for that domain, and only delivers it locally.
Your FROM address does not have to match anything. It can be entirely
made up if you like (this is why phishing is possible).
Is there a way to filter for a domain (example.com), and pass the
messages along via smtproutes to that company's mail server, while
also maintaining a copy of each message (via qmail-tap?) in a
vpopmail domain of the same name (example.com) that lives local on
that box, so that messages could still be sent from the web
interface?
...what? What makes you think you *can't* do that already?
~Kyle
--
I prefer to be called "EVIL GENIUS!"
-- Jumba, from "Lilo & Stitch"
pgpatMnHKzNzq.pgp
Description: PGP signature
|