[ExchangeList] Re: I NEED TO GRIPE!
- From: "John T \(Lists\)" <johnlist@xxxxxxxxxxxxxxxxxxx>
- To: <exchangelist@xxxxxxxxxxxxx>
- Date: Wed, 18 Oct 2006 15:19:02 -0700
Those hosted solutions MUST NOW make changes to allow for either live LDAP
lookups or an automated way of updating a list of acceptable addresses.
John T
eServices For You
"Seek, and ye shall find!"
-----Original Message-----
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Chris Wall
Sent: Wednesday, October 18, 2006 1:30 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
John - I agree. In a perfect world that is the policy that we should all
abide by.
But what about those organizations that use Frontbridge or similar hosted
SPAM/Content solutions and they are not able to verify if an email exists in
a customer's domain? The hosted center has to accept the email, filter it
and then send to a recipient domain. If it is unable to send the message to
the recipient domain b/c of recipient filtering or the address simply does
not exist, then the hosted center sends out an NDR. This 'man in the
middle', which is growing in popularity will hurt many organizations because
of SpamCop's decision.
Hopefully in the very near future, these hosted solutions will be able to
perform live LDAP type lookups before accepting mail for delivery.
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
_____
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of John T (Lists)
Sent: Wednesday, October 18, 2006 4:18 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
The biggest problem here that MANY over look is that you should not be
accepting email for non-existent addresses!
Period
End of Story.
I will back SpamCop on this issue. If you accept an email message and then
are subsequently unable to deliver it to its final destination or to another
server for delivery to its final destination then yes you are breaking
RFC822. (Note that "filtering" of the message in transit does not break
RFC822 if such filtering is at the request of the receiver or his/her email
provider etc etc blah blah blah)
What has to be done is stop accepting incoming email for non-existent
addresses. The connecting server is then given a 5.x.x return code and it is
then up to that connecting server to notify the sender by NDR.
John T
eServices For You
"Seek, and ye shall find!"
-----Original Message-----
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Chris Wall
Sent: Wednesday, October 18, 2006 9: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:
