Subject: Re: comments on draft-shveidel-mediasize-05 (in Last Call for PS)
From: Nathaniel Borenstein <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: "[email-masked] ' '" <[email-masked]>, [email-masked], [email-masked]
Date: Wed, 28 Jul 2004 15:23:19 -0400
List-Id: <ietf-smtp.imc.org>

I concur with Keith.  I've long believed that there might be value to 
an extension like this, but the value I see doesn't justify this level 
of complexity.  I suggest taking a step back and listing the scenarios 
that justify this extension, with an eye toward either reducing or 
justifying the complexity of the solution.  -- Nathaniel

Date: Wed, 28 Jul 2004 11:16:53 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: comments on draft-shveidel-mediasize-05 (in Last Call for PS)
Sender: [email-masked]

I believe this document should not be approved for Proposed Standard,
for the following reasons (in no particular order)

1. It adds a lot of complexity to SMTP clients and servers that
implement it, and in exchange they get a model which is rather limited
and inflexible. Experience suggests that when someone tries to do this
they're solving the wrong problem, and they need to try a different
tack.

2. Imposing separate quotas for different kinds of media seems to be of
limited applicability. 

3. The proposed extension interacts poorly with multipart/alternative

In many recipient environments (eFax, voice mail, pager, IM) the
potential exists to send a message in alternative formats and to allow
the recipient (or the recipient's MUA, or an MTA acting on behalf of the
recipient) to choose which content to convey to the recipient.  For
instance, the same message could be conveyed by each of voice, image,
and text using MIME multipart/alternative. If the message were being
received by a voice mail system, the image and text portions might be
discarded on receipt by the voice mail system's MTA. But if that MTA
rejected a message because it contained images, the message  would be
bounced even though the MTA could have conveyed the message to the
recipient.

More generally, rejecting on the total size of content might not 
be appropriate when some of those attachments might be discarded
by the recipient, or converted to an alternate format by the reciving
MTA. If the same audio clip were sent using three different codecs, the
receiving MTA might choose to store only one of those.  The sum of the
sizes of those attachments may not be relevant; what's relevant is the 
size of the single attachments that is actually stored.  Similarly
if the same text were sent in three different languages (using
multipart/alternative with content-language body part header fields),
the sum of the text sizes is not relevant; what's relevant is the size
of the text in the language preferred by the recipient.

4. The proposed extension interacts poorly with current and proposed
content negotiation mechanisms.

There are many reasons why an MTA, especially an MTA acting on behalf
of a recipient, might reject a message, or - more to the point - 
modify a message (with the recipient's permission) before delivering
it to a recipient.  These involve not only sizes of the media contained
in the message (byte count, physical dimensions, duration, etc.) but 
also the kinds of encodings used (compression, codecs), the number
of colors, the resolution, sampling rate, etc.  A message might be
of reasonable size after a recipient-authorized conversion, even if 
it appeared to be too large as transmitted on-the-wire. 

The possibility also exists that a receiving-MTA, acting with a
recipient's authorization, could authorize the sending MTA to
perform conversions on its behalf.  In this case the MEDIASIZE
extension and the conversion could send conflicting messages.

It makes far more sense to have a general purpose content-
negotiation/conversion/rejection scheme than to address one aspect of 
content-negotiation (size in this case) separately from the others.

5. The proposed extension overloads the SIZE keyword defined in
RFC 1870.

While it might appear that this only affects mutually consenting
parties and there is no harm done, experience suggests that this
is dubious for two reasons.  One is that bugs do occur and
implementations have been known to use extensions without properly
negotiating them. Another is that firewalls are known to exist which
impose syntactical restrictions on SMTP parameters.  Changing the
format of the SIZE parameter invites both kinds of failures for no
good reason.

Keith

Date: Tue, 27 Jul 2004 13:56:20 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Fw: Last Call: 'SMTP Service Extension for message Media Size declaration' to Proposed Standard
Sender: [email-masked]

I just noticed this.  I wonder why the ADs didn't copy this list on the LC?

-Keith

Date: Tue, 13 Jul 2004 11:48:10 -0400
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Subject: Last Call: 'SMTP Service Extension for message Media Size declaration' to Proposed Standard 

The IESG has received a request from an individual submitter to consider the 
following document:

- 'SMTP Service Extension for message Media Size declaration '
   <draft-shveidel-mediasize-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2004-08-16.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-shveidel-mediasize-05.txt

Date: Fri, 16 Jul 2004 16:43:08 +0530
From: Madan Ganesh Velayudham <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Subject: Re: DELIVER AFTER extension
Sender: [email-masked]

Oops ! Thanks Arnt for the hint.

Apologies for missing that.

Arnt Gulbrandsen wrote:
> Have a look at draft-vaudreuil-futuredelivery-02.txt.
> 
> Arnt
> 
> 

-- 
            Madan Ganesh Velayudham  +91 80 2205 3108
-------------------------------------------------------------
Nothing in life is to be feared.  It is only to be understood.

Date: Fri, 16 Jul 2004 16:07:19 +0530
From: Arnt Gulbrandsen <[email-masked]>
To: Madan Ganesh Velayudham <[email-masked]>
Subject: Re: DELIVER AFTER extension
Cc: [email-masked]
Sender: [email-masked]

Have a look at draft-vaudreuil-futuredelivery-02.txt.

Arnt

Date: Fri, 16 Jul 2004 15:51:09 +0530
From: Madan Ganesh Velayudham <[email-masked]>
To: [email-masked]
Subject: DELIVER AFTER extension
Sender: [email-masked]

Hello,

I'm planning to file a draft for the following :

I believe that there is no mechanism by which a mail client can specify 
the mail server to send a mail after a specific period.

When we send mails, there may/can be a requirement like the mail 
processing should start after a time frame.

     Eg.,

     Send this mail after 30 mins

     MAIL FROM: [email-masked] AFTER 30

There is a DELIVERBY rfc2852 which sets the expiry of the mail. 
Simillarly my draft is planning to set up a starting time.

I think this extension would benefit diskless clients and web based 
email clients and allows the mail server provider an easy interface to 
provide
such a feature.

Any thoughts please ?

MG
-- 
            Madan Ganesh Velayudham  +91 80 2205 3108
-------------------------------------------------------------
Nothing in life is to be feared.  It is only to be understood.

To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: Virus scanning non-structured emails 
From: [email-masked]
Date: Fri, 09 Jul 2004 15:53:28 -0400
Sender: [email-masked]

--==_Exmh_-204645376P
Content-Type: text/plain; charset=us-ascii

On Fri, 09 Jul 2004 12:20:31 PDT, SM <[email-masked]>  said:

> What is the use of having a virus scanner if it doesn't protect the end 
> user who will click on an encrypted zip attachment, enter the password and 
> run the executable? :)

Sometimes, the best technical solution is a baseball bat. :)

--==_Exmh_-204645376P
Content-Type: application/pgp-signature

--==_Exmh_-204645376P--

Date: Fri, 9 Jul 2004 15:35:39 -0400
From: Keith Moore <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Virus scanning non-structured emails
Sender: [email-masked]

> >and relying on a virus scanner to do the right thing is better in what way?
> 
> No, there is no better way.
>
> What is the use of having a virus scanner if it doesn't protect the end 
> user who will click on an encrypted zip attachment, enter the password and 
> run the executable? :)

the point is, people who "rely" on virus scanners to provide are deluded.
a virus scanner doesn't fix the security problem, it merely moves it and
makes the system more complex and harder to understand.

now if you make an effort to discourage user agents that are known to be
insecure, and you want a virus scanner as a backup, that's a different story.

Date: Fri, 09 Jul 2004 12:20:31 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: Virus scanning non-structured emails
Sender: [email-masked]

