headers
Hector Santos | 1 Feb 2004 18:16
Favicon

Re: revised draft-malamud-no-soliciting-05


----- Original Message ----- 
From: "Carl Malamud" <carl <at> media.org>
To: <ietf-smtp <at> imc.org>
Sent: Saturday, January 31, 2004 1:37 PM
Subject: revised draft-malamud-no-soliciting-05

>
> Hi -
>
> Based on comments received, I've put a new draft at:
>
> http://trusted.resource.org/no-solicit/
>
> It has also been resubmitted to the i-d queue.  Thanks
> for everybody for your comments.  Please feel free to
> send additional comments to this list, to me, to the
> iesg, or to the forum of your choice.
>
> Regards,
>
> Carl
>
>
>

A few minor comments.  Please take these from the viewpoint of an
experienced developer, technical document writer, reviewer, etc, as if I was
going to use this specification for the first time to implement, i.e.,  it
was endorsed,  I found it on the net and I was going to use the spec for the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Duerst | 2 Feb 2004 21:56
Picon
Favicon

Re: Comments on and FWD: I-DACTION:draft-klensin-emailaddr-i18n-02.txt


Hello John,

I have read your draft. Congratulations, I think it is
extremely well written and well argued.

I have the following comments:

- Editorial: occasionally, please make shorter paragraphs.
   It makes things a bit easier to read.

- Name of the extension: Something a little bit more specific
   than just "I18N" would probably be better.

- 3.4.1: Quite a bit of text is spent on the idea to upgrade
   Web browsers to automagically detect and convert special
   (e.g. ACE-like) encoding forms in the context of Webmail.
   This is a total non-starter, and you should just say so.
   What I have not seen discussed, but is much more feasible
   (although it's still much better to not have to do it) is
   to upgrade the webmail software on the server side to
   convert things from ACE or whatever to actual characters
   (or numeric character references if the charset used in
   the Web page has limitations) and back.

- Editorial: I don't think you have used the term ACE (ASCII
   compatible encoding), but it would be more precise in some cases
   (instead of writing something like 'IDN/punicode-like').

- Editorial: In point 2. of 4.1, it's unclear how many alternatives
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard O. Hammer | 3 Feb 2004 15:38
Picon
Favicon

when to dot-stuff and dot-strip


In an MTA which I am developing, I dot-strip every message body which 
comes in through SMTP.  Later I dot-stuff every message body which 
goes out through SMTP or POP3.  (Reference RFC 2821 section 4.5.2 and 
RFC 1939 section 3 paragraph 4.)

But I never use the message body between the times when I dot-strip 
and dot-stuff.  Unless I am mistaken, I could entirely skip the 
dot-stripping and dot-stuffing, given these functions which I am 
performing.

So, if this sort of optimization is worth considering, I think it 
would entail rethinking the boundaries which surround where message 
bodies need to be dot-stuffed.  Perhaps dot-stuffing would occur when 
a message first entered the SMTP system, dot-stripping would occur 
when a message was handed to some local process where no further 
Internet transport was expected.

Rich Hammer
mailscreen.net
Hillsborough, N.C.
Permalink | Reply | 1 comment |
headers
Tony Hansen | 3 Feb 2004 17:29
Picon
Favicon

Re: when to dot-stuff and dot-strip


If you're ONLY using SMTP and POP, then this is a viable optimization. 
But if you throw in IMAP or direct user access to the files, then the 
optimization gets in the way.

	Tony Hansen
	tony <at> att.com

Richard O. Hammer wrote:
> In an MTA which I am developing, I dot-strip every message body which 
> comes in through SMTP.  Later I dot-stuff every message body which goes 
> out through SMTP or POP3.  (Reference RFC 2821 section 4.5.2 and RFC 
> 1939 section 3 paragraph 4.)
> 
> But I never use the message body between the times when I dot-strip and 
> dot-stuff.  Unless I am mistaken, I could entirely skip the 
> dot-stripping and dot-stuffing, given these functions which I am 
> performing.
> 
> So, if this sort of optimization is worth considering, I think it would 
> entail rethinking the boundaries which surround where message bodies 
> need to be dot-stuffed.  Perhaps dot-stuffing would occur when a message 
> first entered the SMTP system, dot-stripping would occur when a message 
> was handed to some local process where no further Internet transport was 
> expected.
Permalink | Reply | 0 comments |
headers
Hector Santos | 4 Feb 2004 15:42
Favicon

MyDoom, Sorbig - Actions taken?


I hope I am not off topic here with this.

I would be extremely interesting in hearing from SMTP developers here how
they are addressing the latest big problem of the MyDoom virus with thier
customers,etc?  What they have learn to better addressed the problem with
the current specs.

Does anyone have the complete "technical logic" of how this email virus
exploits SMTP?

I know it relies on sending stolen valid addresses and sending "innocent"
looking bounces, but  I believe there are some other "tricky aspects"  about
it  I think may or may not be addressable by SMTP.

If I'm off topic, please ignore. :-)

--

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
Permalink | Reply | 44 comments |
headers
Keith Moore | 4 Feb 2004 23:03
Picon

Re: MyDoom, Sorbig - Actions taken?


> I would be extremely interesting in hearing from SMTP developers here how
> they are addressing the latest big problem of the MyDoom virus with thier
> customers,etc?  What they have learn to better addressed the problem with
> the current specs.
> 
> Does anyone have the complete "technical logic" of how this email virus
> exploits SMTP?

the virus doesn't exploit SMTP.  it exploits mail readers that fail to 
follow the MIME specification.

--
He not busy being born, is busy dying.		- Bob Dylan
Permalink | Reply | 43 comments |
headers
Hector Santos | 5 Feb 2004 04:39
Favicon

Re: MyDoom, Sorbig - Actions taken?


Hmmmmmmm,

It not just about the user. While that is true that top level, the key
problem is the distribution.  That is what makes this SOBIG-generation virus
different from any other normal "Do not open Attachment" email you might
get.

It is more than just "Social Engineering."

The virus success is 100% based on the weakness of the SMTP system and the
current behavior of ANTI-SPAM software to assist in the distribution
process.   It is design exploit the SMTP inability to validate return-paths
and/or sender machines

1)  Initial user gets mail or downloads the virus from somewhere.

2) Virus is installed,  gathers user Outlook  Address book.

3) It begins to send out mail to recepients using a mixed Return Path.

4) Distribution Pattern #1  Mail that gets delivered ->  go to step 1.

5) Distribution Pattern #2 - Expired addresses - Mail bounced back to return
paths.

6) Distribution Pattern #3 - Anti-Spam Software - Filtered Mail bounced back
to return paths.

With the SORBIG virus,  some AVS vendors learned to remove attachment in
(Continue reading)

Permalink | Reply | 42 comments |
headers
Keith Moore | 5 Feb 2004 05:03
Picon

Re: MyDoom, Sorbig - Actions taken?


> It not just about the user.

no, it's the "mail reader" _software_ (the mail user agent) failing to 
adhere to the MIME spec that allows these viruses to propagate so well.
Permalink | Reply | 5 comments |
headers
Valdis.Kletnieks | 5 Feb 2004 05:27
Picon
Favicon

Re: MyDoom, Sorbig - Actions taken?

On Wed, 04 Feb 2004 22:39:53 EST, Hector Santos <winserver.support <at> winserver.com>  said:

> I guess the lack of response means people don't feel this is a problem SMTP
> could help address?

What would help this (and a lot of other security issues) a lot more is
if certain vendors actually paid attention to all the warnings about
transporting active content in e-mail ever since RFC1341 came out like
12 years ago.

Your proposal doesn't really do any good - consider that it's quite
possible for a virus to get loose on an Exchange server and ruin several
thousand people's days without ever going anywhere near SMTP (remember
that some are multi-vector, so all it takes is one Exchange user on Kazaa..)

Putting warts onto one protocol because one vendor can't get another protocol
right is a highly questionable practice at best.  It's the moral equivalent
of reducing the speed limit to 30 on all the interstates because one tire
company had trouble making tires that didn't have the threads fall off at
higher speeds.
Permalink | Reply | 35 comments |
headers
Hector Santos | 5 Feb 2004 06:02
Favicon

Re: MyDoom, Sorbig - Actions taken?


How so Keith?

Can you elaborate what exactly they are not "adhering" to?

What if the attachment was uuencoded instead?

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message ----- 
From: "Keith Moore" <moore <at> cs.utk.edu>
To: "Hector Santos" <winserver.support <at> winserver.com>
Cc: "Keith Moore" <moore <at> cs.utk.edu>; <ietf-smtp <at> imc.org>
Sent: Wednesday, February 04, 2004 11:03 PM
Subject: Re: MyDoom, Sorbig - Actions taken?

> > It not just about the user.
> 
> no, it's the "mail reader" _software_ (the mail user agent) failing to 
> adhere to the MIME spec that allows these viruses to propagate so well.
> 
> 
> 
>
Permalink | Reply | 4 comments |

Gmane