[GRLUG] Sendmail as secondary (backup) MX

[Benjamin Eavey]

I guess that would work, but I'm not sure I want to do it yet until I 
learn more.  What I really want is for my server to be nothing but a 
backup, meaning that it will queue up mail sent to it, but then it will 
always blindly dump it off to the primary MX if it's available.

In my opinion, the primary MX should be sending these undeliverable 
messages for invalid addresses -- my server shouldn't need to worry 
about it.  The primaries are the ones where the email accounts 
physically live, so why is my backup server doing this extra work?

Maybe I'm just dreaming, but there must be a better way to do this...

Thanks!

-Ben


Olding, Jim wrote:
> You could add a catch-all address in sendmail's virtusertable file, and
> then set up a cron job to delete that user's mail file.
> 
> The downside of this is that anyone sending mail to that domain will
> never receive a bounce message, even if they legitimately mistyped an
> email address.
> 
> This also completely violates RFC 2821, which requires bounce messages
> to be sent if your system accepts mail for delivery and later finds that
> the address is invalid.
> 
> -----Original Message-----
> From: grlug-bounces at grlug.org [mailto:grlug-bounces at grlug.org] On Behalf
> Of Benjamin Eavey
> Sent: Tuesday, October 31, 2006 10:36 AM
> To: grlug at grlug.org
> Subject: [GRLUG] Sendmail as secondary (backup) MX
> 
> Has anyone set this up and worked out all the kinks?  I have a machine
> running Sendmail and acting as a backup MX for several domains. 
> Everything has been working fine, for the most part, but now I'm running
> into problems with the queue becoming overloaded.
> 
> It looks like a bunch of spam, and it appears to be a bunch of "550 -
> undeliverable" messages and other similar stuff.  Looks like the
> spammers are sending to non-existent addresses at the domains I host,
> which are then bouncing with "undeliverable" messages, which are then
> building up on my sendmail server, which is trying to deliver them to
> the spoofed originating email addresses.
> 
> I know this is bad, and I'm pulling my hair trying to figure out how to
> make this work properly, but I'm not getting anywhere.
> 
> Can anyone offer any suggestions?  Am I explaining this well enough that
> the problem makes sense?
> 
> Thanks,
> 
> -Ben