Hi Keith,
At 11:59 09-07-2004, Keith Moore wrote:
>and relying on a virus scanner to do the right thing is better in what way?

No, there is no better way.

What is the use of having a virus scanner if it doesn't protect the end 
user who will click on an encrypted zip attachment, enter the password and 
run the executable? :)

Regards,
-sm 

Date: Fri, 9 Jul 2004 14:59:48 -0400
From: Keith Moore <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Virus scanning non-structured emails
Sender: [email-masked]

> Relying on the 
> MUA to do the right thing is a recipe for disaster.

and relying on a virus scanner to do the right thing is better in what way?

--
Regime change 2004 - For great justice.

Date: Fri, 09 Jul 2004 11:14:23 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: Virus scanning non-structured emails
Sender: [email-masked]

Hi Paul,
At 05:19 09-07-2004, Paul Smith wrote:
>If an email virus scanner saw an email like this
>
>------------Cut here-----------
>
>Subject: failed message
>From: [email-masked]
>X-comment: Note - no MIME headers at all
>
>Your message failed because we didn't like it, here's the original message:

[snip]

>Would you expect a virus scanner to detect the virus? Should it try? My 
>thinking is that the virus is actually just a gump of larbled text so why 
>should a virus scanner detect it (let's ignore the fact, for now, that the 
>bounce message shouldn't contain the attachment at all, we all know that 
>some servers do that). If the bounce message was structured so that the 
>original message was in a message/rfc822 section, then, yes, I'd say a 
>virus scanner should detect it, but in this case, the bounce message is 
>unstructured plain text, and no email client SHOULD show the 'attachment' 
>as an attachment, because it isn't one.

There was a time when email was about being conservative with what we send 
and liberal with what we accept.  Nowadays, it is the reverse.  There are 
MTAs bouncing messages with the viral attachment included.  This behavior 
can only foster the spread of viruses.

Although the MUA should not show the 'attachment' as an attachment because 
it isn't one, you will come across MUAs that do that.  The 'fix', if we can 
call it that, is to have the virus scanner detect this gump of garbled text 
as suspicious content if there is even the slightest risk.  Relying on the 
MUA to do the right thing is a recipe for disaster.

Regards,
-sm

http://www.qubic.net
Web Infrastructure Solutions 

Date: Fri, 9 Jul 2004 13:48:49 -0400
From: Keith Moore <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Virus scanning non-structured emails
Sender: [email-masked]

> > Actually it's the other way around.
> >
> > It's irresponsible (and a violation of the MIME standard) to produce 
> > mail user agents that present potentially-harmful content.
> 
> Oh, I agree, but one cannot really expect an attacker to refrain from 
> attacking.

especially when one chooses to deploy insecure network software.

> > To say that virus scanners are "responsible" for fixing holes in
> > user agents puts responsibility in the wrong place.
> 
> They sell a product claiming to do so.

fair enough.

Keith

To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Subject: Re: Virus scanning non-structured emails 
From: [email-masked]
Date: Fri, 09 Jul 2004 13:24:28 -0400
Sender: [email-masked]

--==_Exmh_-762764176P
Content-Type: text/plain; charset=us-ascii

On Fri, 09 Jul 2004 22:24:29 +0530, Arnt Gulbrandsen said:

> > To say that virus scanners are "responsible" for fixing holes in
> > user agents puts responsibility in the wrong place.

> They sell a product claiming to do so.

The market for anti-virus solutions to fix the security problems of
the predominant software vendor has gotten so large that said vendor
wants to get into that market.

Given a market that size, you expect A/V vendors to be anything other
than sales-oriented? ;)

--==_Exmh_-762764176P
Content-Type: application/pgp-signature

--==_Exmh_-762764176P--

From: Arnt Gulbrandsen <[email-masked]>
To: Keith Moore <[email-masked]>
Subject: Re: Virus scanning non-structured emails
Cc: [email-masked], [email-masked]
Date: Fri, 09 Jul 2004 22:24:29 +0530
Sender: [email-masked]

