RE: How I spent my Christmas vacation - Email found in subject
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx>
- Date: Wed, 4 Jan 2006 09:51:28 -0600
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
>
>
Other related posts:
