attachment-0001
<br><font size=2 face="sans-serif">Hi Ira,</font>
<br>
<br><font size=2 face="sans-serif">I am not sure why Health Assessment
does not detect a server that has been attacked and had its antivirus compromised.
I certainly hope that the situation would have been detected before MFD
needed to scan virus. </font>
<br>
<br><font size=2 face="sans-serif">What I want to say is that if a server
has good security on guard, has antivirus, and Health Assessment, and MFD
has its P2600 standard level of security on guard, then I don't think MFD's
antivirus is that necessary.</font>
<br>
<br><font size=2 face="sans-serif">-Nancy</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Ira McDonald <blueroofmusic@gmail.com></b>
</font>
<p><font size=1 face="sans-serif">05/14/2009 04:46 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">nchen@okidata.com, Ira McDonald <blueroofmusic@gmail.com></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">mfd@pwg.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: Resource Service updates for Security</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>Hi Nancy,<br>
</tt></font>
<br><font size=2><tt>The MFD does NOT have access to the current Health
Assessment<br>
for the upstream enterprise server - if that server has been attacked<br>
and had its antivirus compromised, then it behooves the MFD NOT<br>
to trust the firmware blindly - the essence of security is "trust
nobody<br>
more than you have to" - desktops (and now mobile devices) need<br>
antivirus because sometimes the INFRASTRUCTURE systems get<br>
corrupted too.<br>
</tt></font>
<br><font size=2><tt>That was my point.<br>
</tt></font>
<br><font size=2><tt>If an MFD doesn't have sufficient free-standing self-defense,
then<br>
sooner or later that MFD will be quarantined during Network<br>
Endpoint Attachment and Health Assessment by a site policy that<br>
doesn't accept the premise that "security is out-of-scope".<br>
</tt></font>
<br><font size=2><tt>Cheers,<br>
- Ira<br>
</tt></font>
<br><font size=2><tt>Ira McDonald (Musician / Software Architect)<br>
Chair - Linux Foundation Open Printing WG<br>
Blue Roof Music/High North Inc<br>
email: blueroofmusic@gmail.com<br>
winter:</tt></font>
<br><font size=2><tt>579 Park Place Saline, MI 48176<br>
734-944-0094</tt></font>
<br><font size=2><tt>summer:<br>
PO Box 221 Grand Marais, MI 49839<br>
906-494-2434</tt></font>
<br>
<br>
<br><font size=2><tt>On Thu, May 14, 2009 at 4:31 PM, <nchen@okidata.com>
wrote:<br>
</tt></font>
<br><font size=2><tt>><br>
> Hi Ira,<br>
><br>
> I hope the enterprise server itself already has antivirus software
that can<br>
> detect the corruption before MFD retrieve the file. Otherwise, the
antivirus<br>
> does not work well on the enterprise server. If that's the case, what's
the<br>
> use to install antivirus software on MFD then?<br>
><br>
> -Nancy<br>
><br>
><br>
><br>
> *Ira McDonald <blueroofmusic@gmail.com>*<br>
><br>
> 05/14/2009 04:09 PM<br>
> To<br>
> nchen@okidata.com, Ira McDonald <blueroofmusic@gmail.com> cc<br>
> mfd@pwg.org Subject<br>
> Re: Resource Service updates for Security<br>
><br>
><br>
><br>
><br>
> Hi Nancy,<br>
><br>
> Right - my point is, after you verify the digital signature,<br>
> prudent security implementation is to SCAN the firmware<br>
> before making it your next boot image - what if the correct<br>
> digital signature comes from an enterprise server that has<br>
> ITSELF become corrupted? Digital signature's no help.<br>
><br>
> Cheers,<br>
> - Ira<br>
><br>
> Ira McDonald (Musician / Software Architect)<br>
> Chair - Linux Foundation Open Printing WG<br>
> Blue Roof Music/High North Inc<br>
> email: blueroofmusic@gmail.com<br>
> winter:<br>
> 579 Park Place Saline, MI 48176<br>
> 734-944-0094<br>
> summer:<br>
> PO Box 221 Grand Marais, MI 49839<br>
> 906-494-2434<br>
><br>
><br>
> On Thu, May 14, 2009 at 3:00 PM, <nchen@okidata.com> wrote:<br>
><br>
> ><br>
> > Hi Ira,<br>
> ><br>
> > Yes, trusted path, with encryption and signature whenever necessary.
In<br>
> > your case, you need to check the signature before executing.<br>
> ><br>
> > -Nancy<br>
> ><br>
> ><br>
> ><br>
> > *Ira McDonald <blueroofmusic@gmail.com>*<br>
> ><br>
> > 05/14/2009 02:55 PM<br>
> > To<br>
> > nchen@okidata.com, Ira McDonald <blueroofmusic@gmail.com>
cc<br>
> > mfd@pwg.org Subject<br>
> > Re: Resource Service updates for Security<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > Hi Nancy,<br>
> ><br>
> > Trusted path for firmware merely means you know which<br>
> > upstream server was corrupted - at least, if you CHECK<br>
> > the content of the firmware before blindly executing it.<br>
> ><br>
> > And user scripts (and PostScript-like PDL jobs) can be<br>
> > highly effective Denial-of-Service attacks (by crashing the<br>
> > entire MFD or just the Print Service) unless scanned by<br>
> > antivirus/antimalware tools.<br>
> ><br>
> > Those are real threats.<br>
> ><br>
> > Cheers,<br>
> > - Ira<br>
> ><br>
> > Ira McDonald (Musician / Software Architect)<br>
> > Chair - Linux Foundation Open Printing WG<br>
> > Blue Roof Music/High North Inc<br>
> > email: blueroofmusic@gmail.com<br>
> > winter:<br>
> > 579 Park Place Saline, MI 48176<br>
> > 734-944-0094<br>
> > summer:<br>
> > PO Box 221 Grand Marais, MI 49839<br>
> > 906-494-2434<br>
> ><br>
> ><br>
> > On Thu, May 14, 2009 at 2:42 PM, <nchen@okidata.com> wrote:<br>
> ><br>
> > ><br>
> > > Hi Ira,<br>
> > ><br>
> > > P2600 covers the security threats that you mentioned here.<br>
> > ><br>
> > > In short, firmware update must be through trusted path.<br>
> > ><br>
> > > User's document if needed (depending on site security requirement),<br>
> must<br>
> > be<br>
> > > protected from disclosure and/or alteration.<br>
> > ><br>
> > > There are many techniques to protect document disclosure
and<br>
> alteration.<br>
> > We<br>
> > > think the best techniques to prevent from disclosure is
by encryption,<br>
> to<br>
> > > detect alteration is by signing digital signature.<br>
> > ><br>
> > > Many MFPs today do not have these security in place, but
they will<br>
> > > eventually when they comply to the security standard.<br>
> > ><br>
> > > -Nancy<br>
> > ><br>
> > ><br>
> > ><br>
> > > *Ira McDonald <blueroofmusic@gmail.com>*<br>
> > ><br>
> > > 05/14/2009 01:56 PM<br>
> > > To<br>
> > > nchen@okidata.com, Ira McDonald <blueroofmusic@gmail.com>
cc<br>
> > > mfd@pwg.org Subject<br>
> > > Re: Resource Service updates for Security<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > Hi Nancy,<br>
> > ><br>
> > > OK - I'm fascinated.<br>
> > ><br>
> > > What conceivable system security could replace the<br>
> > > need for onboard antivirus software?<br>
> > ><br>
> > > Especially given that many MFDs now update firmware<br>
> > > via a "special" Print Job - and do NOT have digitally<br>
> > > signed firmware packages with an unbroken, network-<br>
> > > accessible chain of authority to a major public Certificate<br>
> > > Authority.<br>
> > ><br>
> > > Certainly scripts and macros invoked in ordinary<br>
> > > Print Jobs are very easily corrupted - users create<br>
> > > them, so they aren't digitally signed - verification of<br>
> > > source does NOT remove the need for verification<br>
> > > that the source system was not in fact corrupted.<br>
> > ><br>
> > > Cheers,<br>
> > > - Ira<br>
> > ><br>
> > > Ira McDonald (Musician / Software Architect)<br>
> > > Chair - Linux Foundation Open Printing WG<br>
> > > Blue Roof Music/High North Inc<br>
> > > email: blueroofmusic@gmail.com<br>
> > > winter:<br>
> > > 579 Park Place Saline, MI 48176<br>
> > > 734-944-0094<br>
> > > summer:<br>
> > > PO Box 221 Grand Marais, MI 49839<br>
> > > 906-494-2434<br>
> > ><br>
> > ><br>
> > > On Thu, May 14, 2009 at 10:54 AM, <nchen@okidata.com>
wrote:<br>
> > ><br>
> > > ><br>
> > > > Hi Ira,<br>
> > > ><br>
> > > > I haven't seen any security certification requirement
that requires<br>
> > > onboard<br>
> > > > antivirus on MFP yet. Not sure what's the basis
of your prediction.<br>
> > > > Antivirus software vendors of course will try to push
their products<br>
> on<br>
> > > any<br>
> > > > platform. If you have not implemented MFP security
standard, properly<br>
> > > > configure the system to secure it, antivirus might
be a good idea to<br>
> > > have.<br>
> > > > But once you have proper security instrumented, antivirus
is not that<br>
> > > > critical. It's nice to have of course.<br>
> > > ><br>
> > > > -Nancy<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > *Ira McDonald <blueroofmusic@gmail.com>*<br>
> > > ><br>
> > > > 05/13/2009 06:20 PM<br>
> > > > To<br>
> > > > nchen@okidata.com, Ira McDonald <blueroofmusic@gmail.com>
cc<br>
> > > > mfd@pwg.org Subject<br>
> > > > Re: Resource Service updates for Security<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > Hi Nancy,<br>
> > > ><br>
> > > > Several vendors currently offer MFDs that incorporate
virus<br>
> > > > scanning of all files and executable modules and that
CAN<br>
> > > > integrate into enterprise antivirus update schemes.<br>
> > > ><br>
> > > > Anyway, it was only an EXAMPLE (not a requirement)
- though<br>
> > > > I think you will find that network endpoint attachment
protocols<br>
> > > > and architectures are ALL going to require that you
certify<br>
> > > > that you have healthy onboard antivirus on your MFD
in the<br>
> > > > very near future.<br>
> > > ><br>
> > > > MFDs running Linux or other general-purpose operating
systems<br>
> > > > are just too dangerous anymore without antivirus (or
firewalls).<br>
> > > ><br>
> > > > Cheers,<br>
> > > > - Ira<br>
> > > ><br>
> > > > Ira McDonald (Musician / Software Architect)<br>
> > > > Chair - Linux Foundation Open Printing WG<br>
> > > > Blue Roof Music/High North Inc<br>
> > > > email: blueroofmusic@gmail.com<br>
> > > > winter:<br>
> > > > 579 Park Place Saline, MI 48176<br>
> > > > 734-944-0094<br>
> > > > summer:<br>
> > > > PO Box 221 Grand Marais, MI 49839<br>
> > > > 906-494-2434<br>
> > > ><br>
> > > ><br>
> > > > On Wed, May 13, 2009 at 5:49 PM, <nchen@okidata.com>
wrote:<br>
> > > ><br>
> > > > ><br>
> > > > > Hi Ira,<br>
> > > > ><br>
> > > > > I agree that<br>
> > > > ><br>
> > > > > "The threat is EXECUTING those Resources
on an Imaging<br>
> > > > > System (the one hosting the Resource Service or
ANY other<br>
> > > > > Imaging System) or even a desktop client system."<br>
> > > > ><br>
> > > > > and<br>
> > > > ><br>
> > > > > "The Resource Service spec should NOT say
anything,<br>
> > > > > anywhere about internal versus external storage
and<br>
> > > > > should NEVER reference a Resource Repository."<br>
> > > > ><br>
> > > > > But I don't think "virus scan" is practical
for an Imaging System<br>
> > like<br>
> > > an<br>
> > > > > MFD or HCD to verify whether the stored or retrieved
Executable<br>
> > > Resources<br>
> > > > is<br>
> > > > > safe to execute. There are many other techniques
to verify the<br>
> > > integrity<br>
> > > > of<br>
> > > > > these type of resources that are more practical
for an MFD or HCD.<br>
> > > > ><br>
> > > > > Did I misunderstand something?<br>
> > > > ><br>
> > > > > -Nancy<br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > > *Ira McDonald <blueroofmusic@gmail.com>*<br>
> > > > ><br>
> > > > > 05/13/2009 05:01 PM<br>
> > > > > To<br>
> > > > > nchen@okidata.com, Ira McDonald <blueroofmusic@gmail.com><br>
> > > > > cc<br>
> > > > > mfd@pwg.org Subject<br>
> > > > > Re: Resource Service updates for Security<br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > > Hi Nancy,<br>
> > > > ><br>
> > > > > Internal or external storage of the Resouces has
NOTHING to<br>
> > > > > do with the security threat in 11.4 below.<br>
> > > > ><br>
> > > > > The threat is EXECUTING those Resources on an
Imaging<br>
> > > > > System (the one hosting the Resource Service or
ANY other<br>
> > > > > Imaging System) or even a desktop client system.<br>
> > > > ><br>
> > > > > The Resource Service spec should NOT say anything,<br>
> > > > > anywhere about internal versus external storage
and<br>
> > > > > should NEVER reference a Resource Repository.<br>
> > > > ><br>
> > > > > Every reference in 11.1 through 11.3 to Resource<br>
> > > > > Repository should be deleted. Users do NOT
know<br>
> > > > > where a Resource Service stores things - if a
vendor<br>
> > > > > does such an extension, then that vendor has broken<br>
> > > > > good security practice in their system design
and<br>
> > > > > will justifiably fail independent security audits.<br>
> > > > ><br>
> > > > > The Resource Service is completely responsible
*on its<br>
> > > > > own* for every Resource that it stores (anywhere)
or allows<br>
> > > > > an authenticated user to retrieve (from the Resource<br>
> > > > > Service, that is).<br>
> > > > ><br>
> > > > > Any network system that hosts a Resource Service<br>
> > > > > is, by definition, an Imaging System - it may
not be<br>
> > > > > dedicated (single-purpose), but it's still an
Imaging<br>
> > > > > System.<br>
> > > > ><br>
> > > > > Another way of putting it is that "Imaging
System"<br>
> > > > > is NOT simply a synonym for "Multifunction
Device"<br>
> > > > > - it's a wider definition that includes Spoolers
and<br>
> > > > > network server-hosted Imaging Services.<br>
> > > > ><br>
> > > > > Cheers,<br>
> > > > > - Ira<br>
> > > > ><br>
> > > > > Ira McDonald (Musician / Software Architect)<br>
> > > > > Chair - Linux Foundation Open Printing WG<br>
> > > > > Blue Roof Music/High North Inc<br>
> > > > > email: blueroofmusic@gmail.com<br>
> > > > > winter:<br>
> > > > > 579 Park Place Saline, MI 48176<br>
> > > > > 734-944-0094<br>
> > > > > summer:<br>
> > > > > PO Box 221 Grand Marais, MI 49839<br>
> > > > > 906-494-2434<br>
> > > > ><br>
> > > > ><br>
> > > > > On Wed, May 13, 2009 at 12:16 PM, <nchen@okidata.com>
wrote:<br>
> > > > ><br>
> > > > > ><br>
> > > > > > Hi Ira,<br>
> > > > > ><br>
> > > > > > Thanks for the text for the Security Consideration.<br>
> > > > > ><br>
> > > > > > Here are something I need to clarify, and
some comments.<br>
> > > > > ><br>
> > > > > > 11.4 - Security Threats from Executable
Resources<br>
> > > > > ><br>
> > > > > > It's not clear to me whether the security
problem described here<br>
> is<br>
> > > for<br>
> > > > -<br>
> > > > > > 1) storing Executable Resources at an external
storage location<br>
> > that<br>
> > > > > > involves an external system for storing the
resource, and the<br>
> > > Resource<br>
> > > > > > Service is hosted by an Imaging System. Or,<br>
> > > > > > 2) storing Executable Resources internally
within the Imaging<br>
> > System<br>
> > > > that<br>
> > > > > > hosts the Resource Service.<br>
> > > > > ><br>
> > > > > > In both cases the security threat is to the
Imaging System.<br>
> > > > > ><br>
> > > > > > If it's case 1) - I agree that the external
system "SHOULD verify<br>
> > the<br>
> > > > > > safety of such resources (e.g., by virus
scanning)". But we<br>
> agreed<br>
> > in<br>
> > > > > last<br>
> > > > > > face-to-face meeting that it's out of scope
of Resource Service<br>
> to<br>
> > > > > consider<br>
> > > > > > anything related to the external storage
system. What Resource<br>
> > > Service<br>
> > > > > > should consider is the restriction of the
storage and retrieval<br>
> > > > > operations<br>
> > > > > > on such resources to authorized users. How
the external storage<br>
> > > system<br>
> > > > > > should protect the stored executable resources
is out of scope.<br>
> > > > Although<br>
> > > > > I<br>
> > > > > > prefer to recommend some security objectives
to be considered by<br>
> > the<br>
> > > > > > external storage system.<br>
> > > > > ><br>
> > > > > > If it's case 2) - I don't think we should
give "virus scanning"<br>
> as<br>
> > an<br>
> > > > > > example to an Imaging System to protect the
stored Executable<br>
> > > > Resources.<br>
> > > > > > Virus scanning or intrusion detection techniques
are common in<br>
> PCs,<br>
> > > but<br>
> > > > > > rarely existent in Imaging Systems. It's
simply not that<br>
> practical<br>
> > > for<br>
> > > > an<br>
> > > > > > Imaging System to have such software implemented
which involves<br>
> > > > constant<br>
> > > > > > maintenance of upto-date virus signatures
by external systems. At<br>
> > the<br>
> > > > > > abstract level, we can provide some good
security objectives to<br>
> > > > consider<br>
> > > > > for<br>
> > > > > > the Imaging System, such as protection of
confidentiality and<br>
> > > integrity<br>
> > > > > of<br>
> > > > > > the resources and their related metadata.
Like case 1), the<br>
> storage<br>
> > > and<br>
> > > > > > retrieval of operations on such resources
must to restricted to<br>
> > > > > authorized<br>
> > > > > > users.<br>
> > > > > ><br>
> > > > > > A Resource Service could be hosted by a computer
remote to the<br>
> > > Imaging<br>
> > > > > > System that is under security consideration.
We should consider<br>
> > this<br>
> > > > case<br>
> > > > > > too.<br>
> > > > > ><br>
> > > > > > 11.5 - Security Threats from Static Resources<br>
> > > > > ><br>
> > > > > > Static resources that have associated Intellectual
Property<br>
> rights<br>
> > or<br>
> > > > > > license rights that involves metadata such
as<br>
> DateTimeOfExpiration<br>
> > > > which<br>
> > > > > > should also be protected for alteration.
Therefore, not only<br>
> > storage<br>
> > > or<br>
> > > > > > retrieval operations on Resources must be
restricted, other<br>
> > > operations<br>
> > > > on<br>
> > > > > > resource metadata must be restricted too.<br>
> > > > > ><br>
> > > > > > Aslo the security problem you described here
is for storing<br>
> Static<br>
> > > > > > Resources internally in an Imaging System
that hosts the Resource<br>
> > > > > Service.<br>
> > > > > > We should also consider the case when the
Resource Service could<br>
> be<br>
> > > > > hosted<br>
> > > > > > by a computer remote to the Imaging System.<br>
> > > > > ><br>
> > > > > > Thanks,<br>
> > > > > > -Nancy</tt></font>
<br><font size=2><tt>> > > > > ></tt></font>
<br><font size=2><tt>> > > > > ><br>
> > > > ><br>
> > > ><br>
> > ><br>
> ><br>
> -----------------------------------------------------------------------------<br>
> > > > > > Principal Engineer<br>
> > > > > > Solutions and Technology<br>
> > > > > > Oki Data<br>
> > > > > > 2000 Bishops Gate Blvd.<br>
> > > > > > Mt. Laurel, NJ 08054<br>
> > > > > > Phone: (856) 222-7006<br>
> > > > > > Email: nchen@okidata.com<br>
> > > > > ><br>
> > > > > ><br>
> > > > > ><br>
> > > > > > *Ira McDonald <blueroofmusic@gmail.com>*<br>
> > > > > ><br>
> > > > > > 05/12/2009 03:15 PM<br>
> > > > > > To<br>
> > > > > > mfd@pwg.org, NancyChen <nchen@okidata.com>,
Ira McDonald <<br>
> > > > > > blueroofmusic@gmail.com> cc<br>
> > > > > > Subject<br>
> > > > > > Resource Service updates for Security<br>
> > > > > ><br>
> > > > > ><br>
> > > > > ><br>
> > > > > ><br>
> > > > > > Hi Nancy,
Tuesday (12<br>
> May<br>
> > > > 2009)<br>
> > > > > ><br>
> > > > > > Per my action from the Resource Service review
during the April<br>
> PWG<br>
> > > > > > meeting, below is some text for the Security
Considerations<br>
> section<br>
> > > of<br>
> > > > > > the Resource Service.<br>
> > > > > ><br>
> > > > > > 11.4 Security Threats from Executable Resources<br>
> > > > > ><br>
> > > > > > Resources with a ResourceCategory of 'Executable'
MUST be handled<br>
> > > with<br>
> > > > > > special care by implementations of the Resource
Service. Such<br>
> > > > resources<br>
> > > > > > can pose serious threats to the integrity
of the Imaging System<br>
> > that<br>
> > > > > > hosts the Resource Service. In particular,
such Resources can be<br>
> > > used<br>
> > > > > > to introduce Trojan Horses to the Imaging
System. If an<br>
> > > implementation<br>
> > > > > > of the Resource Service supports Executable
resources, then that<br>
> > > > > > implementation MUST restrict the storage
of such resources (e.g.,<br>
> > to<br>
> > > > > > authorized administrators and manufacturers)
and SHOULD verify<br>
> the<br>
> > > > > > safety of such resources (e.g., by virus
scanning).<br>
> > > > > ><br>
> > > > > > 11.5 Security Threats from Static Resources<br>
> > > > > ><br>
> > > > > > Resources with ResourceCategory of 'Static'
SHOULD be treated<br>
> with<br>
> > > > > > special care by implementations of the Resource
Service. Fonts<br>
> > that<br>
> > > > > > have associated Intellectual Property rights
(e.g., as part of<br>
> > their<br>
> > > > > > network licenses) can pose serious threats
to the availability of<br>
> > the<br>
> > > > > > Imaging System that hosts the Resource Service
- security audits<br>
> > can<br>
> > > > > > result in the shutdown or physical removal
of the Imaging System.<br>
> > If<br>
> > > > an<br>
> > > > > > implementation of the Resource Service supports
Static resources<br>
> > that<br>
> > > > > > have associated Intellectual Property rights,
then that<br>
> > > implementation<br>
> > > > > > SHOULD restrict the storage of such resources
(e.g., to<br>
> authorized<br>
> > > > > > administrators and manufacturers) and SHOULD
restrict the<br>
> retrieval<br>
> > > of<br>
> > > > > > such resources (e.g., to a configured group
of authorized users).<br>
> > > > > ><br>
> > > > > > Comments?<br>
> > > > > ><br>
> > > > > > Cheers,<br>
> > > > > > - Ira<br>
> > > > > ><br>
> > > > > > Ira McDonald (Musician / Software Architect)<br>
> > > > > > Chair - Linux Foundation Open Printing WG<br>
> > > > > > Blue Roof Music/High North Inc<br>
> > > > > > email: blueroofmusic@gmail.com<br>
> > > > > > winter:<br>
> > > > > > 579 Park Place Saline, MI 48176<br>
> > > > > > 734-944-0094<br>
> > > > > > summer:<br>
> > > > > > PO Box 221 Grand Marais, MI 49839<br>
> > > > > > 906-494-2434<br>
> > > > > ><br>
> > > > > ><br>
> > > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > ><br>
> > > ><br>
> > > ><br>
> > ><br>
> > ><br>
> > ><br>
> ><br>
> ><br>
> ><br>
><br>
><br>
></tt></font>
<br>
<br>
<br><br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.