Keith Moore writes:
> Actually it's the other way around.
>
> It's irresponsible (and a violation of the MIME standard) to produce 
> mail user agents that present potentially-harmful content.

Oh, I agree, but one cannot really expect an attacker to refrain from 
attacking.

> To say that virus scanners are "responsible" for fixing holes in
> user agents puts responsibility in the wrong place.

They sell a product claiming to do so.

Arnt

Date: Fri, 09 Jul 2004 17:43:53 +0100
To: Keith Moore <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: Virus scanning non-structured emails
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 17:29 09/07/2004, Keith Moore wrote:
>Actually it's the other way around.
>
>It's irresponsible (and a violation of the MIME standard) to produce
>mail user agents that present potentially-harmful content.  It's bad
>enough that they present harmful content in well-formed MIME body parts;
>even worse when they make extra effort to find harmful content that
>isn't properly formatted or labelled and try to present _that_.

(Before people start casting nasturtiums on MUAs :-) )

I've just tested both Outlook Express and Outlook with both my 'faked' 
virus message, and the original message I was sent that prompted my 
original message, and neither of them found an attachment in either of the 
emails - both just saw the base64 encoded attachments in the plain text 
message as a lump of gibberish text (as they should have done)

It would be interesting to see if any other MUAs are broken enough to find 
an attachment in my little test message I sent to the list, but the ones 
which most people claim are the most broken worked properly in that case.

(I can see cases around the edge being treated as attachments by the MUA, 
and being missed by a virus scanner which sticks strictly to the MIME 
standards, but this is pretty clearly a plain text message which just 
happens to contain the same text as a BASE64 encoded virus)

I'd be concerned about a virus scanner trying to find things in emails 
which aren't there - it could potentially lead to a DoS on the virus 
scanner whilst letting a compliant MUA ignore the 'non-attachment' and open 
a truly infected attachment. (I can't see how this could happen, but some 
virus writers can be ingenious..)

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 09 Jul 2004 17:28:33 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: Virus scanning non-structured emails
Sender: [email-masked]

At 15:37 09/07/2004, John C Klensin wrote:

> > I've thought about it and I really can't see any sensible way
> > to actually scan the message.. It looks as if the virus
> > scanning engine is just looking for the text
> > 'Content-Transfer-Encoding:' anywhere in the message text and
> > is trying to decode the following text accordingly. This seems
> > decidedly dodgy to me.
>
>It really isn't dodgy if you have email clients that:
>
>         * Opens things, or can be configured to do so, only
>         according to content-type, not file names or heuristics
>         on content.

That isn't really what I'm saying..

>And, for the specific example you give, yes, if you are
>expecting the MTA to protect MUAs from bad things happening, the
>capabilities associated with the MTA, and the assumptions those
>capabilities make, have to be well-matched to the MUA.
>Specifically, if the MTA-based scanner works on a content-type
>basis only, then the MUA needs to work on a content-type basis
>only.  If not, you need to upgrade (or get rid of) one or the
>other.

What the manual virus scanner is doing is seeing the Content-Type: line 
ANYWHERE in an email message, and processing it

