[ExchangeList] Re: exchangelist Digest V1 #227
- From: "Jerry Madsen" <jerry@xxxxxxxxxxxxxx>
- To: <exchangelist@xxxxxxxxxxxxx>
- Date: Tue, 24 Oct 2006 13:05:23 -0500
http://www.msexchange.org
-------------------------------------------------------
-----Original Message-----
From: FreeLists Mailing List Manager [mailto:ecartis@xxxxxxxxxxxxx]
Sent: Tuesday, October 24, 2006 1:03 AM
To: exchangelist digest users
Subject: exchangelist Digest V1 #227
http://www.msexchange.org
------------------------------------------------------------------------
-------------------
exchangelist Digest Mon, 23 Oct 2006 Volume: 01 Issue: 227
In This Issue:
[ExchangeList] Re: hi can you help me ?
[ExchangeList] Re: hi can you help me ?
[ExchangeList] Re: I NEED TO GRIPE!
[ExchangeList] Re: I NEED TO GRIPE!
[ExchangeList] Re: I NEED TO GRIPE!
[ExchangeList] Re: I NEED TO GRIPE!
[ExchangeList] Re: I NEED TO GRIPE!
[ExchangeList] Re: I NEED TO GRIPE!
[ExchangeList] Re: I NEED TO GRIPE!
[ExchangeList] Re: I NEED TO GRIPE!
[ExchangeList] Re: I NEED TO GRIPE!
[ExchangeList] Re: I NEED TO GRIPE!
[ExchangeList] Re: I NEED TO GRIPE!
----------------------------------------------------------------------
From: "John T \(Lists\)" <johnlist@xxxxxxxxxxxxxxxxxxx>
Subject: [ExchangeList] Re: hi can you help me ?
Date: Mon, 23 Oct 2006 00:45:43 -0700
Where the heck did you get your MCSE?
Me thinks an audit of their teaching skills is needed.
NEVER EVER EVER NEVER (SBS aside) install Exchange on a DC unless you =
are
fully aware of the problems that WILL occur down the road and know how =
to
get out of them. (Of course, if you take the time to research and learn
=
that
then you will just not do it.)
You need to go aGoogling and search the MS KB.=20
Why do you want to use the same server name but a different organization
name? Are you going to rebuild the domain and/or forest?
Is this server still going to be a DC? (WHY?)
What version Exchange?
You said your replaced it already. With what name? The old one?
John T
eServices For You
"Seek, and ye shall find!"
> -----Original Message-----
> From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx]
> On Behalf Of gerjos merjaneh
> Sent: Sunday, October 22, 2006 6:07 AM
> To: exchangelist@xxxxxxxxxxxxx
> Subject: [ExchangeList] hi can you help me ?
>=20
> http://www.msexchange.org
> -------------------------------------------------------HI EVERYONE
>=20
> i have 2 domain controllers on my Active directory Domain the =
secound DC
I
> intalled Microsoft Exchamge 2003 now the proplem is this server =
Dameged I
> replace this server with Newone how can I delete the damaged exchange
> server from the Active directory
> Because I want to use the same name but with new organization name
>=20
> About me I know how can I delete the metadata base from Active =
directory
but
> how can delete the exchange metadata base
>=20
> thanks for your Interested
>=20
> Gerjos F Merjaneh
> MCSE2003 , CCNA
>=20
> _________________________________________________________________
> House hunt online now!
> =
http://a.ninemsn.com.au/b.aspx?URL=3Dhttp%3A%2F%2Fninemsn%2Erealestate%2
E=
c
> om%2Eau%2Fcgi%2Dbin%2Frsearch%3Fa%3Dbhp%26t%3Dres%26cu%3DMSN&_t=3D
> 758874163&_r=3DHM_EndText_Oct06&_m=3DEXT
>=20
> -------------------------------------------------------
> List Archives: //www.freelists.org/archives/exchangelist/
> MSExchange Newsletter: http://www.msexchange.org/pages/newsletter.asp
> MSExchange Articles and Tutorials:
http://www.msexchange.org/articles_tutorials/
> MSExchange Blogs: http://blogs.msexchange.org/
> -------------------------------------------------------
> Visit TechGenix.com for more information about our other sites:
> http://www.techgenix.com
> -------------------------------------------------------
> To unsubscribe visit http://www.msexchange.org/pages/exchangelist.asp
> Report abuse to listadmin@xxxxxxxxxxxxxx
------------------------------
Date: Mon, 23 Oct 2006 09:01:24 -0400
Subject: [ExchangeList] Re: hi can you help me ?
From: Rick Boza <rickb@xxxxxxxxxxxxxxx>
I'm more than a little hesitant to pass along this information - you
might
be much better off (I should say 'probably would be much better off')
just
calling in an expert to fix this mess.
There are ways to remove the Exchange org from AD - effectively
'un-forestpreepping' and 'un-domainprepping' your AD structure using
ADSIEdit. Given that you say you want the same server name but a new
Org
name, that's pretty much what you need to do IMHO. Generally, unless
you
have extensive experience, you don't do these things without having PSS
on
the phone to walk you through it.
What about your old/existing mail? Are you planning to try and restore
it?
Because what you're describing is almost certainly going to break
repliability without A LOT of creativity in addressing, routing, and DNS
games.
And as John says, before you continue, be sure to understand the
ramifications and limitations/difficulties with Exchange on a DC.
I'm really not one to solicit business on this list, but maybe you
should
just call one of us an pony up the consulting fees before you make a
real
mess of things?
> From: "John T (Lists)" <johnlist@xxxxxxxxxxxxxxxxxxx>
> Organization: eServices For You
> Reply-To: <exchangelist@xxxxxxxxxxxxx>
> Date: Mon, 23 Oct 2006 00:45:43 -0700
> To: <exchangelist@xxxxxxxxxxxxx>
> Subject: [ExchangeList] Re: hi can you help me ?
>
> http://www.msexchange.org
> -------------------------------------------------------Where the heck
did you
> get your MCSE?
>
> Me thinks an audit of their teaching skills is needed.
>
> NEVER EVER EVER NEVER (SBS aside) install Exchange on a DC unless you
are
> fully aware of the problems that WILL occur down the road and know how
to
> get out of them. (Of course, if you take the time to research and
learn that
> then you will just not do it.)
>
> You need to go aGoogling and search the MS KB.
>
> Why do you want to use the same server name but a different
organization
> name? Are you going to rebuild the domain and/or forest?
>
> Is this server still going to be a DC? (WHY?)
>
> What version Exchange?
>
> You said your replaced it already. With what name? The old one?
>
> John T
> eServices For You
>
> "Seek, and ye shall find!"
>
>
>> -----Original Message-----
>> From: exchangelist-bounce@xxxxxxxxxxxxx
> [mailto:exchangelist-bounce@xxxxxxxxxxxxx]
>> On Behalf Of gerjos merjaneh
>> Sent: Sunday, October 22, 2006 6:07 AM
>> To: exchangelist@xxxxxxxxxxxxx
>> Subject: [ExchangeList] hi can you help me ?
>>
>> http://www.msexchange.org
>> -------------------------------------------------------HI EVERYONE
>>
>> i have 2 domain controllers on my Active directory Domain the
secound DC
> I
>> intalled Microsoft Exchamge 2003 now the proplem is this server
Dameged I
>> replace this server with Newone how can I delete the damaged
exchange
>> server from the Active directory
>> Because I want to use the same name but with new organization name
>>
>> About me I know how can I delete the metadata base from Active
directory
> but
>> how can delete the exchange metadata base
>>
>> thanks for your Interested
>>
>> Gerjos F Merjaneh
>> MCSE2003 , CCNA
>>
>> _________________________________________________________________
>> House hunt online now!
>>
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Erealestate%2Ec
>> om%2Eau%2Fcgi%2Dbin%2Frsearch%3Fa%3Dbhp%26t%3Dres%26cu%3DMSN&_t=
>> 758874163&_r=HM_EndText_Oct06&_m=EXT
>>
>> -------------------------------------------------------
>> List Archives: //www.freelists.org/archives/exchangelist/
>> MSExchange Newsletter: http://www.msexchange.org/pages/newsletter.asp
>> MSExchange Articles and Tutorials:
> http://www.msexchange.org/articles_tutorials/
>> MSExchange Blogs: http://blogs.msexchange.org/
>> -------------------------------------------------------
>> Visit TechGenix.com for more information about our other sites:
>> http://www.techgenix.com
>> -------------------------------------------------------
>> To unsubscribe visit http://www.msexchange.org/pages/exchangelist.asp
>> Report abuse to listadmin@xxxxxxxxxxxxxx
>
>
> -------------------------------------------------------
> List Archives: //www.freelists.org/archives/exchangelist/
> MSExchange Newsletter: http://www.msexchange.org/pages/newsletter.asp
> MSExchange Articles and Tutorials:
> http://www.msexchange.org/articles_tutorials/
> MSExchange Blogs: http://blogs.msexchange.org/
> -------------------------------------------------------
> Visit TechGenix.com for more information about our other sites:
> http://www.techgenix.com
> -------------------------------------------------------
> To unsubscribe visit http://www.msexchange.org/pages/exchangelist.asp
> Report abuse to listadmin@xxxxxxxxxxxxxx
>
------------------------------
Date: Mon, 23 Oct 2006 12:30:11 -0400
From: Danny <nocmonkey@xxxxxxxxx>
Subject: [ExchangeList] Re: I NEED TO GRIPE!
If you accept email for recipients that do not exist, you must pay a
toll
for causing backscatter on the Internet.
On 10/18/06, Chris Wall <Chris.Wall@xxxxxxxxxxxxxxxxxxx> wrote:
>
> 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
>
>
>
>
>
--
CPDE - Certified Petroleum Distribution Engineer
CCBC - Certified Canadian Beer Consumer
------------------------------
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Date: Mon, 23 Oct 2006 13:21:07 -0400
From: "William Holmes" <wtholmes@xxxxxxxxxxxxxx>
Hello,
This is the primary reason we do not use any external RTBL. You are
subscribing to a service that has its own policies. Every anti-spam
system
has a cost benefit ratio, when that ratio drops below an acceptable
ratio its
time to move on. There are more effective ways to handle spam that your
organization can have direct control over.
Bill
________________________________
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Danny
Sent: Monday, October 23, 2006 12:30 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
If you accept email for recipients that do not exist, you must pay a
toll for
causing backscatter on the Internet.
On 10/18/06, Chris Wall < Chris.Wall@xxxxxxxxxxxxxxxxxxx
<mailto:Chris.Wall@xxxxxxxxxxxxxxxxxxx> > wrote:
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
<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
--
CPDE - Certified Petroleum Distribution Engineer
CCBC - Certified Canadian Beer Consumer
------------------------------
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Date: Mon, 23 Oct 2006 13:57:46 -0400
From: "Moon, Brendan" <bmoon@xxxxxx>
Sticking your head in the sand isn't going to solve the problem.
Neither is avoiding the use of RBLs in your own shop. The point is that
the 'generally accepted' customs and standards change with the times.
Most spam senders falsify the "from" address. This means that the NDRs
you send out to the Internet go to a forged address, and end up in some
unsuspecting soul's mailbox. As Spamcop asserts, this is arguably just
as bad as the original spam.
- Brendan Moon
________________________________
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of William Holmes
Sent: Monday, October 23, 2006 1:21 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Hello,
This is the primary reason we do not use any external RTBL. You are
subscribing to a service that has its own policies. Every anti-spam
system has a cost benefit ratio, when that ratio drops below an
acceptable ratio its time to move on. There are more effective ways to
handle spam that your organization can have direct control over.
Bill
________________________________
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Danny
Sent: Monday, October 23, 2006 12:30 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
If you accept email for recipients that do not exist, you must pay a
toll for causing backscatter on the Internet.
On 10/18/06, Chris Wall < Chris.Wall@xxxxxxxxxxxxxxxxxxx
<mailto:Chris.Wall@xxxxxxxxxxxxxxxxxxx> > wrote:
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
<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
--
CPDE - Certified Petroleum Distribution Engineer
CCBC - Certified Canadian Beer Consumer
------------------------------
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Date: Mon, 23 Oct 2006 15:20:09 -0400
From: "William Holmes" <wtholmes@xxxxxxxxxxxxxx>
I am not ignoring spam. I am ignoring RTBL because of their marginal
usefulness and the fact that they can change their policy and affect
email
flow to my organization. In my environment they improve the detection
of
spam only by about 3% while preventing quiet a bit of legitimate mail. I
find
Bayesian filters much more effective and they don't "decide" to change
policy
on a whim.
It is not appropriate (at least in my opinion) to violate RFC822 just to
say
you are a more effective spam filter. This is ostensibly what they
(spamacop)
are doing. Then again if you don't agree you are welcome to continue
using
their services.
Bill
________________________________
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Moon, Brendan
Sent: Monday, October 23, 2006 1:58 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Sticking your head in the sand isn't going to solve the problem.
Neither is
avoiding the use of RBLs in your own shop. The point is that the
'generally
accepted' customs and standards change with the times.
Most spam senders falsify the "from" address. This means that the NDRs
you
send out to the Internet go to a forged address, and end up in some
unsuspecting soul's mailbox. As Spamcop asserts, this is arguably just
as
bad as the original spam.
- Brendan Moon
________________________________
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of William Holmes
Sent: Monday, October 23, 2006 1:21 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Hello,
This is the primary reason we do not use any external RTBL. You are
subscribing to a service that has its own policies. Every anti-spam
system
has a cost benefit ratio, when that ratio drops below an acceptable
ratio its
time to move on. There are more effective ways to handle spam that your
organization can have direct control over.
Bill
________________________________
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Danny
Sent: Monday, October 23, 2006 12:30 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
If you accept email for recipients that do not exist, you must pay a
toll for
causing backscatter on the Internet.
On 10/18/06, Chris Wall < Chris.Wall@xxxxxxxxxxxxxxxxxxx
<mailto:Chris.Wall@xxxxxxxxxxxxxxxxxxx> > wrote:
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
<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
--
CPDE - Certified Petroleum Distribution Engineer
CCBC - Certified Canadian Beer Consumer
------------------------------
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Date: Mon, 23 Oct 2006 14:47:10 -0500
From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
You're right about that. When you deal with unaccountable entities with
questionable motivations and methods, it's better to avoid them all and
use more sophisticated and trustworthy methodologies to stem the spam
tide. Why put a company at risk using these "do-gooders" when you can
benefit from vendors who take responsibility for their products?
Thomas W Shinder, M.D.
Site: www.isaserver.org <http://www.isaserver.org/>
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7 <http://tinyurl.com/3xqb7>
MVP -- Microsoft Firewalls (ISA)
________________________________
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of William Holmes
Sent: Monday, October 23, 2006 12:21 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Hello,
This is the primary reason we do not use any external RTBL. You
are subscribing to a service that has its own policies. Every anti-spam
system has a cost benefit ratio, when that ratio drops below an
acceptable ratio its time to move on. There are more effective ways to
handle spam that your organization can have direct control over.
Bill
________________________________
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Danny
Sent: Monday, October 23, 2006 12:30 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
If you accept email for recipients that do not exist, you must
pay a toll for causing backscatter on the Internet.
On 10/18/06, Chris Wall < Chris.Wall@xxxxxxxxxxxxxxxxxxx
<mailto:Chris.Wall@xxxxxxxxxxxxxxxxxxx> > wrote:
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
<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
--
CPDE - Certified Petroleum Distribution Engineer
CCBC - Certified Canadian Beer Consumer
------------------------------
From: "Howard Rappaport" <howie@xxxxxxxxx>
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Date: Mon, 23 Oct 2006 16:03:00 -0400
I have to say RTBL's have more than marginal usefulness, but it all
depends
on how / why you use them. They save my other layered products from
having
to deal with the message (specifically A/V), there is big value in that
for
me . can't beat the price. Seeing 60% less mail get processed
internally is
fantastic for me! I used to use spamcop; but they're too aggressive for
me,
so I no longer use them. I've finally dwindled my list down to these
four:
sbl-xbl.spamhaus.org, relays.ordb.org, combined.njabl.org, and
list.dsbl.org
and haven't heard any complaints from the 25 or so people on our mail
server.
They're a tool; a wonderful free tool that is great for some, not all.
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of William Holmes
Sent: Monday, October 23, 2006 3:20 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
I am not ignoring spam. I am ignoring RTBL because of their marginal
usefulness and the fact that they can change their policy and affect
email
flow to my organization. In my environment they improve the detection
of
spam only by about 3% while preventing quiet a bit of legitimate mail. I
find Bayesian filters much more effective and they don't "decide" to
change
policy on a whim.
It is not appropriate (at least in my opinion) to violate RFC822 just to
say
you are a more effective spam filter. This is ostensibly what they
(spamacop) are doing. Then again if you don't agree you are welcome to
continue using their services.
Bill
_____
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Moon, Brendan
Sent: Monday, October 23, 2006 1:58 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Sticking your head in the sand isn't going to solve the problem.
Neither is
avoiding the use of RBLs in your own shop. The point is that the
'generally
accepted' customs and standards change with the times.
Most spam senders falsify the "from" address. This means that the NDRs
you
send out to the Internet go to a forged address, and end up in some
unsuspecting soul's mailbox. As Spamcop asserts, this is arguably just
as
bad as the original spam.
- Brendan Moon
_____
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of William Holmes
Sent: Monday, October 23, 2006 1:21 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Hello,
This is the primary reason we do not use any external RTBL. You are
subscribing to a service that has its own policies. Every anti-spam
system
has a cost benefit ratio, when that ratio drops below an acceptable
ratio
its time to move on. There are more effective ways to handle spam that
your
organization can have direct control over.
Bill
_____
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Danny
Sent: Monday, October 23, 2006 12:30 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
If you accept email for recipients that do not exist, you must pay a
toll
for causing backscatter on the Internet.
On 10/18/06, Chris Wall < Chris.Wall@xxxxxxxxxxxxxxxxxxx
<mailto:Chris.Wall@xxxxxxxxxxxxxxxxxxx> > wrote:
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
<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
--
CPDE - Certified Petroleum Distribution Engineer
CCBC - Certified Canadian Beer Consumer
------------------------------
From: "John T \(Lists\)" <johnlist@xxxxxxxxxxxxxxxxxxx>
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Date: Mon, 23 Oct 2006 14:10:28 -0700
William, what you and others are failing to understand is that SpamCop
is
not the bad guy here, any one who is first accepting email for
non-existing
addresses and THEN bouncing are the causes of the problem and SpamCop is
merely pointing that fact out.
It is entirely irresponsible for a company/entity to at first accept
delivery of email destined to non-existent addresses and then bounce.
This
causes backscatter and additional spam, often to innocent people in the
form
of forged from addresses. That is not acceptable in this day and age.
If a spammer is spreading spam and using a forged address that is one of
mine, and your server first accepts that spam and then bounces it to the
forged from address, mine, I will not hesitate one minute to cause your
server to be listed on RBL!
If the destination email address is non-existent, you must reject, not
accept then bounce.
John T
eServices For You
"Seek, and ye shall find!"
-----Original Message-----
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of William Holmes
Sent: Monday, October 23, 2006 12:20 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
I am not ignoring spam. I am ignoring RTBL because of their marginal
usefulness and the fact that they can change their policy and affect
email
flow to my organization. In my environment they improve the detection
of
spam only by about 3% while preventing quiet a bit of legitimate mail. I
find Bayesian filters much more effective and they don't "decide" to
change
policy on a whim.
It is not appropriate (at least in my opinion) to violate RFC822 just to
say
you are a more effective spam filter. This is ostensibly what they
(spamacop) are doing. Then again if you don't agree you are welcome to
continue using their services.
Bill
_____
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Moon, Brendan
Sent: Monday, October 23, 2006 1:58 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Sticking your head in the sand isn't going to solve the problem.
Neither is
avoiding the use of RBLs in your own shop. The point is that the
'generally
accepted' customs and standards change with the times.
Most spam senders falsify the "from" address. This means that the NDRs
you
send out to the Internet go to a forged address, and end up in some
unsuspecting soul's mailbox. As Spamcop asserts, this is arguably just
as
bad as the original spam.
- Brendan Moon
_____
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of William Holmes
Sent: Monday, October 23, 2006 1:21 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Hello,
This is the primary reason we do not use any external RTBL. You are
subscribing to a service that has its own policies. Every anti-spam
system
has a cost benefit ratio, when that ratio drops below an acceptable
ratio
its time to move on. There are more effective ways to handle spam that
your
organization can have direct control over.
Bill
_____
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Danny
Sent: Monday, October 23, 2006 12:30 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
If you accept email for recipients that do not exist, you must pay a
toll
for causing backscatter on the Internet.
On 10/18/06, Chris Wall < Chris.Wall@xxxxxxxxxxxxxxxxxxx
<mailto:Chris.Wall@xxxxxxxxxxxxxxxxxxx> > wrote:
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
<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
--
CPDE - Certified Petroleum Distribution Engineer
CCBC - Certified Canadian Beer Consumer
------------------------------
From: "John T \(Lists\)" <johnlist@xxxxxxxxxxxxxxxxxxx>
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Date: Mon, 23 Oct 2006 14:12:40 -0700
Very true, that is why of the 70 some-ought RBLs out there, only about 2
dozen are used by those of use who know how to use them, in a weighted
anti-spam configuration.
John T
eServices For You
"Seek, and ye shall find!"
-----Original Message-----
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
Sent: Monday, October 23, 2006 12:47 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
You're right about that. When you deal with unaccountable entities with
questionable motivations and methods, it's better to avoid them all and
use
more sophisticated and trustworthy methodologies to stem the spam tide.
Why
put a company at risk using these "do-gooders" when you can benefit from
vendors who take responsibility for their products?
Thomas W Shinder, M.D.
Site: www.isaserver.org <http://www.isaserver.org/>
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP -- Microsoft Firewalls (ISA)
_____
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of William Holmes
Sent: Monday, October 23, 2006 12:21 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Hello,
This is the primary reason we do not use any external RTBL. You are
subscribing to a service that has its own policies. Every anti-spam
system
has a cost benefit ratio, when that ratio drops below an acceptable
ratio
its time to move on. There are more effective ways to handle spam that
your
organization can have direct control over.
Bill
_____
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Danny
Sent: Monday, October 23, 2006 12:30 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
If you accept email for recipients that do not exist, you must pay a
toll
for causing backscatter on the Internet.
On 10/18/06, Chris Wall < Chris.Wall@xxxxxxxxxxxxxxxxxxx
<mailto:Chris.Wall@xxxxxxxxxxxxxxxxxxx> > wrote:
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
<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
--
CPDE - Certified Petroleum Distribution Engineer
CCBC - Certified Canadian Beer Consumer
------------------------------
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Date: Mon, 23 Oct 2006 17:25:58 -0400
From: "Moon, Brendan" <bmoon@xxxxxx>
I think you missed my point. Even if you don't use an RBL, your
recipients may. The original poster (OP) didn't utilize SpamCop
services. His intended recipients did. So by allowing NDRs to flow
back to the internet, he got himself blacklisted. While you could
certainly say "who cares?" His user community had a problem with it.
I was simply adding support to the suggestion that he try to prevent
outbound NDRs generated by inbound spam.
- Brendan Moon
________________________________
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of William Holmes
Sent: Monday, October 23, 2006 3:20 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
I am not ignoring spam. I am ignoring RTBL because of their marginal
usefulness and the fact that they can change their policy and affect
email flow to my organization. In my environment they improve the
detection of spam only by about 3% while preventing quiet a bit of
legitimate mail. I find Bayesian filters much more effective and they
don't "decide" to change policy on a whim.
It is not appropriate (at least in my opinion) to violate RFC822 just to
say you are a more effective spam filter. This is ostensibly what they
(spamacop) are doing. Then again if you don't agree you are welcome to
continue using their services.
Bill
________________________________
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Moon, Brendan
Sent: Monday, October 23, 2006 1:58 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Sticking your head in the sand isn't going to solve the problem.
Neither is avoiding the use of RBLs in your own shop. The point is that
the 'generally accepted' customs and standards change with the times.
Most spam senders falsify the "from" address. This means that the NDRs
you send out to the Internet go to a forged address, and end up in some
unsuspecting soul's mailbox. As Spamcop asserts, this is arguably just
as bad as the original spam.
- Brendan Moon
________________________________
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of William Holmes
Sent: Monday, October 23, 2006 1:21 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Hello,
This is the primary reason we do not use any external RTBL. You are
subscribing to a service that has its own policies. Every anti-spam
system has a cost benefit ratio, when that ratio drops below an
acceptable ratio its time to move on. There are more effective ways to
handle spam that your organization can have direct control over.
Bill
________________________________
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Danny
Sent: Monday, October 23, 2006 12:30 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
If you accept email for recipients that do not exist, you must pay a
toll for causing backscatter on the Internet.
On 10/18/06, Chris Wall < Chris.Wall@xxxxxxxxxxxxxxxxxxx
<mailto:Chris.Wall@xxxxxxxxxxxxxxxxxxx> > wrote:
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
<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
--
CPDE - Certified Petroleum Distribution Engineer
CCBC - Certified Canadian Beer Consumer
------------------------------
From: "William Lefkovics" <william@xxxxxxxxxxxxxxxxx>
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Date: Mon, 23 Oct 2006 21:43:53 -0700
That depends on your perspective, John. I am not failing to understand
it
at all. SpamCop was one of the RBLs I used back in 2002-2003 or so.
I understood the principles then, and I understand them now.
That does not mean I should concur with your all or nothing religious
stance
on the subject.
While I can forgive your inability to handle 'backscatter', does it mean
independent entities should be out looking for servers that do this
because
it meets *their* definition of spam? That meets *my* definition of
vigilanteeism.
You should start your own RBL. It isn't difficult. Well, it was easier
7
or 8 years ago, I think.
_____
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of John T (Lists)
Sent: Monday, October 23, 2006 2:10 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
William, what you and others are failing to understand is that SpamCop
is
not the bad guy here, any one who is first accepting email for
non-existing
addresses and THEN bouncing are the causes of the problem and SpamCop is
merely pointing that fact out.
It is entirely irresponsible for a company/entity to at first accept
delivery of email destined to non-existent addresses and then bounce.
This
causes backscatter and additional spam, often to innocent people in the
form
of forged from addresses. That is not acceptable in this day and age.
If a spammer is spreading spam and using a forged address that is one of
mine, and your server first accepts that spam and then bounces it to the
forged from address, mine, I will not hesitate one minute to cause your
server to be listed on RBL!
If the destination email address is non-existent, you must reject, not
accept then bounce.
John T
eServices For You
"Seek, and ye shall find!"
-----Original Message-----
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of William Holmes
Sent: Monday, October 23, 2006 12:20 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
I am not ignoring spam. I am ignoring RTBL because of their marginal
usefulness and the fact that they can change their policy and affect
email
flow to my organization. In my environment they improve the detection
of
spam only by about 3% while preventing quiet a bit of legitimate mail. I
find Bayesian filters much more effective and they don't "decide" to
change
policy on a whim.
It is not appropriate (at least in my opinion) to violate RFC822 just to
say
you are a more effective spam filter. This is ostensibly what they
(spamacop) are doing. Then again if you don't agree you are welcome to
continue using their services.
Bill
_____
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Moon, Brendan
Sent: Monday, October 23, 2006 1:58 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Sticking your head in the sand isn't going to solve the problem.
Neither is
avoiding the use of RBLs in your own shop. The point is that the
'generally
accepted' customs and standards change with the times.
Most spam senders falsify the "from" address. This means that the NDRs
you
send out to the Internet go to a forged address, and end up in some
unsuspecting soul's mailbox. As Spamcop asserts, this is arguably just
as
bad as the original spam.
- Brendan Moon
_____
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of William Holmes
Sent: Monday, October 23, 2006 1:21 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Hello,
This is the primary reason we do not use any external RTBL. You are
subscribing to a service that has its own policies. Every anti-spam
system
has a cost benefit ratio, when that ratio drops below an acceptable
ratio
its time to move on. There are more effective ways to handle spam that
your
organization can have direct control over.
Bill
_____
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Danny
Sent: Monday, October 23, 2006 12:30 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
If you accept email for recipients that do not exist, you must pay a
toll
for causing backscatter on the Internet.
On 10/18/06, Chris Wall < <mailto:Chris.Wall@xxxxxxxxxxxxxxxxxxx>
Chris.Wall@xxxxxxxxxxxxxxxxxxx> wrote:
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>
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 <http://www.globalknowledge.com>
--
CPDE - Certified Petroleum Distribution Engineer
CCBC - Certified Canadian Beer Consumer
------------------------------
From: "William Lefkovics" <william@xxxxxxxxxxxxxxxxx>
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Date: Mon, 23 Oct 2006 22:27:32 -0700
An RBL for servers that allow OOFs to list posts... now you're on to
something.
_____
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of William
Lefkovics
Sent: Monday, October 23, 2006 9:44 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
That depends on your perspective, John. I am not failing to understand
it
at all. SpamCop was one of the RBLs I used back in 2002-2003 or so.
I understood the principles then, and I understand them now.
That does not mean I should concur with your all or nothing religious
stance
on the subject.
While I can forgive your inability to handle 'backscatter', does it mean
independent entities should be out looking for servers that do this
because
it meets *their* definition of spam? That meets *my* definition of
vigilanteeism.
You should start your own RBL. It isn't difficult. Well, it was easier
7
or 8 years ago, I think.
_____
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of John T (Lists)
Sent: Monday, October 23, 2006 2:10 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
William, what you and others are failing to understand is that SpamCop
is
not the bad guy here, any one who is first accepting email for
non-existing
addresses and THEN bouncing are the causes of the problem and SpamCop is
merely pointing that fact out.
It is entirely irresponsible for a company/entity to at first accept
delivery of email destined to non-existent addresses and then bounce.
This
causes backscatter and additional spam, often to innocent people in the
form
of forged from addresses. That is not acceptable in this day and age.
If a spammer is spreading spam and using a forged address that is one of
mine, and your server first accepts that spam and then bounces it to the
forged from address, mine, I will not hesitate one minute to cause your
server to be listed on RBL!
If the destination email address is non-existent, you must reject, not
accept then bounce.
John T
eServices For You
"Seek, and ye shall find!"
-----Original Message-----
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of William Holmes
Sent: Monday, October 23, 2006 12:20 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
I am not ignoring spam. I am ignoring RTBL because of their marginal
usefulness and the fact that they can change their policy and affect
email
flow to my organization. In my environment they improve the detection
of
spam only by about 3% while preventing quiet a bit of legitimate mail. I
find Bayesian filters much more effective and they don't "decide" to
change
policy on a whim.
It is not appropriate (at least in my opinion) to violate RFC822 just to
say
you are a more effective spam filter. This is ostensibly what they
(spamacop) are doing. Then again if you don't agree you are welcome to
continue using their services.
Bill
_____
From: exchangelist-bounce@xxxxxxxxxxxxx
[mailto:exchangelist-bounce@xxxxxxxxxxxxx] On Behalf Of Moon, Brendan
Sent: Monday, October 23, 2006 1:58 PM
To: exchangelist@xxxxxxxxxxxxx
Subject: [ExchangeList] Re: I NEED TO GRIPE!
Sticking your head in the sand isn't going to solve the problem.
Neither is
avoiding the use of RBLs in your own shop. The point is that the
'generally
accepted' customs and standards change with the times.
Most spam senders falsify the "from" address. This means that the NDRs
you
send out to the Internet go to a forged address, and end up in some
unsuspecting soul's mailbox. As Spamcop asserts, this is arguably just
as
bad as the original spam.
- Brendan Moon
------------------------------
End of exchangelist Digest V1 #227
**********************************
-------------------------------------------------------
List Archives: //www.freelists.org/archives/exchangelist/
MSExchange Newsletter: http://www.msexchange.org/pages/newsletter.asp
MSExchange Articles and Tutorials:
http://www.msexchange.org/articles_tutorials/
MSExchange Blogs: http://blogs.msexchange.org/
-------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com
-------------------------------------------------------
To unsubscribe visit http://www.msexchange.org/pages/exchangelist.asp
Report abuse to listadmin@xxxxxxxxxxxxxx
-------------------------------------------------------
List Archives: //www.freelists.org/archives/exchangelist/
MSExchange Newsletter: http://www.msexchange.org/pages/newsletter.asp
MSExchange Articles and Tutorials: http://www.msexchange.org/articles_tutorials/
MSExchange Blogs: http://blogs.msexchange.org/
-------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com
-------------------------------------------------------
To unsubscribe visit http://www.msexchange.org/pages/exchangelist.asp
Report abuse to listadmin@xxxxxxxxxxxxxx
Other related posts:
- » [ExchangeList] Re: exchangelist Digest V1 #227
