🚀 go-pugleaf

In article <34c238b4.1663293@news.demon.co.uk>
    john@assen.demon.co.uk.nospam (John McCabe) writes:

> A lot of junk mail has the source address set to 99876@12345.com and
> other such crap. Would it be posible to implement a regular expression
> matching algorithm for use in the mail kill so that rather than
> *@compuserve.com, I could use e.g. [0-9]*@compuserve.com to represent
> any purely numerical user field?

I find I can reject this one (and not have any problems with real Compuserve
IDs using [0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]@*.  There may be other
people using purely 8-digit user-ids, but I've yet to see one.

Regexps in mailkill processing are *good*.

--Paul

In article <34c238b4.1663293@news.demon.co.uk>
           john@assen.demon.co.uk.nospam "John McCabe" writes:

> A lot of junk mail has the source address set to 99876@12345.com and
> other such crap. Would it be posible to implement a regular expression
> matching algorithm for use in the mail kill so that rather than
> *@compuserve.com, I could use e.g. [0-9]*@compuserve.com to represent
> any purely numerical user field?

This might be rather tricky with the basic mailkill mechanism
- I presume WinDIS uses the same or similar code to the
standard NET 2.16d.  Both the recent GremNOS version of ka9q
and my own local delivery program (and perhaps YAN/others)
support a keep as well as a kill facility, similar to news
kill.  In order to do what you want, I have the two entries:

 *[0-9][0-9][0-9][0-9]*@*

which gets anything with 4 consec digits as you'd expect,
and

 !*[0-7][0-7][0-7][0-7][0-7].[0-7][0-7][0-7]*@compuserve*

which lets valid Compu$erve mail through, mail which would
otherwise have been rejected by the first rule.

Without a keep facility, the best I can think of at the moment
is:

 *[89]*@compuserve.com 

which should kill mail forged to appear as though from CS,
but only if there's a 8 or 9 in the numeric part (there
usually is, in my experience.)  Perhaps someone else can
come up with a better kill rule for this sort of mail.

It's certainly worth doing - the rules above from my mailkill
account for over 2/3 of the UCE rejections here.
-- 
Pete

pete$no$pam@pdlmail.demon.co.uk wrote:

What you mention here is exactly what I want. I did mean to mention a
keep facility also where you could specify certain names from
somewhere like CompuServe and AOL because all this *@compuserve.com
with 10million users or whatever is a pain from a mailkill point of
view!


>This might be rather tricky with the basic mailkill mechanism
>- I presume WinDIS uses the same or similar code to the
>standard NET 2.16d.  Both the recent GremNOS version of ka9q
>and my own local delivery program (and perhaps YAN/others)
>support a keep as well as a kill facility, similar to news
>kill.  In order to do what you want, I have the two entries:
>
> *[0-9][0-9][0-9][0-9]*@*
>
>which gets anything with 4 consec digits as you'd expect,
>and
>
> !*[0-7][0-7][0-7][0-7][0-7].[0-7][0-7][0-7]*@compuserve*
>
>which lets valid Compu$erve mail through, mail which would
>otherwise have been rejected by the first rule.
>
>Without a keep facility, the best I can think of at the moment
>is:
>
> *[89]*@compuserve.com 
>
>which should kill mail forged to appear as though from CS,
>but only if there's a 8 or 9 in the numeric part (there
>usually is, in my experience.)  Perhaps someone else can
>come up with a better kill rule for this sort of mail.
>
>It's certainly worth doing - the rules above from my mailkill
>account for over 2/3 of the UCE rejections here.
>-- 
>Pete
>


Best Regards
John McCabe <john@assen.demon.co.uk>

Mark Rogers <mark-news@controlware.demon.co.uk> wrote:

>In article <885151496snz@pdlmail.demon.co.uk>, pete$no$pam@pdlmail.demon
>.co.uk writes
>>
>>This might be rather tricky with the basic mailkill mechanism
>>- I presume WinDIS uses the same or similar code to the
>>standard NET 2.16d.  
>
>My understanding was that the standard Demon release of KA9Q doesn't
>support wildcards in mailkill at all. If WinDIS does the same then even
>basic regexp matching as you describe won't work.

To some extent you're correct. I believe WinDis supports only the * as
a wildcard in e.g. *@assen.demon.co.uk, but I believe you are correct
about the regexp matching.

