Subject: email document delivery service

From: stanislav shalunov <[email-masked]>
Date: 03 Feb 2005 19:57:41 -0500

Internet-draft announcements, as they are currently generated, include
a MIME-based mechanism to request internet-drafts via email.  Do you
use this feature?  If you do, could you please let me know?

Background: the IETF Tools team is working on a draft,
draft-ietf-tools-notification-03.txt, that specifies the requirements
for a document notification service.  We'd like to better understand
how email document delivery is actually used.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

This message is designed to be viewed at room temperature.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Tim Chown <[email-masked]>
Date: Fri, 4 Feb 2005 08:41:43 +0000

Hi,

Our anti-virus system tags all IETF draft announcements as being potentially
dangerous.  I suspect because of the unusual options to fetch the data that
are encoded in the MIME header.

We would certainly like to see that feature removed from IETF announcements, 
as it seems archaic.   This may not be within the remit of your draft, but 
you may wish to consider what effect various MIME options have on anti-virus 
systems, and potential vulnerabilities that lie within them.

(I can't actually see those headers to comment on, as they are removed before 
the announce gets to me, with a replacement plain text warning attachment :).

Tim

-- 
Tim

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Feb 2005 04:32:46 -0500

--On Thursday, February 03, 2005 7:57 PM -0500 stanislav 
shalunov <[email-masked]> wrote:

> Internet-draft announcements, as they are currently generated,
> include a MIME-based mechanism to request internet-drafts via
> email.  Do you use this feature?  If you do, could you please
> let me know?
>
> draft-ietf-tools-notification-03.txt, that specifies the
> requirements for a document notification service.  We'd like
> to better understand how email document delivery is actually
> used.

Please be a little bit careful about how and where this question 
is asked.  Most of the active participants in the IETF have 
reasonably good, online, access to the Internet with 
cost-effective bandwidth (at least much of the time).  But there 
are people for whom those things are not the case, but who want 
to track our work and should be able to do so.  They may or may 
not read the open IETF list but, given recent volume surges, I'd 
guess most of them do not.   For them, the email access, and 
maybe even the remote-body-part access, can be important 
features -- more important, perhaps, for RFC retrieval than for 
I-D retrieval, but important nonetheless.

While I'm on the subject,

--On Friday, February 04, 2005 8:41 AM +0000 Tim Chown 
<[email-masked]> wrote:

> Hi,
>
> Our anti-virus system tags all IETF draft announcements as
> being potentially dangerous.  I suspect because of the unusual
> options to fetch the data that are encoded in the MIME header.
>
> We would certainly like to see that feature removed from IETF
> announcements,  as it seems archaic.   This may not be within
> the remit of your draft, but  you may wish to consider what
> effect various MIME options have on anti-virus  systems, and
> potential vulnerabilities that lie within them.

Hmm.  There is a case to be made that those external body part 
options are as safe, or safer, than a delivered attachment: you 
can, in principle, inspect either before opening or executing 
it, but I can easily imagine one of those "a good/fun user 
experience is more important than security or bullet-proof-ness" 
MUAs being designed to provide better access for an actual 
virus-checker for the external body parts.  Certainly an 
external body part is as safe and probably safer than an 
imbedded URL, especially in an MUA that opens those URLs 
automatically.

So my instinctive response to that request is "have you 
considered getting your anti-virus software fixed?".

     john

---

From: [email-masked]
Date: Fri, 04 Feb 2005 10:28:10 -0800 (PST)

> as it seems archaic.

The "arhaic" feature you refer to is how I customarily fetch drafts to look at.
I wouldn't look at nearly as many if it were removed. I suspect I'm not alone
in this.

				Ned

---

From: Tony Hansen <[email-masked]>
Date: Fri, 04 Feb 2005 13:43:56 -0500

John C Klensin wrote:
> --On Friday, February 04, 2005 8:41 AM +0000 Tim Chown wrote:
> Hmm.  There is a case to be made that those external body part options 
> are as safe, or safer, than a delivered attachment: you can, in 
> principle, inspect either before opening or executing it, but I can 
> easily imagine one of those "a good/fun user experience is more 
> important than security or bullet-proof-ness" MUAs being designed to 
> provide better access for an actual virus-checker for the external body 
> parts.  Certainly an external body part is as safe and probably safer 
> than an imbedded URL, especially in an MUA that opens those URLs 
> automatically.
> 
> So my instinctive response to that request is "have you considered 
> getting your anti-virus software fixed?".

Our firewall software here also briefly tagged message/external-body 
attachments as dangerous. Instead of just removing the attachment, the 
software deleted the entire message and sent a note saying that they had 
done so. Whoever had installed the software just didn't get it; it took 
us a bit to get them to fix it.

Even more fearful, I have a feeling that they were just following 
instructions provided by the firewall software people, who SHOULD know 
better.

	Tony Hansen

---

From: Bill Fenner <[email-masked]>
Date: Fri, 4 Feb 2005 12:00:19 -0800

[tangent alert!]

> instructions provided by the firewall software people, who SHOULD know

Heh.  You're giving quite a bit of credit to a class of people
("firewall software people") who shipped a default set of rules for
our stateful-inpsection firewall that included a rule "TCP packets on
the FTP control channel must end with CRLF".  So much for being able
to connect to any site that has a welcome banner larger than the
MSS...

  Bill