How I spent my Christmas vacation - Email found in subject

Welfare -

I don't mean to be downgrading my knowledge or Certification, but there
are some many people on this list (and others) that are far more
advanced than me - it simply humbles one to be a mere spectator. At this
point in time - the only thing I can contribute is: I did "X" and
experienced "Y".

I am honored and thankful to read the thoughts and ideas from the
contributors, seriously.

Joseph F. Danielsen, MCSA-Messaging, MCP
Network Blade Inc.
49 Marcy Street
Somerset, NJ 08873
(732) 213-0600
www.NetworkBlade.Com 
 

-----Original Message-----
From: Thomas W Shinder [mailto:tshinder@xxxxxxxxxxx] 
Sent: Wednesday, January 04, 2006 10:51 AM
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: How I spent my Christmas vacation - Email found
in subject

http://www.ISAserver.org

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
> 
> 

------------------------------------------------------
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

Other related posts: