In message <[log in to unmask]>, "Emerson, Tom"
<[log in to unmask]> writes
>In a semi-related thread on another list [thankfully, not replicated to
>a newsgroup so far as I know] someone mentioned a two-part
>"co-conspirator" to the problem: verisign.
>
>It seems that Verisign, the holders and maintainers of a large part of
>the domain name registry, made an arbitrary (it seems) decision to
>break a fundamental part of the DNS as a whole: instead of returning a
>"failure" status for bogus domains, they now return a LEGITIMATE IP
>address for anything "not resolved".  For web traffic, this will direct
>you to their sign up page so you can register said domain [that you
>most likely mistyped anyway]; for all other traffic, such as SMTP edit
>checks against the SOURCE of the message, it will likely go to a black hole...
>
>Now, for those that haven't made the connection as to why this is a
>"bad thing", consider my last comment there: SMTP edit checks.  Yes,
>one part of the "war on spam/UCE"  **WAS** to verify that the domain of
>the sender is in some way "legitimate".  This is because many spammers
>& worms simply "make up" a domain to make the message appear
>"legitimate" to the end user [security.microsoft.org, for example...]
>When the top-level DNS resolve returns "no such address", many SMTP
>programs simply drop the message right there [and I'm told this cuts
>50% of the spam in it's tracks]  Now that ANYTHING in ".com" resolves
>to an IP, well...

Well, at least there's an advisory out against it now....

>> -----Original Message-----
>> From: Roy Brown [mailto:[log in to unmask]]
>>
>> In message <[log in to unmask]>, John
>> Lee <[log in to unmask]> writes
>> >Good (or bad) Morning:
>> >
>> >It's Monday and I'm still getting these.  My ISP theorizes [...]
>> >Does anyone have ideas about:
>> >1.  Filtering software to block emails that carry .exe files?
>>
>> Lots of email software can, lots of spam filters can, lots of
>> specialist programs can.
>
>This can get to be a sore/sticky point, but I'd venture to guess that
>while an ISP would **LOVE** to install a unilateral "block this type of
>message" rule, there will be some "legitimate" traffic in which having
>"blocked" said message would result in lots of (justified) finger
>pointing and name calling.  Therefore it falls upon the end users to
>install this type of software (and then monitor what it is doing)

Sometimes I might want to email somebody a program - possibly even
myself on another machine. If I couldn't send it as an .exe, I'd send it
as something else - and the WinOSes are a bit too good at saying 'well,
I don't care what it's called, I know what it *is*, and I'll treat it
accordingly'.
Hence circumvention.

ISPs wouldn't dare touch your traffic - too easy to screw up - unless
that was (like AOL) the deal from the get-go. Though Demon here, home to
some of the most rabid "you toucha my traffic, I suea your pants off"
denizens on the 'net will be blocking this worm as of now. (Demon is
famous for offering the Internet as 'raw' as can be, and consequently
attracts the knowledgeable person who values that. Plus of course, those
who knew nothing of the Internet, and chose them because they had an
all-in-one connection software package in the days of non-M$ Winsocks.
Still, I expect we've transmuted into the first camp by now)

>One possibility [especially for those still on "dial-up"] would be to
>use either "pop-filters" (I'll explain) or "remote/offline" mail mode
>[of outlook]. On my system at home, using kmail [which is a Linux-based
>e-mail client] it has what it calls "pop-filters", which simply means a
>filter that looks at "just the headers" and makes a decision to
>download, delete, or hold messages.  The general rule-of-thumb is to
>only apply these "pop-filters" on messages over a certain size [like
>50kb, though these "security" messages tend to be 140k, this "limit"
>can be easily bumped a bit]

Turnpike, which I use, can apply rules at three levels on POP3; on the
logical reconstructed envelope, as it would be if SMTP was in use; on
the headers; and on the body. So you get 'pop-filters' on every message,
of you want. Trouble is, it's hard to filter these worms reliably,
except on Body rules, and you have to get the whole thing to do that.

I'm using a tool which shows me the headers of all the waiting mail, and
just checking there's nothing there that's non-spam and over 140k,
before deleting everything over that size. OK, it doesn't get the
mystery 15k ones that seem to have omitted to take on board the payload,
but 15k I can deal with even on full downloads......

>Outlook's "offline" mail mode is similar in that it will download "just
>the headers" first, which will allow you to (manually) decide to
>download/delete/wait-for-later on messages.  While this step is manual,
>it at least saves you from multiple 140kb downloads that you are going
>to throw out anyway.

I found this a bit mysterious; I know it did it with News, and with
Hotmail (which is HTTP), but I'd never come across it for POP3. And I
still can't find it there (OE6); it seems that only with HTTP and IMAP
can you do this (perhaps off Exchange Server for the latter?).

Can I do it with POP3? If so, can you point me to where?

>> More to the point, what's this very limited email software
>> you are using that can't even show you headers?
>
>Most likely outlook -- unless you know where to look, it isn't obvious
>as to how to view the actual headers, and in some cases, you won't get
>the "full" headers anyway.

Right-click on the message, choose Properties/Details, and if that's not
enough, Message Source is all you'll ever need....

>  I'd also guess anyone using "web-based" e-mail doesn't have access to
>the "real" headers either...

My ISP's offering, Demon WebMail gives you that. And why not? They are
'there' with the message. Unlike the 'SMTP envelope', which does need to
be synthesized by something that knows what it's doing.
--
Roy Brown        'Have nothing in your houses that you do not know to be
Kelmscott Ltd     useful, or believe to be beautiful'  William Morris

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *