OT? /dev/null 5.1.1 email
<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
On Tue, 2005-07-05 at 09:42 -1000, Randy Bush wrote:
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.
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
On Tue, 2005-07-05 at 10:05 -1000, Randy Bush wrote:
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?
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.
On Tue, 2005-07-05 at 15:27 -0500, Adi Linden wrote:
The first one goes up and down more than it probably should. :-)
Make your secondary mx aware of all the valid recipient addresses.
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.
On Tue, 5 Jul 2005, Adi Linden wrote:
The first one goes up and down more than it probably should. :-)
Make your secondary mx aware of all the valid recipient addresses.
Are there mechanisms in postfix or sendmail to do this automatically, or should this be done out-of-band? I've tried looking for this feature, but found nothing; maybe I don't know the right terms to search for. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On 7/6/2005 1:32 AM, Pekka Savola wrote:
Make your secondary mx aware of all the valid recipient addresses.
Are there mechanisms in postfix or sendmail to do this automatically, or should this be done out-of-band? I've tried looking for this feature, but found nothing; maybe I don't know the right terms to search for.
Just about any MTA that is serious enough to be used also supports some kind of networked database for recipient lookups. With postfix, check the docs for local_recipient_maps. I don't remember how this is done in Sendmail, but it's possible there too. There can be a second step here, of separating the recipient lookups from the known (local) delivery mailboxes. Getting the lookups and the remote delivery to work together can be non-obvious and tricky. With postfix, check http://www.postfix.org/LDAP_README.html for a discussion on using virtual maps to make this work. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Wed, 6 Jul 2005, Pekka Savola wrote:
On Tue, 5 Jul 2005, Adi Linden wrote:
Make your secondary mx aware of all the valid recipient addresses.
Are there mechanisms in postfix or sendmail to do this automatically, or should this be done out-of-band? I've tried looking for this feature, but found nothing; maybe I don't know the right terms to search for.
Exim supports call-forward recipient verification, using syntax like "require verify = recipient/callout". This is very useful if you have any kind of organizational complexity in your email system which makes it hard for an MX to know which local parts are valid in all of its domains. For example, my MXs relay email to about 50 departmental email servers and act as a secondary MX for some other domains. We have no special knowledge of which addresses are valid in these domains, and it would be hard to make that possible because of the variety of software running on the departmental email servers. However if they are run well such that they completely verify their recipient addresses during the SMTP conversation, then so can we. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.
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
On Tue, 2005-07-05 at 12:02 -1000, Randy Bush wrote:
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.
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.
On Tue, 5 Jul 2005, Jim Popovitch wrote:
Presumably sending smtp servers do have spools, however given the range of things that send email these days... who really knows?
Things that send email without having a spool cannot route email according to RFC 974, so they are not a problem for MXs. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.
--On Tuesday, July 5, 2005 12:02 -1000 Randy Bush <randy@psg.com> wrote:
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.
Or, perhaps one wants more direct control over the how long you can be down before things bounce policy. A secondary MX allows that. The fuse on the sending spool is at the discretion of the person running the senders mailserver. The time limit on your secondary MX is, presumably, somewhat under your own control. There are other legitimate purposes as well. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery.
At 04:00 PM 7/5/2005, you wrote:
On Tue, 2005-07-05 at 09:42 -1000, Randy Bush wrote:
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.
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.
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.
At 4:35 PM -0400 2005-07-05, Daniel Senie wrote:
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.
Do an LDAP master database somewhere, then put LDAP slaves on each mail server that needs to access that information. Not too hard. -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.
On Tue, 2005-07-05 at 16:35 -0400, Daniel Senie wrote:
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.
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.
On Tue, 5 Jul 2005, Jim Popovitch wrote:
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.
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).
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. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
In message <Pine.WNT.4.63.0507052219510.5600@jvc>, Todd Vierling writes:
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.
The usual justification for a secondary MX is when the MX servers have some sort of special access to the ultimate recipients -- non-SMTP mail delivery, firewalls that they are privileged to pass, etc. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
On Jul 5, 2005, at 11:28 PM, Steven M. Bellovin wrote:
In message <Pine.WNT.4.63.0507052219510.5600@jvc>, Todd Vierling writes:
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.
The usual justification for a secondary MX is when the MX servers have some sort of special access to the ultimate recipients -- non-SMTP mail delivery, firewalls that they are privileged to pass, etc.
They're also mighty handy when dealing with planned, extended outages, such as moving to a new {building, ISP, etc.} or, say, losing power to the {only IX for Moscow, northeastern U.S.}, etc. It's much easier to configure your backup MXen to not toss messages or send warning emails after 4h than it is to politely ask all sending SMTP servers to do the same. -Dave
David Andersen wrote:
On Jul 5, 2005, at 11:28 PM, Steven M. Bellovin wrote:
<snip>
It's much easier to configure your backup MXen to not toss messages or send warning emails after 4h than it is to politely ask all sending SMTP servers to do the same.
-Dave
Apparently this has boiled down to - Some people feel perfectly comfortable trusting the sender's queuing (witness graylisting's popularity) - Some people feel more secure managing the queued mail. This is also nicer to the sender's queues. - Secondary MX's should make every possible effort not to add to spam blowblack -- popular mechanisms include smtp call aheads, LDAP, virtusertable maps and so on. If this is impossible serious thought should be given to the need for the MX in the first place. - Secondary MX's should take care not to be an end run against any anti abuse systems deployed by the primary MX path. - Typically similar effort that goes into enabling a secondary MX to perform recipient verification needs to be done anyway when having more than one primary MX for simple load balancing reasons. So not having "secondaries" at that point does not make much sense. - Building a setup depending on a failure mode for productive purposes is not wise. IOW, depending on collecting mal-clients for blacklisting who connect to your secondary when you believe that they shouldnt is potentialy problematic. So is designing a setup where you rely on failure of the primary MX reachability so that the secondary MX with better conectivity than the sender can simply relay it based on MX records.
On Tue, 05 Jul 2005 21:49:54 EDT, Jim Popovitch said:
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).
Wow. A whole whopping 1% of the RFC2821-recommended 4-5 days. How's that working out for you?
On Tue, 2005-07-05 at 23:30 -0400, Valdis.Kletnieks@vt.edu wrote:
On Tue, 05 Jul 2005 21:49:54 EDT, Jim Popovitch said:
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).
Wow. A whole whopping 1% of the RFC2821-recommended 4-5 days.
How's that working out for you?
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.
At 4:00 PM -0400 2005-07-05, Jim Popovitch wrote:
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. -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.
Brad Knowles wrote:
At 4:00 PM -0400 2005-07-05, Jim Popovitch wrote:
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.
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. 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. -Patrick
On Tue, 5 Jul 2005, Patrick Muldoon wrote:
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.
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. -- Simon J. Lyall. | Very Busy | Mail: simon@darkmere.gen.nz "To stay awake all night adds a day to your life" - Stilgar | eMT.
On Tue, 05 Jul 2005 22:47:48 EDT, Patrick Muldoon said:
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. ;)
On Wed, Jul 06, 2005 at 12:08:23AM -0400, Valdis.Kletnieks@vt.edu wrote:
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. ;)
Another: highest MX pointing to server which only responds after 5-10 secs with 451 instead of 220-hello -- MTAs will try different MX, spammers will try to send or disconnect, but mails will be rejected anyway. p. -- Beware of he who would deny you access to information, for in his heart he dreams himself your master. -- Commissioner Pravin Lal
On 7/5/2005 10:47 PM, Patrick Muldoon wrote:
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.
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 -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
participants (17)
-
Adi Linden -
Brad Knowles -
Daniel Senie -
David Andersen -
Eric A. Hall -
Jim Popovitch -
Joe Maimon -
Owen DeLong -
Patrick Muldoon -
Pekka Savola -
Piotr KUCHARSKI -
Randy Bush -
Simon Lyall -
Steven M. Bellovin -
Todd Vierling -
Tony Finch -
Valdis.Kletnieks＠vt.edu