Best Regards
John McCabe <john@assen.demon.co.uk>

"Dave {Reply address in.sig}" <noone@llondel.demon.co.uk> wrote:

>In article <34c238b4.1663293@news.demon.co.uk>
>   john@assen.demon.co.uk.nospam (John McCabe) writes:
>> Hi there,
>> 
>> Here is a brief suggestion I hope you might consider (if you haven't
>> already).
>> 
>> A lot of junk mail has the source address set to 99876@12345.com and
>> other such crap. Would it be posible to implement a regular expression
>> matching algorithm for use in the mail kill so that rather than
>> *@compuserve.com, I could use e.g. [0-9]*@compuserve.com to represent
>> any purely numerical user field?
>> 
>A better bet would be to put in some fancy DNS-lookup stuff, which 
>would get rid of a large amount of junk. Anything without at least an MX 
>record on its source address can them be rejected. Should encourage 
>people to email you with valid addresses and not with a NOSPAM stuck in 
>the middle of their hostname as well :-)

This could be a problem because I have received message from a mail
address that I couldn't look up using WSPing, but that could be
replied to without any problems. Strange huh?


Best Regards
John McCabe <john@assen.demon.co.uk>

In article <885151496snz@pdlmail.demon.co.uk>, pete$no$pam@pdlmail.demon
.co.uk writes
>
>This might be rather tricky with the basic mailkill mechanism
>- I presume WinDIS uses the same or similar code to the
>standard NET 2.16d.  

My understanding was that the standard Demon release of KA9Q doesn't
support wildcards in mailkill at all. If WinDIS does the same then even
basic regexp matching as you describe won't work.

-- 
Mark Rogers (Software Engineer)       -o-      mark@controlware.demon.co.uk
2M_ControlWare, Yaxley, Peterborough, ENGLAND.

In article <34c289a5.337184@news.demon.co.uk>
           john@assen.demon.co.uk.nospam "John McCabe" writes:

> Mark Rogers <mark-news@controlware.demon.co.uk> wrote:
> ..
> >My understanding was that the standard Demon release of KA9Q doesn't
> >support wildcards in mailkill at all. If WinDIS does the same then even
> >basic regexp matching as you describe won't work.
> 
> To some extent you're correct. I believe WinDis supports only the * as
> a wildcard in e.g. *@assen.demon.co.uk, but I believe you are correct
> about the regexp matching.

Seems to me then that the obvious course of action is to
upgrade to GremNOS or YAN or a recent flavour of NET/Textwin
that has the fuller regexp mailkill.  I've never used WinDIS
but understand it uses the same filesystem convention as the
plain DOS software?

One other possibility (if WinDIS supports SMTP 'queue' mode)
is to use my DELIVER bolt-in if you can figure out a way of
integrating it.  This provides not only regexp mail kill/keep
but also 'mail-scoring' rules, where each line of mail is
scored according to content - it won't prevent downloading
the mail, but will file it in a suitable place :-)  In a
logical place on ftp.demon, though can't recall the URL at
the moment...
-- 
Pete
        "We have not inherited the earth from our ancestors,
         we have borrowed it from our descendants."

In article <885238424snz@pdlmail.demon.co.uk>, pete$no$pam@pdlmail.demon
.co.uk writes
>
>Seems to me then that the obvious course of action is to
>upgrade to GremNOS or YAN or a recent flavour of NET/Textwin
>that has the fuller regexp mailkill.  I've never used WinDIS
>but understand it uses the same filesystem convention as the
>plain DOS software?

Same filesystem, yes. But it actually runs alongside a winsock and
therefore runs at the same time as web browsing, etc. Demon's KA9Q and
its variants would need to be run standalone (and therefore require a
seperate dial-up). They're also not so user-friendly to a Windows user
(which is why us DOSers like it so much :-)

Is there a version of KA9Q which will run using winsock? That would be a
very useful port, but whether or not it is feasible I don't know. I know
there are versions which run off alternative stacks, but whether they
can interface with Windows I don't know.

-- 
Mark Rogers (Software Engineer)       -o-      mark@controlware.demon.co.uk
2M_ControlWare, Yaxley, Peterborough, ENGLAND.

