Re: PLUG: PMAS

In article <U9wdi.170182$_c5.159175@attbi_s22>,
"John E. Malmberg" <wb8tyw@xxxxxxxxxxx> writes:
Bill Gunshannon wrote:
In article <46755c79$1@xxxxxxxxxxxxxxxxxxx>,

But that just increases the likelihood of a false positive. I have
people who contact me who get bounces every once in a while. When
asked, I usually look at the logs to see why. You would be amazed
(well, maybe not) at the number of places, like comcast, that have
multiple MTA machines, which seem to get selected at randow when a
user sends an email, where one or two of them are RBLed. Result:
most messages go thru but every once in a while one gets rejected.
And I can assure you even when the retune messages says it was rejected
because of an RBL the user doesn't understand. All he knows is he
couldn't send email to that address. At that point, most users just
give up.

I am curious at what filtering that you are using that is having such a
high false positive rate. The state of the art that can be obtained
with DNSbsl is > 80% with out a DHCP list, and well into the 90% in spam
detection. The false positive rate with out a DHCP list is too low to
measure, and below the rate of which e-mail gets lost from
human/network/server issues. With a DHCP list, the risk of rejecting a
good e-mail increases to about .001 percent. Again, more good mail
probably gets lost for other reasons beyond the mail server operator or
network administrators control.

So what DNSbls are you using that generate these higher rates of false
positives?

Maybe we are using the term "false positive" in different ways. Based on
the fact that using BL's of pretty much any type I am familiar with reults
in denying the message before seeing any of it, how do oyu know it wasn't
a legitimate message as opposed to SPAM (which is my definition of a "false
positive".)

I am not sying that the DNSbls have bad data, I am saying that everyone
using a site that gets on a bl is not necessarily a SPAMMER.


The only time that I saw two of my former ISP's mailservers get put in a
DNSbl, sample spams obtained from news.admin.net-abuse.email and
spamcop.net (back when anyone could look that up), showed that one
server was operating as an open relay, and the other at the same time
appeared to be either an open proxy or completely owned by the spammer.
The MAPS OPS list will also show sample spams if you are trying to find
out the spam history of a I.P. address.

I have recently seen both Comcast and Google mail servers get rejected.
In the past I have seen Adelphia. There were others, but I can't remember
names off the top fo my head.


And apparently two other very large ISPs also immediately put them in a
local blocking list, based on postings on an internal news group. It
took longer to get those blocks removed than from the DNSbls once the
problem was fixed. These private blocks were noticed by the users more
than the DNSbl listing was.

(RBL amd DUL are a trademark of MAPS and they have taken legal action
against blocking list operators and/or software vendors that use those
terms as generic)


But which is easier and more likely to succeed? Trying to guess a
"keyword" that appears in all this SPAM or searching for keywords
that are relevant to your business?

No, that is a waste of CPU cycles. However almost all spam has a URL in
it that will resolve to a I.P. address that has long been listed as
totally controlled by the spammer.

It is now almost impossible for a spammer to keep a website up long
enough for a spam run on a dedicated hosting company unless that company
is actively supporting spammers only. To get around that, spammers are
trying to host web sites on systems infected with malware.

Which takes us back to the "trusted server" concept. Instead of trying
to guess who not to accept email from establish relationships with people
(or rather with a network) with which you are willing to accept email.


AOL reacted to that first by rejecting all e-mails with only numbered IP
address URLs in them, which forced the spammers to start buying domain
names. The domain names can be changed, but they still usually resolve
to a known controlled I.P.

In article <f53kiv$fr2$1@xxxxxxxxxxxxxxxxx>,
david20@xxxxxxxxxxxxxxxx writes:


However if things are setup correctly the sender should get back a message
saying that they have been blocked because they are on that particular RBL.


And do you really think my father would have understood that message? :-)
I work in the Computer Science Department of University and I doubt that
half the faculty or one tenth of our students would.

When it is done properly though, the mail message about the non-delivery
is done by the server local to the sender. So if that message is not
understandable, the reason for that usually lies with the ISP running
the mail server. And that is the same ISP that the user needs to
contact to get the problem resolved.

No, it isn;t the message, it's the concept. Real people don't know what
an RBL is. I know, I asked. And what's more, although I hadn't really
thought about it before, I, personally, never read all the Reject: messages
I get cause 99% of them are bogus and some I have tested for and found them
to contain viruses.


And most of the mail servers that I have seen allow local customization
of the bounce message they send to their internal network users.
Very obvious when the local system messes up the edits.

Unfortunately it is worse than Bill describes about the quality of the
message.

Many ISPs will suggest that the sender try rebooting their computer to
resolve an issue, and most users are not aware of how competent their
ISP is in these areas.

I think you probably meant "incompetent"!! :-)


I have seen Gmail file bounce messages from mail sent from it in the
spam folder, where POP users will never see them. Now that is a prime
example of broken software. Since a Gmail server generated the bounce
from a reject it received from an authenticated user sending through it,
it should never have a false positive.

Other ISPs silently delete all bounce messages, and some mail servers do
not pass through the reject code and text.

Based on what I see at this end, I can understand doing this. Like so much
of what we used to use in the past these have been turned into just another
method of abuse.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill@xxxxxxxxxxxxxxx | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
.

Relevant Pages

  • Re: How to Bounce mail
    ... Can I use a forward on rule -- back to the sender, ... I am a very ordinary guy, not a spammer. ... Expect to get added to public and private blacklists as a spam ... that you deliver your fake bounce to the correct recipient. ...
    (microsoft.public.outlook)
  • Re: Junk and defeating spammers.
    ... > Also I find something to give spammers a headache. ... > comes in that you use mail.app bounce feature to bounce it back to the ... spammers rely on people being able to contact them and if you spam ... their email address spoofed by a spammer will attest. ...
    (comp.sys.mac.system)
  • Re: There needs to be an international policy
    ... > How do I know these countries have the majority of spammers? ... > These mail servers that serve the spam is one thing. ... The spam REALLY ... > is the links to sites where the spammer lives. ...
    (microsoft.public.security)
  • Re: Filtering spam
    ... > It is very annoying receiving that many times daily. ... and would only be seen in spam. ... "phoney bounce" feature. ... never go to the spammer. ...
    (microsoft.public.windows.inetexplorer.ie6_outlookexpress)
  • Re: Tool to bounce mails
    ... > if there's some script/application that can bounce those, ... > part in annoying the spammer. ... Lots of the addresses spam is "from" are valid addresses because they're ... (Assuming you're running your own mailserver, ...
    (Debian-User)