Well, after all those outages to upgrade the mailservers, it's back to being
as bad as it ever was. Some observations:
My ntlworld addy gets 100+ spam messages a day. It's not that hard to cope
with; I use spampal & OE's filters and most of it doesn't make it past the
server. But here's the point: all the spam I get is To/CC:'d exclusively to
ntlworld addresses. A few months ago, I set up a "delete-on-server" rule for
anything CCd to ntlworld addies with the same first letter as mine. It
rapidly collected about 300 addies.
One of the by-products of this is that you get a good feel for how much spam
ntlworld as a whole's getting. Specifically, in the last 10 days or so, not
only have total spam volumes gone up; I've also seen enormous numbers of new
addies that fit the To/CC: criterion above.
In other words, a new "millions" CD full of ntlworld addies has appeared on
the spammer scene. And surprise surprise: at exactly the same time
ntlworld's mailservers have slowed to a crawl again!
So: ntlworld's spam-strategy appears to be, zero server-side filtering and
increased bandwidth to cope with the rising tide of crap. (Which within
weeks of an upgrade is *already* struggling to cope.) This of course means
that ntlworld addies are particularly valuable to spammers, as they know
anything sent to them will get through. (Unless it's filtered by the
recipient - but anyone filtering spam is never going to buy anything from a
spammer anyway, so that's far less of a problem to them than server-side
filtering.)
When is ntlworld going to bite the bullet and accept that they *have* to
start filtering spam at their end if they want to run a mail service that
reaches acceptable standards?
--
> When is ntlworld going to bite the bullet and accept that they *have*
> to start filtering spam at their end if they want to run a mail
> service that reaches acceptable standards?
I just saw someone complaining that Freeserve had gone too far and just
about all his mail was ending up in a spam folder, including not only
legitimate list mail, but also mail from friends. I doubt there's
anything that would satisfy everybody.
I might add that my ntl mail is behaving just fine, at the moment,
despite the address used here, and another, getting their fair share of
spam. I have another couple that get none at all, and I can see from
those just what sort of dictionary attack is happening, they don't start
with kat. Nor for that matter are they used publically.:-)
--
kat
>^..^<
>chopsmcp said
>
>> When is ntlworld going to bite the bullet and accept that they *have*
>> to start filtering spam at their end if they want to run a mail
>> service that reaches acceptable standards?
>
>I just saw someone complaining that Freeserve had gone too far and just
>about all his mail was ending up in a spam folder, including not only
>legitimate list mail, but also mail from friends. I doubt there's
>anything that would satisfy everybody.
Possibly, but there are a few things that would come pretty close to
being universally acceptable. For a start, NTL could filter out
anything with a set of alphabetically sequential NTLWorld email
addresses in the To or Cc lines - that's a sure-fire sign of spam, as
the chances of it being a legitimate multi-recipient email are close
to nil. And there are other things, like sender domain checking, which
rarely if ever give false positives.
More to the point, even non-agressive filtering will deal with most
spam, while leaving the chances of a false-postive acceptably low. As
it happens, I don't actually get my main incoming email via NTL (I use
Gradwell.com), so I've been experimenting with a combination of
server-side and client-side filtering to find the most effective
combination. So far, I've found that Spamassasin on the server at a
very weak level (I'm using it at 7) flags about 80% of spam, with
absolutely no false positives so far. What gets through is then
checked again by my more aggressive client-side filtering (using
Spampal). This does generate some false positives, but that's not a
problem as the "spam" mailbox is small enough for me to manually scan
through it for anything I want to keep before deleting the rest.
So, even assuming that the majority of NTL users won't want (or know
how) to install client-side filtering, NTL could still cut out most of
the spam by using a weak server-side filter, and have minimal risk of
false positives.
Mark
--
--> http://photos.markshouse.net - now with added kittens! <--
"Come on you target for faraway laughter, come on you stranger,
you legend, you martyr, and shine!"
> [cross-posted: hope people feel it's legitimate]
>
> Well, after all those outages to upgrade the mailservers, it's back
> to being as bad as it ever was. Some observations:
>
> My ntlworld addy gets 100+ spam messages a day. It's not that hard to
> cope with; I use spampal & OE's filters and most of it doesn't make
> it past the server. But here's the point: all the spam I get is
> To/CC:'d exclusively to ntlworld addresses. A few months ago, I set
> up a "delete-on-server" rule for anything CCd to ntlworld addies with
> the same first letter as mine. It rapidly collected about 300 addies.
>
I was with NTLWorld. I used to get spams that were specifically
addressed to NTLWorld users, in the sense that the marketing puff spoke
to NTLWorld users - like "To all NTL World users: EXCLUSIVE OFFER!".
It's not beyond the bounds of possibility, to my mind, that NTL have an
"arrangement" with some murketer or other. Based on my experience, I'd
be inclined to trust them about as far as I could throw their
head-office building.
--
Jack.
> And there are other things, like sender domain checking, which
>rarely if ever give false positives.
Sender domain checking? Making sure the sender IP corresponds to the
'from' domain? If that's so then none of mine would *ever* get
through..
Maybe I'm wrong, but if that's what you mean by sender domain checking
then I promise you _numerous_ false positives.
--
Dave Johnson - req...@freeuk.com
>In MsgID<bkln8052t2t87n1mb...@news.markshouse.net>
No, I simply mean checking that the domain exists. A slightly more
useful check is to look for valid MX records as well, but that's a
little more controversial as MX records are not actually required by
the relevant RFCs.
Mark
--
--> http://www.FridayFun.net - now with added games! <--
"Life is bigger, it's bigger than you"
I'm happy with it as I get only 2 spams per week.
--
Yours
Zebedee
(Claiming asylum in an attempt
to escape paying his debts to
Dougal and Florence)
To which I'd add: their current approach is *already* losing legit mail. EG:
during their regular Monday night "upgrade outages", they regularly lost all
mail sent to me over an eight hour period. Also, I don't know what the
ntlworld mailbox quota is - but my daily incoming mail's getting up to a
megabyte - the great majority of which is spam. So: how long would you have
to leave that before people started getting over-quota bounces? (And third
parties started getting spam bounced to their addies in faked from fields
for the same reason?)
> No, I simply mean checking that the domain exists. A slightly more
> useful check is to look for valid MX records as well, but that's a
> little more controversial as MX records are not actually required by
> the relevant RFCs.
Checking that at least one of the SMTP envelope From, the From: header
or the Reply-To: header (if present) is valid would seem a reasonable
server-side check. And if the From: header is missing (or there is
a Received: header after it, indicating that an MTA or MUA has inserted
it because it wasa missing) the message is automatically suspect.
On the other hand, I don't receive all that much spam compared to a lot
of people. 50 or so per day, across all my domains (not including the
Committee and Control mail forwarded to me), in spite of being active on
Usenet with a real address which hasn't changed for around 5 years. And
none to my NTL address, just the occasional message from NTL themselves
(but then I don't use that address anywhere at all).
Chris C
Freeserve recently started to mark my mail from gisajob.com as *** SPAM ***
in the subject field. Does anyone know if this method is a replacement for,
or an addition to Freeserves failure to deliver mail with certain single
line message bodies, as a crude way of filtering w32Netsky variants.
Graham.
%Profound_observation%
> [cross-posted: hope people feel it's legitimate]
>
> Well, after all those outages to upgrade the mailservers, it's back to being
> as bad as it ever was. Some observations:
>
<snip problems with NTL getting shed loads of SPAM>
I forward all mail to my NTL addy to work now and let the filters there sort
out the spam.
It catches about 90% of the spam and I get one false positive a week which
isn't a great loss.
I would indeed be far happier to have NTL spam-check my mail, but since a
certain percentage of the spam is for Norton Internet Security (including
Norton Anti-Spam) perhaps there is indeed an arrangement out there ;-)
TOny
>>Maybe I'm wrong, but if that's what you mean by sender domain checking
>>then I promise you _numerous_ false positives.
>
>No, I simply mean checking that the domain exists.
My mistake, thanks.
>A slightly more
>useful check is to look for valid MX records as well, but that's a
>little more controversial as MX records are not actually required by
>the relevant RFCs.
Hmm, more that I don't understand, it seems to me that an MX record is
by definition required for an email domain??
>
> Hmm, more that I don't understand, it seems to me that an MX record
> is by definition required for an email domain??
>
An MX record is only required if you are supposed to be able to receive
email. It follows that email addresses in the From: and Reply-to:
headers should be for domains with MX records. There's no reason why the
HELO domain (return-path) should have an MX record.
--
Jack.
Heh - more misunderstanding on my part..
Whenever I've used smtp by telnet I've always just given whatever junk
shuts up the 'most people say helo' type error so I don't really think
about it. I can see both sides of the argument over HELO domain
checking and there doesn't seem to be a way to reconcile them.
As an alternative to the microshaft idea of charging for email as an
anti spam method, why not just make it a three stage process? Modify
servers and clients so that
Server receives email (or maybe a blank/dummy)
Server replies to from address with auth-code
Orig client repeats message with auth-code in headers
Seems that would kill a large proportion of spam, and remove the
ability to use a dummy from: address.
If the clients were not only modified to accept and return
authorisation number but also to auto delete anything with the (new)
standard auth header then there would be no problem with queries
caused by spammers mistakenly using a forged from:
No, if there is no MX record then a lookup will be done for the A record
(IP address). Some MTAs will go even further, stripping off subdomains
until they get back to a TLD, trusting that if they try to send to the
parent for a nonexistent subdomain the receiving MTA will reject it.
Some parent domains also have a 'wildcard' MX record to catch anything
sent to a subdomain without its own MX record, a good lookup algorithm
should be able to distinguish that from a specific MX record for that
domain.
I suspect though that the lookup being talked about is for the sending
address, and there is no requirement for that to have an MX record or a
mailserver...
Chris C
> Whenever I've used smtp by telnet I've always just given whatever junk
> shuts up the 'most people say helo' type error so I don't really think
> about it. I can see both sides of the argument over HELO domain
> checking and there doesn't seem to be a way to reconcile them.
Quite a few MTAs do check the HELO domain, and compare it with the
reverse DNS of the originating IP address. However, insisting that they
are the same would break a lot of mail (all of mine, for a start,
whether I go direct (RDNS says something at NTL's dynamic space, the
smarthost will give my HELO name from its IP address).
> As an alternative to the microshaft idea of charging for email as an
> anti spam method, why not just make it a three stage process? Modify
> servers and clients so that
>
> Server receives email (or maybe a blank/dummy)
> Server replies to from address with auth-code
Or Reply-To address?
> Orig client repeats message with auth-code in headers
The client?
> Seems that would kill a large proportion of spam, and remove the
> ability to use a dummy from: address.
Seem to me that it would kill all email stone dead. For a start, if
it's the originating client doing it the final mail would be delayed
until the client was next invoked (possibly weeks). What about list
servers?
> If the clients were not only modified to accept and return
> authorisation number but also to auto delete anything with the (new)
> standard auth header then there would be no problem with queries
> caused by spammers mistakenly using a forged from:
Wouldn't that auto-delete everything? And double (at least) the network
traffic?
Who is going to pay to update every client and server? There are
clients out there dating back decades (OK, over a decade at least), and
who knows how many servers there are. Plus you're putting an additional
delay into it, and one which will depend on the sender (if I send a
message just before going on holiday, I won't fire up my client again
until I get back).
If you are going to do that drastic a change, it needs a totally new
protocol. SMTP is non-secure as designed, no amount of patches to
(mis-)use it for other things is going to work sensibly. Scrap it and
write something designed for security (build in PGP or whatever, for
instance). But it will take years to get accepted and longer to get
built and installed everywhere (and I'd bet that MS would then modify it
and break it)...
Chris C
> Sender domain checking? Making sure the sender IP corresponds to the
> 'from' domain? If that's so then none of mine would *ever* get
> through..
>
> Maybe I'm wrong, but if that's what you mean by sender domain checking
> then I promise you _numerous_ false positives.
No. If you get an email from bill...@hotmail.com then make sure that
hotmail.com exists before accepting the email.
We get a lot of that, too. Since revealing the addresses using To/Cc
is wasteful incompetence for a spammer, this points to a single
source, either a single spam gang, or a single spamming tool bundled
with addresses.
> So: ntlworld's spam-strategy appears to be, zero server-side filtering and
> increased bandwidth [...] This of course means
> that ntlworld addies are particularly valuable to spammers, as they know
> anything sent to them will get through.
We get much more to various Demon addresses, which are efficiently
filtered on the Demon servers. Having used them for years on Usenet
and elsewhere counts for a lot more than the filtering. I'm sure
many spammers are just sending to every address they can lay their
hands on.
That being said, NTL most probably did have an insider or two who
sold NTL addresses (this is not unheard of, sadly). I have a call in
to NTL AUP team to investigate a spam that used a form of address
(@dtn.ntl.com) that we didn't even know existed, and therefore could
not have revealed. Not that I expect a result.
--
Pekka P. Pirinen
Any sentence that begins 'Humans would never be so stupid as to...'
is very probably wrong. - David M. Palmer
> Freeserve recently started to mark my mail from gisajob.com as *** SPAM ***
> in the subject field. Does anyone know if this method is a replacement for,
> or an addition to Freeserves failure to deliver mail with certain single
> line message bodies, as a crude way of filtering w32Netsky variants.
"In addition to", I believe. The only other crude filtering I'm aware
of, is the rejection or dropping of emails with certain subject lines
used by viruses. "Test" and "Hello" are examples. I don't think they
look at message bodies.
Last night I sent 2 emails from one of my freeserve accounts, one with
'test' in the subject and the other with 'test' in the body. The subject one
was deliverd, I am still waiting for the body one.
Last night I sent 2 emails from one of my freeserve accounts, one with
'test' in the subject and the other with 'test' in the body. The subject one
was deliverd, I am still waiting for the body one.
Graham
%Profound_observation%
Last night I sent 2 emails from one of my freeserve accounts, one with
> Last night I sent 2 emails from one of my freeserve accounts, one with
> 'test' in the subject and the other with 'test' in the body. The subject one
> was deliverd, I am still waiting for the body one.
<counts repeated posts>
Well, you certainly have no problems posting to newsgroups! ;O)
--
Ian Cox
Sutton-in-Ashfield
icq 116510696
I assumed this was due to the recent viruses with the above in the subject
line.
--
Regards
Krystian
This has definitely happened at some point. I signed up to NTLworld as a
backup dialup. The email address was *never* used but within a week junk
started coming into the inbox. Presumably it's still arriving and
clogging up their servers. I haven't checked for a very long time.
Dave
--
There are 10 types of people in the world. Those who understand binary,
and those who don't.
>> It's not beyond the bounds of possibility, to my mind, that NTL have
>> an "arrangement" with some murketer or other. Based on my
>> experience, I'd be inclined to trust them about as far as I could
>> throw their head-office building.
>
> This has definitely happened at some point. I signed up to NTLworld
> as a backup dialup. The email address was *never* used but within a
> week junk started coming into the inbox. Presumably it's still
> arriving and clogging up their servers. I haven't checked for a very
> long time.
>
Funny thing, I never get any spam at all on my never-used primary
address. Or anything else for that matter.
--
kat
>^..^<
>Funny thing, I never get any spam at all on my never-used primary
>address. Or anything else for that matter.
Does NTL allow re-use of the username ? Someone I know opened a PAYG
account with FreeUK and that mail address was already getting lots of
junk mail. Seems they happened to choose a popular name so had been
used before (and presumably closed when spam got too much to bear).