Hmm incase you haven't got my previous message here is something I got from
my ISP I hope this message will get in...
This is a notification from my ISP about the virus, I guess nobody got
messages from you containing the attached virus file, but a google use
will probably help you, also try to check few viruses && security sites
and the site www.thenet.co.il (hebrew) which have some information about
viruses (at least in my last visit ...)
here is it:
Dear User,
There is a new virus in town, which causes mail message to APPEAR
as though they were sent by you. If you know you didn't send that
specific mail, please ignore them.
<EOF>
On Mon, Apr 22, 2002 at 08:40:08PM +0300, Eran Tromer wrote:
> Eli Marmor wrote:
> > Eliran wrote:
>
> > It's very nice of the subscribers of this list that everybody
> > volunteers to help or find solutions for this problem, from using
> > amAVis, to checking the headers. But the sad truth is that there is no
> > solution. Maybe except for publishing ads in all the leading newspapers
> > in the world, telling everybody: "The viruses that you've received from
> > us were sent to you from friends of you, not from us"...
>
> Indeed.
> And the only long-term solution is to educate users about signed e-mail,
> and to help and/or pressure producers of e-mail software to improve
> their S/MIME and PGP support. Signing should be enabled by default, and
> possibly also encryption (though here there are political hurdles).
> Unsigned plaintext e-mail is a historical remnant that must be abolished.
>
> To name one culprit, I find it preposterous that to this date Mozilla
> has a half-cooked S/MIME support and no PGP support.
>
>
> The toughest part is key distribution. Both the existing centralized
> solutions and the distributed ones are highly problematic for common
> use: to use S/MIME you essentially have to obtain certs from VeriSign
> (or its subsidiary Thawte), and to use PGP you need to know people who
> know people, or to use external verification channels.
>
> However, if the only authentication we care about is "this e-mail was
> sent by someone who owns this e-mail address", then it's possible to use
> an existing distribution network, namely DNS, because you can trust a
> domain owner to certify e-mails coming from his domain. I propose the
> following.
>
> When an e-mail account is created, a PGP key pair is generated. The
> private key is given to the owner of the account. The public key is
> published by the SMTP server serving this account (determined according
> to the MX DNS record), using an extension to the SMTP protocol (say,
> using a new "PKEY OF" SMTP command).
>
> When you get a signed email from [EMAIL PROTECTED], your mail client contacts
> mail.isp.com:25, issues a "PKEY OF [EMAIL PROTECTED]" command, and declares
> the e-mail valid iff it got a public key which matches the signature.
> The public key may be cached.
>
> Problem: the SMTP server may need to delegate the request in real-time
> to another SMTP server. The SMTP e-mail infrastructure is not designed
> for this kind of real-time stuff.
>
> An alternative would be to do all communication via standard e-mail.
> Namely, upon receipt of a mail from [EMAIL PROTECTED], your mail client would
> send a message to "[EMAIL PROTECTED]" containing
> "[EMAIL PROTECTED]" as the body. The ISP's SMTP server would (hopefully)
> recognize this and reply with the approptiate public key [1]. This is a
> true end-to-end solution that's transparent to proxies and firewalls.
> Latency may be pretty harsh, but some client-side caching would go a
> long way to address this, since the e-mails about whose authenticity you
> care are usually ones you've seen before.
>
> Another alternative is to get the public key from the ISP via HTTP (and
> thus get free caching, firewall and proxy support). The URL can be
> published via the DNS infrastructure.
>
> One more point -- how do the messages get signed? Preferably by the
> sender's mail client, but if there's some reasonable authentication
> setup between the sender and its ISP (say, by login password and IP
> address) then the ISP may add the signature automatically. This can
> greatly speed up the transition to such a system.
>
> I think that if a solution of this sort is standardized and
> appropriately evangelized, within a few years the majority of e-mails
> will be signed. The time to start is now.
>
> Wadd'ya think?
>
>
> Regards,
> Eran Tromer
>
> [1] You'll want to add a cooky to prevent an adversaty from spoofing the
> e-mail reply. BTW, note that all of these solutions are susceptible to
> DNS spoofing and TCP man-in-the-middle attacks during the public key
> request. That's still a great improvement over today's situation, and
> will be automagically solved with IPv6 and a secure DNS infrastructure.
>
>
> =================================================================
> To unsubscribe, send mail to [EMAIL PROTECTED] with
> the word "unsubscribe" in the message body, e.g., run the command
> echo unsubscribe | mail [EMAIL PROTECTED]
>
>
--
<a href="http://eg-site.tripod.com";>Eliran</a>
I got food poisoning today. I don't know when I'll use it.
-- Stephen Wright
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