So, it would scan this email message (and find (almost) the EICAR test 
virus - I changed it a bit so it wouldn't be blocked, hopefully)

Is that what you'd expect to see happening, or should it just be treated as 
plain text (which it is)

Content-Type: Base64

WDVPIVAlQEFQWzRcUFpYNTQoUG5wN0NDKTd9JEVJQ0FSLVNUQU5EQVJELUFOVElWSVJVUy1URVNU
LUZJTEUhJEgrSCo=

It would be interesting to see if any email clients (or other email virus 
scanners) can detect that as an attachment...

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 9 Jul 2004 12:29:27 -0400
From: Keith Moore <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Virus scanning non-structured emails
Sender: [email-masked]

Actually it's the other way around.  

It's irresponsible (and a violation of the MIME standard) to produce
mail user agents that present potentially-harmful content.  It's bad
enough that they present harmful content in well-formed MIME body parts;
even worse when they make extra effort to find harmful content that
isn't properly formatted or labelled and try to present _that_.

Given the presence of such user agents, it's somewhat reasonable for
virus scanners to look for harmful content that isn't properly labelled.
But it's ridiculous to expect virus scanners to prevent exploiting all
security holes in software that has security holes by intent, design, 
and sloppy implementation.  

To say that virus scanners are "responsible" for fixing holes in 
user agents puts responsibility in the wrong place. 

--
Regime change 2004 - For great justice.

From: Arnt Gulbrandsen <[email-masked]>
To: Paul Smith <[email-masked]>
Subject: Re: Virus scanning non-structured emails
Cc: [email-masked]
Date: Fri, 09 Jul 2004 20:12:18 +0530
Sender: [email-masked]

Paul Smith writes:
> Would you expect a virus scanner to detect the virus?

Yes. I remember a case where a virus scanner did not catch a virus, and 
let the message through to Outlook (Express?), whose mime parser was 
insufficiently fuzzy to see the binary attachment and let the computer 
be infected.

> Should it try?

Yes. Anything else is irresponsible.

Arnt

Date: Fri, 09 Jul 2004 10:37:48 -0400
From: John C Klensin <[email-masked]>
To: Paul Smith <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: Virus scanning non-structured emails
Sender: [email-masked]

--On Friday, 09 July, 2004 15:00 +0100 Paul Smith
<[email-masked]> wrote:

> 
> At 14:10 09/07/2004, [email-masked] wrote:
> 
> 
>> *MY* thinking is in line with yours - if the lack of MIME is
>> that broken, the virus scanner shouldn't bother.  However,
>> there's 2 points to remember:
>> 
>> 1) the MUA may be silly enough to attempt message reassembly,
>> or auto-parse any HTML/Javascript found in the message (even
>> though it is a text/*PLAIN* by default) - remember we live in
>> a world where "helpful" MUAs will find executable code
>> *inside a .JPG* and run it for you...
> 
> Yes, that's my concern.
> 
> (The thing that brought this issue up was that the virus
> scanning function in our MTA isn't currently detecting a virus
> in the email, but the same virus scanning engine with its
> 'scan inside mailbox' option enabled IS detecting a virus in
> the mail file. So, obviously we're getting complaints that our
> MTA scanner isn't working.)
> 
> I've thought about it and I really can't see any sensible way
> to actually scan the message.. It looks as if the virus
> scanning engine is just looking for the text
> 'Content-Transfer-Encoding:' anywhere in the message text and
> is trying to decode the following text accordingly. This seems
> decidedly dodgy to me.

Paul,

It really isn't dodgy if you have email clients that:

	* Opens things, or can be configured to do so, only
	according to content-type, not file names or heuristics
	on content.  
	
	* If it is willing or able to open things on a
	non-content-type basis, it does so only after warnings
	and has options to configure in virus scanning of the
	body part as part of the opening process.

	* and, of course, uses a limited-capability mechanism to
	read/ open any HTML or similarly dangerous ("capable")
	body parts.

I'm not a security expert but, from my observation of how
malware spreads, use of any mail client that doesn't have that
set of capabilities and behavior is just an invitation to
trouble, which will probably arrive.  In the current Internet
environment, it is an invitation to malware -- more or less the
equivalent of walking around with a "kick me" sign on one's back
-- whether virus scanners are present or not.

And, for the specific example you give, yes, if you are
expecting the MTA to protect MUAs from bad things happening, the
capabilities associated with the MTA, and the assumptions those
capabilities make, have to be well-matched to the MUA.
Specifically, if the MTA-based scanner works on a content-type
basis only, then the MUA needs to work on a content-type basis
only.  If not, you need to upgrade (or get rid of) one or the
other.

      john

Date: Fri, 09 Jul 2004 15:00:08 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: Virus scanning non-structured emails
Cc: [email-masked]
Sender: [email-masked]

At 14:10 09/07/2004, [email-masked] wrote:

>*MY* thinking is in line with yours - if the lack of MIME is that broken,
>the virus scanner shouldn't bother.  However, there's 2 points to remember:
>
>1) the MUA may be silly enough to attempt message reassembly, or auto-parse
>any HTML/Javascript found in the message (even though it is a text/*PLAIN*
>by default) - remember we live in a world where "helpful" MUAs will find
>executable code *inside a .JPG* and run it for you...

Yes, that's my concern.

(The thing that brought this issue up was that the virus scanning function 
in our MTA isn't currently detecting a virus in the email, but the same 
virus scanning engine with its 'scan inside mailbox' option enabled IS 
detecting a virus in the mail file. So, obviously we're getting complaints 
that our MTA scanner isn't working.)

I've thought about it and I really can't see any sensible way to actually 
scan the message.. It looks as if the virus scanning engine is just looking 
for the text 'Content-Transfer-Encoding:' anywhere in the message text and 
is trying to decode the following text accordingly. This seems decidedly 
dodgy to me.

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

To: Paul Smith <[email-masked]>
Cc: [email-masked]
Subject: Re: Virus scanning non-structured emails 
From: [email-masked]
Date: Fri, 09 Jul 2004 09:10:44 -0400
Sender: [email-masked]

--==_Exmh_-1771375024P
Content-Type: text/plain; charset=us-ascii

On Fri, 09 Jul 2004 13:19:09 BST, Paul Smith <[email-masked]>  said:

> Would you expect a virus scanner to detect the virus? Should it try? My 
> thinking is that the virus is actually just a gump of larbled text so why 
> should a virus scanner detect it (let's ignore the fact, for now, that the 
> bounce message shouldn't contain the attachment at all, we all know that 
> some servers do that). If the bounce message was structured so that the 
> original message was in a message/rfc822 section, then, yes, I'd say a 
> virus scanner should detect it, but in this case, the bounce message is 
> unstructured plain text, and no email client SHOULD show the 'attachment' 
> as an attachment, because it isn't one.

*MY* thinking is in line with yours - if the lack of MIME is that broken,
the virus scanner shouldn't bother.  However, there's 2 points to remember:

1) the MUA may be silly enough to attempt message reassembly, or auto-parse
any HTML/Javascript found in the message (even though it is a text/*PLAIN*
by default) - remember we live in a world where "helpful" MUAs will find
executable code *inside a .JPG* and run it for you...

2) You didn't *seriously* expect a virus scanner to pass up a chance to find
a virus and send a spam^H^H^H^Hnote to the almost-certainly-forged From:
advertising its glorious feats of virus detection, did you?

--==_Exmh_-1771375024P
Content-Type: application/pgp-signature

--==_Exmh_-1771375024P--

Date: Fri, 09 Jul 2004 13:19:09 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Virus scanning non-structured emails
Sender: [email-masked]

Sorry if this isn't the right mailing list for this topic, but it seems the 
most relevant I can find..

If an email virus scanner saw an email like this

------------Cut here-----------

Subject: failed message
From: [email-masked]
X-comment: Note - no MIME headers at all

Your message failed because we didn't like it, here's the original message:

----------------------

Subject: Your message
From: [email-masked]
MIME-Version: 1.0
Content-Type: multipart/mixed;  boundary="----=_Boundary"

------=_Boundary
Content-Type: text/plain

My message

------=_Boundary
Content-Type: application/octet-stream; name="document01.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="document01.exe"

<base64 encoded virus>

------=_Boundary--

------------Cut here-----------

Would you expect a virus scanner to detect the virus? Should it try? My 
thinking is that the virus is actually just a gump of larbled text so why 
should a virus scanner detect it (let's ignore the fact, for now, that the 
bounce message shouldn't contain the attachment at all, we all know that 
some servers do that). If the bounce message was structured so that the 
original message was in a message/rfc822 section, then, yes, I'd say a 
virus scanner should detect it, but in this case, the bounce message is 
unstructured plain text, and no email client SHOULD show the 'attachment' 
as an attachment, because it isn't one.

But, what do the panel think?

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

From: "Hector Santos" <[email-masked]>
To: "Dave Crocker" <[email-masked]>, "ietf-smtp" <[email-masked]>
Subject: Re: Revised draft-crocker-mail-arch
Date: Tue, 6 Jul 2004 21:28:40 -0400
Organization: Santronics Software, Inc
Sender: [email-masked]

----- Original Message ----- 
From: "Dave Crocker" <[email-masked]>
To: "ietf-smtp" <[email-masked]>
Sent: Sunday, July 04, 2004 10:24 PM
Subject: Revised draft-crocker-mail-arch

>
> Folks,
>
> (ietf-mxcomp bcc'd, but discussion should be pursued on ietf-smtp
> mailing list.)
>
>
> I have submitted a new version of the Internet Mail Architecture I-D.
> You can access a version at:
>
>
<http://brandenburg.com/specifications/draft-crocker-mail-arch-01.html>
>

Dave,

Great document!

Just a few comments. I hope they are reasonable and useful.

| 4.3. Layers of Identity References

Date: Is required by RFC 2822 section 3.6. Right?  Is there reason why Date:
is not included?

How about Message-ID?  It is very important entity for the MS.

| 6.1 MTA Relaying
|
| MTAs relay mail. They are like packet-switches and IP routers.
| Their job is to make routing assessments and to move the message
| payload data closer to the recipient. It is not their job to
| reformulate the payload or to change addresses in the envelope or
| the content.

Does adding the following or similar make sense?

"...with the exception of adding trace information (to the network control
header block)."

| 6.2.4  MUA Gateways

| The critical distinguish between an MTA and a gateway is that the
| latter modifies addresses and/or message content.

Did you mean "distinction?"

Also,  we support six (6) gates (mail formats/networks) using a central MS
framework.   The following also applies to store & forward user systems as
well mentioned in 4.1.5.

What is very important in the "transformation process" from net to net is
that the message originality, intent and properties be optimally retained to
the highest degree.  This is very important in email where privacy must be
kept during the gating process.  Maintaining Message content originality is
equally and critically important as it can introduce "tampering issues."  As
section 4.3 "Layers of Identify References" shows, the mail content is
authored by the originator.

So probably a replacement of the word "modifies" to "transforms" with an
additional clause to the above sentence would help highlight these critical
points:

"The critical distinction between an MTA and a gateway is that the latter
transforms addresses and/or message content while retaining message
properties (i.e., email privacy)."

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

Date: Mon, 5 Jul 2004 09:24:29 +0700
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: ietf-smtp <[email-masked]>
Subject: Revised draft-crocker-mail-arch
Sender: [email-masked]

Folks,

(ietf-mxcomp bcc'd, but discussion should be pursued on ietf-smtp
mailing list.)

I have submitted a new version of the Internet Mail Architecture I-D.
You can access a version at:

    <http://brandenburg.com/specifications/draft-crocker-mail-arch-01.html>

It has significant changes, notably including:

> Actors:

> Addition of the User/Relay/Provider construct of actors. Labeling of
> these roles has also been added to the tables showing architectural
> function. The distinction of Actors, versus architectural system
> components, is not typical for discussions of email. Therefore it is
> likely that the construct needs refinement. In particular, please
> review the table assignments.

> MDA/MS/MUA:

> The construct of the Message Store has been added. This change is
> intended to reflect the consensus view from online discussion,
> rather than being the editor's view, which has in any event
> changed... However it is likely that it will need significant
> revision or replacement. Please review it carefully!

> Message Identifiers:

> Discussion of message identifiers has been added to the section on
> Email Identities.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>