|
|
 |  |
Re: reverse DNS questionsFrom: Michael Wise Date: Friday, September 5, 2003
Time: 9:32:15 amAt 11:55 -0500 9/5/03, Len Conrad wrote:
>>Their reasoning...partially; their actions...no.
>>
>>They claim that they want to block smtp transactions from so-called
>>"residential" DSL lines. (whether thy have static IP blocks or
>>not), but what their lazy admins are really doing is labelling as
>>"residential" and then blocking _ALL_ SBC DSL IP blocks if they do
>>not have an rdns suggesting they are being used by a business.
>
>A legit mail server on a subscriber network, while maintaining full
>control over the mail server's administration, can relay its
>outbound through its provider's SMTP gateway, through the
>businesses' own web server, or through a partner/commercial site.
Nobody is questioning whether it can or not. The issue is it should
not have to or be forced to do so. I can guarantee that my clients'
mail server are for more reliable, far more secure, and far less
likely to ever be a spam source than their providers' smtp
gateways...so why should we be forced to use those gateways?
I know, I know...receiver's server/receiver's rules...but in most
cases, they can take their lazy and incompetent sledgehammer rules
and stuff them. I don't really care if rr.com accepts my mail or not.
The other big aspect of this which you, and others insisting that we
use our providers' relays verses our own SECURE and RELIABLE ones is
if we relay through our providers' gateways, we have no record or log
that our email was ever delivered to the mail server of its intended
recipient...we are putting complete faith that our providers' relays
will do so and so in a timely manner. That isn't good enough. I, and
my clients, want log files for all our mail server transactions
indicating when and from what servers mail was received as well as
confirmation that mail was delivered to the mail servers it was
intended for.
Please tell me how we can get this by relaying through our providers'
mail servers?
>
>The issue is very clear. If someone came to you and said: "I have
>solution for you that will fix your horrible problem (of millions of
>inbound spam and joejob msgs per day), with 99.99% accuracy", what
>would you do? \
Not sure where your 99.9% accuracy figure comes from as it can't even
be close to the mark and I challenge you to provide verifiable
evidence supporting it. If somebody told me that, I would laugh. I've
been in spam fighting circles a long time, and there's no such thing
as 99.9% accuracy.
>AOL and RR have decided to do it,
AOL is not doing what this thread is about. RR is...AOL is not.
>and, like anybody who blocks subscriber networks, are reaping huge benefits.
Maybe if RR.com's abuse people had gotten off their lazy butts years
ago, they wouldn't feel so compelled to put on a big fat blind fold
and swinging a sledge hammer around.
They can easily block dynamic residential blocks (many competent
providers do) through their own research or using any one of a few
good public dnsbl's designed for just that purpose.
They can and should be using responsible dnsbl's (spamcop, easynet,
spamhaus, etc.), but they do not.
They are lazy and incompetent and find your defense of their practice
to be most insulting.
>As more and more MXs block subscriber networks,
"more and more" aren't doing any such thing despite the claims of
RR.com and their apologists. What more and more are doing is blocking
DYNAMIC residential blocks. RR.com is the ONLY major provider I have
encountered that is blocking transactions from dsl lines without
regard for them being static or dynamic.
>this policy will become a de facto law,
I seriously doubt it. Can you name a single major provider (besides
rr.com) who is blocking all of a dsl provider's transactions from
static blocks?
>just like AOL requiring senders to have PTR records has become law
>for anybody wanting to send to AOL.
No problem there. Lots of providers have such requirements. Any
competent mail/dns admin will have made sure they had PTR records
long before AOL even knew what they were.
--Mike
|

Return to Digital Point Solutions' Home Page |