[ExchangeList] Re: I NEED TO GRIPE!
- From: "Periyasamy, Raj" <Raj.Periyasamy@xxxxxxxxxxxx>
- To: <exchangelist@xxxxxxxxxxxxx>
- Date: Wed, 18 Oct 2006 13:26:35 -0400
I agree with Chris in general. The comments you highlighted,
" I mean, if a customer sends an e-mail to our domain and misspells the
SMTP address of one of our sales people - You want an NDR to go back to
them so hopefully they realize their mistake."
would apply to companies that uses smart hosts to relay their emails to
Internet. We are one of them. We use GFI, and the Directory harvest
filter, which does ldap lookups, is configured to block an email if it
contains more than 2 misspelled recipient IDs. This works fine. Plus,
we've had a lot of false positives by using spamcops blacklists. We have
switched to using only spamhaus, and it seems false positives are down
drastically.
SPF is a great filter. I used to have it enabled within GFI, and set a
level to reject messages from domains that are soft fail and hard fail.
It worked fine, except that some domains did not configure their
domain's SPF records properly, and we had to encounter false positives.
Majority of them were government and educational institutes. In
addition, due to some bug with the SPF filter module in the latest
version of the GFI, it kept crashing on us, and we had major mail
delivery issues, and had to turn it off. I would really like to enable
that feature again when the problem is resolved by GFI. I think SPF will
become an accepted standard for preventing email spoofing and forgery.
Pretty easy to setup, and it works with minimum overhead to the spam
filter.
HTH.
Regards,
Raj Periyasamy
MCSE(Messaging), CCNA
________________________________
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Jensen, Douglas
Sent: Wednesday, October 18, 2006 1:02 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
I probably agree with you except for:
" I mean, if a customer sends an e-mail to our domain and misspells the
SMTP address of one of our sales people - You want an NDR to go back to
them so hopefully they realize their mistake."
Why not let the senders email system handle the non delivery report. If
my email server can not deliver a message to someone else because we
spelled their name incorrectly, my email server sends a ndr to the
sender telling the reason (no such user, DNS can not find the domain,
etc.) the email was not delivered. That happens every time my server can
not deliver a message. It does not require the other server to do
anything other than reject the message and give a hint as to why it was
rejecting it.
Certainly you are not saying I have to accept any and all mail sent to
my domain even if the user does not exist.
Douglas Jensen
Douglas.Jensen@xxxxxxxxxxxxx <mailto:Douglas.Jensen@xxxxxxxxxxxxx>
Voice (952) 402-9821
Fax (952) 402-9815
Network Administrator
Scott Carver Dakota CAP Agency, Inc.
712 Canterbury Road
Shakopee, MN 55379
www.capagency.org
<file:///C:/Documents%20and%20Settings/djensen.SCDCAP/Application%20Data
/Microsoft/Signatures/www.capagency.org>
________________________________
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Chris Wall
Sent: Wednesday, October 18, 2006 11:14 AM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] I NEED TO GRIPE!
Any one wanting to read or chime in, please feel free! I know all of
you are e-mail admins, and you may have some thoughts on the subject as
well.
I am extremely disappointed with SpamCop.net - one of the few blacklist
sites that have - rather, HAD a good reputation...
Is any one else being affected by their actions of Blacklisting domains
because they follow RFC822 and send NDR's when a mail is not
successfully delivered?
Okay, here's the overall story - SpamCop sets up these 'HoneyPot' email
addresses (whatever@xxxxxxx). SpamCop then sends e-mails out to many
domains (illegitimate e-mail addresses - basically acting as spammer's
themselves) and wait to see which domains send an NDR back to the
'HoneyPot' email address. If your domain follows RFC822 and sends the
NDR, they blacklist the IP address of the server that sends the NDR.
Their website (http://www.spamcop.net/fom-serve/cache/329.html#bounces)
even details their stance on the issue. I have copied it below:
'Q: Why not allow bounces? They are required by RFC822!
A: Originally, SpamCop made attempts to forgive misdirected bounce
messages - to reject them as evidence of spam. However, there are two
factors conspiring to force us to rescind this policy. First of course,
is that these misdirected messages *are* spam as we define it
(Unsolicited Bulk Mail). They are objectionable to recipients and can
even cause denial of service to innocent third parties. Users of our
blocking service want us to stop them.'
I understand what they are trying to accomplish - to prevent NDR's from
being sent to you when spammers 'spoof' your personal e-mail address.
However, SpamCop is punishing domains that abide by all security
standards for e-mail except for their 'rogue' approach to NDR delivery.
Total BS in my opinion.
Now of course, any domain could enable LDAP authentication on incoming
e-mail and block NDR's being sent when an e-mail address is sent to a
non-existent e-mail address in your domain - BUT, even excluding RFC822
rules requiring NDR's on e-mails that are not successfully delivered,
most organizations want to keep NDR's enabled so that senders are aware
if a message is not successfully sent. I mean, if a customer sends an
e-mail to our domain and misspells the SMTP address of one of our sales
people - You want an NDR to go back to them so hopefully they realize
their mistake.
Spamcop.net even says to use SPF for checking the e-mail origin...
Well, I use SPF. But only block e-mails where the sending domain
provides an SPF record and the authentication fails. I am not going to
block emails coming into our domain just because a sending domain may
not have SPF setup for their domain... I mean, I cant force them to
provide and SPF record, even though it is recommended.
SpamCop.net users should either stop relying on their services or either
use SpamCop.net in a 'weighted' approach for determining SPAM.
Any way - I had to gripe about this poor decision on SpamCop's behalf
and would like to get your opinions...
Regards,
Chris Wall - MCSE + Messaging
NAM Exchange Administrator
Chris.Wall@xxxxxxxxxxxxxxxxxxx
T (919) 460.3236
F (919) 468.4889
Global Knowledge
LEARNING. To Make a Difference.
http://www.globalknowledge.com
Other related posts:
