Re: SpamAssassin



In article <es1e30$fjc$1@xxxxxxxxxxxxxxxxx>, david20@xxxxxxxxxxxxxxxx
writes:

Not quite sure I understand the above
is that

65 spam messages marked as spam
35 messages not marked as spam
of those
12 messages not marked as spam are legitimate mail
23 messages not marked as spam are really spam

Yes.

ie you have a 23% false negative rate using spamassassin with a threshold of 5
but a zero false positive rate.

Yes.

That sounds like a pretty appalling rate of mistakes - either 5 is a
particularly high score to set as a threshold for spamassassin so that most
mail will get through or I'd suspect that the provider isn't keeping the
spamassassin rules uptodate so that the spammers are getting their mail
through. If it is the latter then things will become interesting when the
provider next updates the rules since for a brief period therafter the
situation may be totally reversed with few false negatives and a number of
false positives.

I'll have to investigate how often the rules are updated. Personally,
as long as the total amount tagges as spam is appreciable, I would
rather have a few false negatives as long as I have no false positives.

My provider would send a message to the (alleged) sender if a message is
not relayed to me because it is suspected of being spam. Thus, a
legitimate sender could find out that this was a problem. (I'm not sure
this is a good idea. What I observe myself is that a spammer sends
email to a non-existent address somewhere else with my address (or a
non-existent address in my domain) as the forged sender.
The spam
scanner at the other end sends me (or, if the user doesn't exist, my
Postmaster, who is me wearing another hat) a message that there was a
problem. Maybe, however, the spammer really wanted to spam my addresses
and is using the spam filter at the other site as a spam relay. (Fine
point: for non-existent users, the Postmaster only gets the mail if they
are also syntactially invalid VMS usernames, since I drop all the rest
during the SMTP dialog, since this is by far the most spam I get
(dictionary attack).

Yes this is backscatter and if your provider is accepting mail for your
systems and then running spamassassin on it before sending a bounce then
they are part of the spam problem not the solution. It is not acceptable
nowadays to send a bounce to the supposed sending address after you have
discovered a mail message is spam or contains a virus.

Viruses he drops completely. For spam he sends a bounce, after the
message has been scanned---IF I request that this be done if the
threshold is exceeded. If not, the mail is tagged as spam but delivered
to me.

I think the key word is "discovered". I suppose there is a small
probability that an email is mistakenly tagged as spam and thus not
delivered (if that is what I request). I don't see the logic in
distinguishing between spam and viruses, though. (Viruses might be more
certain in their identification, but if the motivation is to inform the
sender that he is doing something wrong, then why not inform him that he
is sending a virus? Of course, most senders of spam are forged, and on
VMS I don't care about viruses anyway, but that is neither here nor
there.)

Opinions differ. I haven't been able to find a list of generally
accepted (by the white hats) guidelines for spam handling. If you know
of any, point me to them. If not, then even if I agree with you, the
provider can just quote another opinion.

Note: at the moment, everything still comes through to me; it is just
tagged as spam. I don't generate bounces except when I can't avoid it.
(I reject stuff to non-existent users, but that fails for syntactically
invalid VMS usernames, which generates a bounce, most of which bounce
back to me. There are only a few of these a day, though; there are
several hundred attempted sends to nonexistent (but syntactically valid)
usernames.

Some systems can
run an anti-spam product during the SMTP dialogue and can reject the
mail at the end of the DATA part which is acceptable.

From the point of view of preventing backscatter, that's better.
However, the legitimate mistake is not corrected here, either.

There are now some
DNSBLs which list sites which produce backscatter eg Spamcop. I
personally think that is going too far since there are still some
circumstances (account going overquota where the account is not on the
receiving mailserver itself etc) which most mail systems cannot cope
with other than by producing a bounce.

One shouldn't confuse legitimate bounces with backscatter. Presumably,
if my provider gets into a DNSBL due to backscatter he will change his
policies, since he charges for customers (like me) to send through a
"good" server. (Technically, I can do anything locally, but I have a
dynamic IP address and many folks now just reject all of those.)

Unless your Dynamic-DNS provider has a list of all your valid email addresses
then no anti-spam product it runs can determine that a message is for a
non-existent account on your systems.

True, but since no legitimate mail is sent to non-existent users, it
could be flagged as spam based on other grounds.

True but then you have potentially changed an SMTP dialogue rejection of an
invalid address (assuming the connection is to your ALPHA) into a backscatter
bounce message from your provider complaining about spam.

As long as it is spam, that's not a problem.

Question: are the bounces really a problem? If the (forged) sender does
not exist, they will bounce back. Presumably to an account at the
provider which accepts everything, since otherwise (assuming the
original spam is retained in the body of the message, and assuming that
the threshold is always exceeded) a vicious circle is generated with
messages bouncing back and forth. If the (forged) sender exists, then
either he wants to stop spam to himself or not. If not, no problem. If
so, then the bounce will be filtered. Not ideal, but is there really a
situation where people genuinely concerned about spam will be annoyed by
backscatter?

.



Relevant Pages

  • Re: Domain hosting query
    ... and your mailserver bounces the email to the sender - and depending on how ... a spam sender. ... Just to clarify - we don't bounce anything. ... Bounces result in backscatter. ...
    (uk.telecom.broadband)
  • Re: Domain hosting query
    ... and your mailserver bounces the email to the sender - and depending on how ... a spam sender. ... Just to clarify - we don't bounce anything. ... Bounces result in backscatter. ...
    (uk.telecom.broadband)
  • Re: PLUG: PMAS
    ... 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. ... 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? ... And most of the mail servers that I have seen allow local customization of the bounce message they send to their internal network users. ...
    (comp.os.vms)
  • Re: PLUG: PMAS
    ... appeared to be either an open proxy or completely owned by the spammer. ... out the spam history of a I.P. address. ... I have recently seen both Comcast and Google mail servers get rejected. ... I have seen Gmail file bounce messages from mail sent from it in the ...
    (comp.os.vms)
  • Re: Beware of ISP spam filtering
    ... They receive the mail and tell the sender that they've got it correctly. ... Then they open a new connection to the destination server to pass the ... OTOH, if the destination server says no, maybe because the spam or virus ... it can send a bounce to let the supposed sender ...
    (uk.telecom.broadband)