Sam Varshavchik wrote:
Mail forwarding is not a random event. Mail forwarding occurs,
presumably, at the ultimate recipient's request. It is the ultimate
recipient that places the forwarding in place, so that the recipient's
mail gets forwarded to a different destination.
That forwarding
Alessandro Vesely wrote:
Currently, the only way that one can concede forwarding is by IP
address. This may make sense for a fully controlled backup MX. In
general, the same IP address can be used to forward a message as well
as to submit a new one. The forwarded-to recipient has no way to
Alessandro Vesely writes:
Currently, the only way that one can concede forwarding is by IP
address.
That's beside the point. The bottom line is this. Your email address is
[EMAIL PROTECTED] If you need to have example.com forward all your mail to
[EMAIL PROTECTED], you'll just have to live
Sam Varshavchik wrote:
Mail forwarding is not a random event. Mail forwarding occurs, presumably,
at the ultimate recipient's request. It is the ultimate recipient that
places the forwarding in place, so that the recipient's mail gets
forwarded
to a different destination.
As such,
Bowie Bailey writes:
Sam Varshavchik wrote:
Mail forwarding is not a random event. Mail forwarding occurs, presumably,
at the ultimate recipient's request. It is the ultimate recipient that
places the forwarding in place, so that the recipient's mail gets
forwarded
to a different
Hi, running courier pop and imap running on some boxes with postfix.
I want my maildroprc file to send spam to a spam folder:
if (/^X-Spam-Status: Yes/)
{
to $MAILDIR/.Spam/
}
But how does maildrop become aware of the MAILDIR variable? I'm using
authdaemon with mysql backend (authmysql) and
Juan Miscaro writes:
Hi, running courier pop and imap running on some boxes with postfix.
I want my maildroprc file to send spam to a spam folder:
if (/^X-Spam-Status: Yes/)
{
to $MAILDIR/.Spam/
That should be to $MAILDIR/.Spam
You need to quote the pathname.
}
But how does maildrop
Julian Mehnle wrote:
Alessandro Vesely wrote:
Rewriting the sender's address currently works, but is wrong for
backup MXes. Isn't there room for designing a better solution?
One should always be able to fully trust one's backup MXes, not only for
_that_ reason but also because you want
