<disclaimer>
I know this is an email-only question, however the value of the feedback
from NANOG is greater than elsewhere, imho.
</disclaimer>
Should undeliverable email (5.1.1, User unknown) be directed
to /dev/null rather than responded to?
I was always under the impression that it was nice to respond with a
polite message, however these days it seems that 95% of the polite
responses are going to 5.1.1 addresses themselves.
Tia,
-Jim P.
Should undeliverable email (5.1.1, User unknown) be directed
to /dev/null rather than responded to?
one current fashion is to try to catch it as early in the smtp
receipt process as possible and reject the mail to the smtp
sender. this gives the rejection to the real source as opposed
to the joe job name.
randy
Thanks Randy,
It just dawned on me that rejects are in fact occurring early in the
receipt process on the primary MX. This is nicely done via Sendmail's
virtualusers table having a complete and accurate list of who is valid
for the domains handled by that MX.
However, is seems the problem is over on the secondary MX (Postfix)
which only has a list of legit relay domains for pMX. When pMX is back
online sMX fwds it's queue, but at that point pMX rejects to sMX...who
then rejects to Sender. I'm not sure how I can get away from that
happening.
-Jim P.
However, is seems the problem is over on the secondary MX (Postfix)
which only has a list of legit relay domains for pMX. When pMX is back
online sMX fwds it's queue, but at that point pMX rejects to sMX...who
then rejects to Sender. I'm not sure how I can get away from that
happening.
what is the purpose of having a secondary mx?
randy
The first one goes up and down more than it probably should. 
The principle purpose of the secondary mx, in this case, is to accept
email for the primary mx during periods where the primary is down, being
re-configured, or loadavg > 10. The primary handles a few chatty
mailinglists, and other than abuse@, postmaster@, admin@, there are no
real user accounts involved.
My only reason for not dropping the secondary mx is that, while I am a
big proponent of using your upstream SMTP server, those who deliver
directly would get "temporarily unavailable" messages (or worse). Of
course, at least on the primary, most of those that deliver directly are
dropped due to DUL RBLs.
-Jim P.
The first one goes up and down more than it probably should.
Make your secondary mx aware of all the valid recipient addresses.
Adi
Thank you Adi, Chris, Randy, Daniel, etc. 
Syncing virtual/valid users seems to be the preferred method for dealing
with this, as opposed to just dev/null'ing. Since the two systems are
relatively compatible, I'll look into just pushing the virtualtable to
the postfix system.
Thanks all,
-Jim P.
Use something like LDAP to do the lookups on the primary, or rsync over files so you can do the rejects on the secondary, perhaps. Given you said in another message your primary freaks on occasion, I guess the LDAP would need to be to some third server.
Generally there's little reason to run a secondary MX. Email will queue if the sole MX is offline or unreachable. Email will queue at senders' mail servers.
Also note that spammers like to use higher-ordered MX's as a way to get spam injected, probably the best argument for not bothering to run secondaries.
However, is seems the problem is over on the secondary MX (Postfix)
which only has a list of legit relay domains for pMX. When pMX is back
online sMX fwds it's queue, but at that point pMX rejects to sMX...who
then rejects to Sender.
Yup, and a lot of spammers take advantage of this fact by directly connecting to the secondary MXes of their targets, and never connecting to the primary MXes.
I'm not sure how I can get away from that
happening.
Short of having a complete list of all your valid recipients on the secondary MX, or having some way for them to obtain this information, I don't think you can. Also note that you have to completely replicate the full anti-spam/anti-virus configuration from the primary MXes to the secondary MXes, for the same reasons.
Do an LDAP master database somewhere, then put LDAP slaves on each mail server that needs to access that information. Not too hard.
The principle purpose of the secondary mx, in this case, is to accept
email for the primary mx during periods where the primary is down
and the sending smtp server has no spool. i.e. no useful
purpose.
today, the primary purpose of secondary mxs is to receive spam.
randy
The problem with the above is that your (or your users') email delivery
is then dependent upon the configuration and timeouts of someone else's
system (my system drops undeliverables after 1 hour). A backup mx
system gives you the capability of getting and keeping what you can,
when you can. What you do with it after that is all under your control.
-Jim P.
> The principle purpose of the secondary mx, in this case, is to accept
> email for the primary mx during periods where the primary is downand the sending smtp server has no spool. i.e. no useful
purpose.
Presumably sending smtp servers do have spools, however given the range
of things that send email these days... who really knows? What happens
when a blackberry system sends an email to a mx that's temporarily down?
Don't some routers support email notifications too, do they spool?
Multiply that by mis-configured Linux systems, Exchange servers,
text-paging, etc., etc. and all of a sudden the possibilities are
endless.
NOTE: I am a HUGE proponent of routing outbound smtp through the
upstream provider. However, I can not guarantee that all the senders to
my system agree with and follow that philosophy. I also desire to be
RFC compliant, but I also realize I can't force the world to follow.
today, the primary purpose of secondary mxs is to receive spam.
I agree, but that is probably only because (most) primary mxs have been
locked down. The problem of receiving spam, that is headed your way
anyway, and then rejecting it is no different from primary to secondary.
The means of rejecting it however could have an impact on other systems,
and that is why I started this thread in the first place. 
So, it comes down to this: Lock down the secondary mx(s), or delete
them.
-Jim P.
True -- however, too many people have so grossly misconfigured secondary MXs
in "traditional" operation mode, in the face of today's blowback bounce spam
world. Traditional secondary MXs are going the way of open relays, *quick*.
The default recommendation I give anyone these days is to use no
secondaries, and let the sender's mail server queue it up, as that's the
fastest implementation path. As a second stage, and only if the expertise
and time is available, then a backup MX with some sort of recipient
validation at SMTP time can be implemented.
Brad Knowles wrote:
Wow. A whole whopping 1% of the RFC2821-recommended 4-5 days.
How's that working out for you?
You might be able to connect to them but who knows what transient network
even might stop a remote site from connecting to your primaries long
enough that they try the secondary MX.
A related thing is that these days your mail system has to check the
validity of the address on SMTP connect time. I've used/seen a few email
setups where the front layer just checked the domain validity and the
layers further back checked the full address.
Doing that these days leaves you with a lot of email/spam to invalid
addresses you have to drop or bounce.
Actually quite well. Please understand that I am probably not utilizing
and providing email on this system exactly like you or anyone else is.
This system provides mailinglist services to dedicated subscribers.
Yes, they may experience their own email problems, if prolonged... they
can catch up on all that they missed in the mailinglist archives. Keeps
my log files clean.
-Jim P.
What about setting your highest order MX and lowest order MX to point to
the same set of mail servers, and hide your backup servers in the
middle.
Devious.
Even better if you can implement something that auto blacklists
people that connect to your "secondary" MX's when you know that your
primaries are up and accepting e-mail.
The problem there (especially if the primary and secondary aren't on the same
subnet/network) is that just because *you* know that your primary is up and
receiving, that doesn't mean that a network glitch didn't render it inaccessible
from the sending site. I'd hate to get blacklisted just because our main link
to the outside world hiccupped, and it happened to come up in time for us to
fall back to the secondary MX that you *TOLD* us to use.
http://wiki.apache.org/spamassassin/WrongMXPlugin is a SpamAssassin plugin
that "determines if an email was sent to a lower preference MX when a
higher preference MX was likely available."
Haven't used it but it's an interesting idea on my to-examine list
