Hi Josesph, Welfare or Warfare? :-)) Tom Thomas W Shinder, M.D. Site: www.isaserver.org Blog: http://spaces.msn.com/members/drisa/ Book: http://tinyurl.com/3xqb7 MVP -- ISA Firewalls **Who is John Galt?** > -----Original Message----- > From: Joseph Danielsen [mailto:JDanielsen@xxxxxxxxxxxxxxxx] > Sent: Wednesday, January 04, 2006 9:44 AM > To: [ISAserver.org Discussion List] > Subject: [isalist] How I spent my Christmas vacation - Email > found in subject > > http://www.ISAserver.org > > WOW - > This was not a thread - this was a semester. It made me feel like a > welfare student watching the professor's debate. > > (John T) Thanks for not beating me up on this one... I learned my > leason. > > Joseph F. Danielsen, MCSA-Messaging, MCP > Network Blade Inc. > 49 Marcy Street > Somerset, NJ 08873 > (732) 213-0600 > www.NetworkBlade.Com > > > -----Original Message----- > From: John T (Lists) [mailto:johnlist@xxxxxxxxxxxxxxxxxxx] > Sent: Wednesday, January 04, 2006 3:50 AM > To: [ISAserver.org Discussion List] > Subject: [SPAM-HC] - [isalist] RE: How I spent my Christmas vacation - > Email found in subject > > http://www.ISAserver.org > > Replying to several posts and some of my replies may be mute by others > that > have already responded: (NOTE: My responses are not against any one at > all. > I have seen otherwise experts on most e-mail subjects take the wrong > stance > on accepting all e-mail and then rejecting. If I offend any > one, I have > no > intention too. We all need to help one another so that we can become > stronger in our combined fight with the bad guys.) > > (Dr Tom) You bet! The DNS stuff can drive you crazy. That's one nice > thing > about the Exchange SMTP service, that you can disable NDR's. You can't > do > that with the IIS SMTP service. I'm hoping that the Longhorn IIS SMTP > service will allow for the same functionality. > > There is some confusion as to the generation of NDR's. Normally, the > only > time a receiving SMTP server will generate a NDR is if AFTER > it receives > the > message, it is unable to deliver the message to the final destination. > This > is for the most part concerning relay or gateway SMTP servers. 99% of > the > time, the NDR is generated by the sending e-mail server when it is > unable to > complete the passing of the message to the receiving SMTP server, > whether > through permanent error such as not a valid user or account > disabled to > temporary errors such as user over quote or disk error and so forth. > Where > the confusion comes from is not in the generation of NDR's, but in the > receiving e-mail server being poorly configured to receive > all, and then > reject. The biggest abuser of this is Yahoo.com. The second biggest > abuse is > a Default Exchange server. If receiving e-mail servers were properly > configured to reject an incoming message that it would be unable to > deliver > for invalid user and other such code 5 permanent failures, that would > greatly clear up the confusion. > > (Joseph) That sounds like my experience when I configured GFI > MailEssentials > to "generate NDR" on my Bayesian filter. > > BAD BAD BAD. By generating an NDR based on anti-spam or anti-virus > scanning/filtering, you are in essence adding to the spam > problem. Most > of > today's spam and virus laden e-mails are from forged from > addresses. As > such, you are then sending NDR's to a forged address, often times an > unsuspecting victim. > > (Joseph) In my case, I do filter Recp not in AD, but I read > GFI's manual > which suggested that sending the NDR to spammers would simply convince > them > to take the email address off of their list. Even IF that > were true (and > it's not) the cost was too high. > > THIS IS ABSOLUTLE STUPIDITY! I dare some one from GFI to back this one > up. I > am more than willing to discuss their suggestion about > generating NDR's. > I > do not know whether to cry at the lack of understanding or > laugh at the > foolishness. > > (Dr. Tom)No. The inbound SMTP relays are in a DMZ away from the core > critical assets, such as Exchange, SharePoint and Active > Directory. The > relays accept mail only for my domains, and then scrub for viruses and > spam. > While the LDAP queries would prevent this issue, I don't consider the > inbound relays as part of the same security zone as the Exchange > Servers. > Why? Because the spam whackers are 1. Internet facing, and 2. must > accept > anonymous inbound connections. > > But that does not mean a inbound relay or gateway server can > not be user > aware. There are ways of doing it, and in today's environment > it MUST be > done. And yes, you do it by LDAP query but it does not have to be real > time, > it could be a scheduled task updating a static list. > > (Dr. Tom) I don't think it's a false sense of security. The design was > not > perfect from a configuration point of view, not a security point of > view. > Internet facing hosts that accept anonymous inbound connections should > never > be located on the same security zone as core information > assets. I pity > the > fool who thinks otherwise :)) > > A receiving e-mail server is required by RFC to accept e-mail from <> > (anonymous) for valid users. There are many legit reasons for this. A > properly configured receiving e-mail server with appropriate anti-spam > and > anti-virus scanning/filtering has not security or otherwise > problem with > this. > > (Dr. Tom) So, you allow LDAP queries from hosts on an anonymous access > DMZ. > How do you mitigate the security issues involved with that. > Yes, I know > the > convention wisdom in some circles say don't accept mail to > non-existing > accounts, but then you have to allow LDAP from a very low > security zone. > A > very poor compromise. > > But an LDAP query can be restricted to what it can access. > > (Dan) 1. I have to send NDRs out to people sending in mis-typed > addresses, > we deal a lot with get general public, people make typos on e-mail > addresses > all the time. Without the NDRs, many people would send e-mail and > "assume" > it went through, and plan their activites according to those > assumptions. > We don't know if the originating addresses are valid until we > attempt to > send the NDR. > > Incorrect thought process. If you do not accept the invalidly > addressed > message in the first place, the burden is on the sending e-mail server > where > it should be. That server would then generate and send an NDR back to > the > sender. > > (Dan) 2. Due to the wide variety of SMTP servers connecting to us, we > cannot > "require" them to use a certain type of protocol just to send > us e-mail. > Thus, we allow everything to come in, and then deal with the results. > Too > many people in the education industry run the cheapest > software they can > get, whether it is freeware or stuff that is 10-15 years old > it doesn't > matter. As long as it is free. > > What protocol, SMTP? Sorry, there is a standard and all must follow. > Connect, handshake, mail from, mail to, data. If mail to is > not a known > valid address, reject. > > (Dan) 3. Unfortunately, no-one can identify spammers by their e-mail > address or originating server, so it is impossible to tell if we're > sending > e-mail to spammers or not. > > Most likely, you are sending to forged and possibly unsuspecting > "victims." > If, and that is a big if, you are sending back to a valid address, you > just > confirmed information he/she wants. :)) > > (Dan) The proposed backscatter solution is just a dream. > While I agree > that > it IS a problem, and that there are several ways around it, > there is no > "practical" solution at this time. Unless we can get EVERYONE running > completely compatible DNS servers, it will remain an illusive > dream. In > the > meantime, we contribute to the e-mail backscatter problem daily not by > choice but by necessity. Blocking e-mail that doesn't come from a > "compatible" server is entirely out of the question for us right now. > > Not a dream at all, just do not accept for a non-valid > address. And what > does this have to do with DNS servers? Nothing. Nothing > except the extra > load you are placing on them trying to find records for > domains that may > or > may not exist, and which if exist may be constructed to cause DNS > issues. > > (Greg) What I did was write a script that runs on a windows box > internally, > that yoinks all smtp addresses out of the AD for given domain names > (like > all krystaltek.com etc) and compiles a text file which is > then scp'ed to > the > postfix box. A cron job on the postfix box picks this up and > sticks it > in > the right place (/etc/postfix/valid_recips) and postmaps it. > > Yes, this is the best way and one that I employ on my gateway servers > and > many others do as well. A script runs on a computer on the > LAN where the > receipeint e-mail server is to gather valid addresses. That > same script > then > copies the resulting file to a central location whether by > xcopy or ftp > depending on where it is and what is between the locations. Another > script > at the central location then combines the various files into a master > file > that holds all valid addresses for all clients and then does what is > needed > to update the gateway SMTP servers. > > (Dan) I don't have to send an e-mail to > helpmeunderstandsmtp@xxxxxxxxxxxxx > to tell you that the response will come from my server. I'm running a > standards (RFC) compliant server. However, this is not the > case in many > of > the e-mail we receive on a daily basis. Our server gets > about 500-1000 > e-mails a day that require an NDR being sent. Occasionally I > go through > these NDR e-mails to see what is being rejected. I keep hoping that > everything that is sent out is a result of spam, but I keep finding > valid > NDRs in there. If everything was as perfect as you imply, my server > would > never have to send out those messages! > > You are mixing up 2 different things. If you send a message to an > invalid > address, it is your server that will generate the NDR back to > you if the > receiving SMTP server is correctly configured. However, on incoming > e-mail > to your server, if you properly and correctly rejected during the > envelope a > message to other than a valid recipient on your server, then > your server > would not have a need to then create an NDR. If you are finding valid > NDR's, > you need to investigate the reason. If they are for such things a user > over > quote, then that is not for you to worry about. What valid > NDR's are you > seeing? > > (Dan) Just to appease you, I did your "Google: email backspatter" > search, > but it only showed me exactly what I've been trying to > describe to you. > The > ability of SMTP servers to send/relay information with little or not > authentication is exactly the reason why many big companies considered > backing the e-mail postage idea. There is no good solution to the > problem. > The solution proposed in many of results of that query all dealt with > SMTP > servers being compliant with a set standard, rejecting all > traffic that > failed to pass those tests. An NDR coming from the "sending" SMTP > server > only happens when two compatible systems talk to each other. > > Incorrect. An NDR coming from the sending SMTP server only goes to the > sender. The compatibility is the SMTP protocol. In fact, SMTP is > probably > one of the simplest protocols there as, as you can even use telnet to > create > an entire session. The SMTP server behind either the sending or > receiving > could care less about what make or model they are as long as they talk > SMTP > protocol. > > (Dan) Sorry for the DNS confusion, I meant to say SMTP. But yes, > rejecting > e-mail at the SMTP level from servers that don't or can't authenticate > is > the same as blocking from non-compatible SMTP servers. That > is what the > results of your Google answer-to-everything search suggest. They > propose > authenticating the sender, encrypting the transaction, etc... > In short, > putting more of a responsibility on the sending SMTP server. > Again, this > "only" works with "current" standards (RFC) complaint SMTP > servers. By > not > sending out NDRs, you've cut off error messages to people > that sent you > a > message and think that you got it. This, in itself isn't a "huge" > problem, > but it all depends on who you expect to receive e-mail from. > > Oops, terminology confusion here. The only authentication > ever going on > is > from the sender to the sender's SMTP server. This is a must. It is sad > to > note that many SMTP servers out there do not require their senders to > authenticate, but that is a whole other discussion. And once again, if > the > receiving server never accepted the message to an invalid > address in the > first place, your claim of must send out an NDR to inform of > non-deliver > vanishes. > > (Dan) I didn't misunderstand you, I just thing you're living in a > fantasy > world and think everyone is running the latest and greatest software > (Freeware or not) on their SMTP servers. Yes, in a perfect world > wouldn't > need to send out NDRs, but we don't live in a perfect world. Turn off > your > NDR sending if you want to, since you won't see the results > it will seem > (to > you at least) to be the perfect solution. > > Not perfect Dan, correct. Do not receive e-mail for non-valid > addresses! > > (Honorable Jim) When "NDR" means "respond to the sending host if > possible" > instead of "send to the address in the 'from:' data field", then NDR > might > once again be a useful mechanism. Until then, it's nothing > more or less > than a way to invite bandwidth abuse. > > Very nicely put. > > (Greg) Just reject the mail at the gateway and let the > sending server be > responsible for generating the NDR. not to be wasting my bandwidth > please! > > Exactly what should be done. > > People, remember this one thing: If the war on spam and > viruses were as > simple as some believe, it would have been over already. > > John T > eServices For You > > > > ------------------------------------------------------ > List Archives: http://www.webelists.com/cgi/lyris.pl?enter=isalist > ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp > ISA Server FAQ: http://www.isaserver.org/pages/larticle.asp?type=FAQ > ------------------------------------------------------ > Visit TechGenix.com for more information about our other sites: > http://www.techgenix.com > ------------------------------------------------------ > You are currently subscribed to this ISAserver.org Discussion List as: > jdanielsen@xxxxxxxxxxxxxxxx > To unsubscribe visit > http://www.webelists.com/cgi/lyris.pl?enter=isalist > Report abuse to listadmin@xxxxxxxxxxxxx > > ------------------------------------------------------ > List Archives: http://www.webelists.com/cgi/lyris.pl?enter=isalist > ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp > ISA Server FAQ: http://www.isaserver.org/pages/larticle.asp?type=FAQ > ------------------------------------------------------ > Visit TechGenix.com for more information about our other sites: > http://www.techgenix.com > ------------------------------------------------------ > You are currently subscribed to this ISAserver.org Discussion > List as: tshinder@xxxxxxxxxxxxxxxxxx > To unsubscribe visit > http://www.webelists.com/cgi/lyris.pl?enter=isalist > Report abuse to listadmin@xxxxxxxxxxxxx > >