In article <885151496snz@pdlmail.demon.co.uk>,
 <pete$no$pam@pdlmail.demon.co.uk> wrote:

> *[89]*@compuserve.com 
>
>which should kill mail forged to appear as though from CS,
>but only if there's a 8 or 9 in the numeric part (there
>usually is, in my experience.)  Perhaps someone else can
>come up with a better kill rule for this sort of mail.

It's not quite as simple as that.  There are now two formats of
Compuserve email addresses.  The old style user-id format
(octal.octal@compuserve.com) remains valid.  However there is now the
new style alphanumeric_alias@compuserve.com, designed to give Compuserve
users more normal looking email addresses.  I forget the exact
restrictions, but there is no reason why 8s and 9s shouldn't be present.
What you need to reject (according to most of the forged Compuserve
addresses I see) are a number or a dotted pair of numbers that contain
an 8 or a 9.

-- 
John F Hall

In article <6a4ua8$obd$1@avondale.demon.co.uk>
           jfhall@avondale.demon.co.uk "John F Hall" writes:

> In article <885151496snz@pdlmail.demon.co.uk>,
>  <pete$no$pam@pdlmail.demon.co.uk> wrote:
> 
> > *[89]*@compuserve.com 
> >
> > [snip]
> 
> It's not quite as simple as that.  There are now two formats of
> Compuserve email addresses.  The old style user-id format
> (octal.octal@compuserve.com) remains valid.  However there is now the
> new style alphanumeric_alias@compuserve.com, designed to give Compuserve
> users more normal looking email addresses.  I forget the exact

Yes - I'd forgotten about those (though none of the Compuserve
folk I correspond with have digits in their "new-style"
addresses.  That's not to say it can't happen though).

> restrictions, but there is no reason why 8s and 9s shouldn't be present.
> What you need to reject (according to most of the forged Compuserve
> addresses I see) are a number or a dotted pair of numbers that contain
> an 8 or a 9.

...which is what I have in my own mailkill/keep.  Still not
foolproof, I'll admit, but until I inadvertently trigger the
first rejection of mail from john_1234_hall@compuserve.* 
I'll live with it :-)
-- 
Pete
        "We have not inherited the earth from our ancestors,
         we have borrowed it from our descendants."

In article <aPzM8DA1eIx0Iw6x@controlware.demon.co.uk>
           mark-news@controlware.demon.co.uk "Mark Rogers" wrote:

>Is there a version of KA9Q which will run using winsock? That would be a
>very useful port, but whether or not it is feasible I don't know.

I should dearly love to see YAN with an option to run with winsock on
Win95...

Roger

--
 /~~\_/~\ BEWARE ,,,  |~) _  _  _  _  |~)    __|_ _  _  \    / _  __|_
|  #=#======of==#   | |~\(_)(_|(/_|   |_)|_||  | (_)| |  \/\/ (/__\ |
 \__/~\_/ FILKER ```         _|          roger@firedrake.demon.co.uk
Vote Chris Bell for TAFF in 1998    http://www.firedrake.demon.co.uk/

In article <885314832snz@wash.demon.co.uk>
           john$@wash.demon.co.uk "John Washington" writes:

> p@p> Seems to me then that the obvious course of action is to
> p@p> upgrade to GremNOS or YAN or a recent flavour of NET/Textwin
>      ^^^^^^^
> 
> A WinDIS user might reasonably consider that not to be an
> upgrade.  Surely the big advantage of running WinDIS is

Maybe I left out the winkey-smiley?

Actually I was being half-serious; if spam is becoming that
much of a problem, it would be at least worth considering
using a modern NET/tw to collect mail (and perhaps news)
and switch off SMTP in WinDIS (assuming one can).  Agreed
it's two calls instead of one - what price spam-killing?

> that it uses WinSock, so alongside WinDIS you can run NetScape
> or whatever.  How you can do that with NOS unless
> you know how to add a packet shim that gets NOS talking via
> WinSock?

Wouldn't mind betting that (a) someone has done it and (b)
some folk would find it very useful.  Not me on either count
I hasten to add.
-- 
Pete

In article <885404300snz@pdlmail.demon.co.uk>
    pete$no$pam@pdlmail.demon.co.uk writes:

> In article <6a4ua8$obd$1@avondale.demon.co.uk>
>            jfhall@avondale.demon.co.uk "John F Hall" writes:

> > restrictions, but there is no reason why 8s and 9s shouldn't be present.
> > What you need to reject (according to most of the forged Compuserve
> > addresses I see) are a number or a dotted pair of numbers that contain
> > an 8 or a 9.
> 
> ...which is what I have in my own mailkill/keep.  Still not
> foolproof, I'll admit, but until I inadvertently trigger the
> first rejection of mail from john_1234_hall@compuserve.* 
> I'll live with it :-)

I have yet to see more than one mail with a forged compuserve numeric
address (and even that one got the dot in the wrong place).  That one
came from the idiot who now uses 8-digit user-ids without a dot and
uses random ISPs (occasionally compuserve) and invalid domains.

I catch him with [0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]@*.  Theoretically
this blocks other valid correspondents, but I've yet to see mail from
such (I do check with POP3 and no mail to me from a user-id of this type
has been anything other than junk).

Yes, I know that bouncing to the invalid domains wastes resources.  But
bouncing to the valid ones gives ISPs a legal reason to pursue the junk
mailers - AOL successfully claimed damages from one who caused lots of
bounces to end up with them.  I suspect that legal action by ISPs over
bounces because of forged addresses may be more successful in preventing
this sort of thing than complaints to abuse addresses of the real ISP. If
you complain to abuse@ the junk mailer gets kicked off and finds another
ISP.  If you bounce and AOL sue for damages the junk mailer may be in no
position to do it again, even if he wanted to.

Even the bounces to invalid domains may persuade ISPs whose users receive
junk mail to institute stricter AUPs because they get to see exactly how
much damage junk mail causes.  It may even persuade them to setup junk
filters on their incoming mail relays.

--Paul

On Tuesday, in article <885315010snz@wash.demon.co.uk>
     john$@wash.demon.co.uk "John Washington" wrote:

JW> On Sunday, in article <885188192snx@llondel.demon.co.uk>
JW>      noone@llondel.demon.co.uk "Dave {Reply address in.sig}"
JW>      wrote:
JW> 
JW> Di> A better bet would be to put in some fancy DNS-lookup stuff, which 
JW> Di> would get rid of a large amount of junk. Anything without at least an MX 
JW> Di> record on its source address can them be rejected. Should encourage 
JW> Di> people to email you with valid addresses and not with a NOSPAM stuck in 
JW> Di> the middle of their hostname as well :-)
JW> 
JW> Are MX records reasonably reliably available?  I like the sound
JW> of this method, but not if it means I risk bouncing valid mail
JW> from remote but valid corners of the world.

I would be wary of it, especuially given the generally flaky
state of Demon's DNS caches of late.

I run a few mailing lists via a server in Australia (cos it's
a friend's server, and she'll happily host the lists I want).

Most of the recipients are in the UK, and receive mail with no
problem, but ...  one the .ac.uk sites has now started using
just this sort of MX lookup as an anti-spam jobby.  Problem is,
their link is slow and congested, and JANET's intl connectivity
can be pretty saturated, so the lookup often times out --
so the mail is bounced :(

We got round this by routeing the mail through another friendly
node in Canada, but it has taught me that if you are going to
*reliably* use a DNS-based verification method, you'd better
be prepared to set *very* long timeouts.  No prob with a leased
line, but expensive on a dial-up.   So unless you own a telco
I'd scrub the idea :(

As an aside, and in case you're wondering why this .ac.uk site
has a bad set-up, the story (as I have been told it) is sad --
almost worthy of comp.risks.  Like all universities these days,
they are short of cash, so pay their staff in fragments of
peanuts.  Still, they had some good ppl.  But then some wise
bureaucrat decided to split the growing computer services dept
into academic computing and administrative computing: sound
enough, except that the techies then wisely reasoned that since
the admin ppl are good at keeping the $$$s for themselves,
they'd join the admin team if possible, and structured things so
that most them went there -- including all the good ppl.  And one
or two goofs are left to cope with all the demands of the
academic staff, most of whom seem to just want their email to
work.  Which it doesn't ... 

Claire

(anti-spam address in use -- you can reply directly for the
next few weeks, but thereafter pls change username to "c-mac")


-- 
Anti-spam address in use.  The address given will be valid
for a few weeks; thereafter, change the username to "c-mac"
when replying