Alan wrote on 05/01/2001 11:02:02 AM:
> You're assuming that an average CU is capable of recognising
> a bogus VTIMEZONE, which might be expecting a bit too much.
>
> Remember it's not always easy to tell spam/malicious email
> from real email- just look at how email viruses manage to
> spread.
Sure, anyone can build a CUA that is not well designed and CUs are more than welcome to use it and pay the price ("Ya get what you pay for" and "What goes around, comes around" come to mind for both CU and vendor in this case). However, Id hope that a CUA that offers autoprocessing would have some kind of smarts in it (ie: "I only want requests from my boss to be autoprocessed", "Only process signed iMIP requests from domains X, Y or Z", etc) so that this is not an issue.
After all, if I dont accept the spam then why would my CUA need or want to store the bogus defintions? The bogus definitions are only useful in the context of the iTIP/iMIP message that my CUA is processing to start with and if I toss it, I can safely toss the cruft too.
> I wouldn't even expect an average CU to be able to look
> at the source of a VTIMEZONE and decide if it's valid or not.
Whoa Hoss. The CU is not very likely at all to even see the TZ defintions. They see the decoded iTIP request and will generally toss it (unless of course they love adding spam to their calendar). If they for some reason accept the spam then Id expect the CUA to require some CU involvement before "updating" or 'overwriting" its own TZ definitions.
> If
> all CUAs accepted buggy timezones that were presented to them, those
> VTIMEZONEs could spread quickly, in a similar manner to viruses-
> imagine if my EST5EDT timezone was messed up, but only in the
> 'standard' portion; I wouldn't realise until October.
I think that Erics current proposal is NOT that the bogus defintions would be propigated but rather that each app would encode the TZ information from its own internal table of TZ definitions. That is, I may get (and for some reason) accept your spam that adds a new North_America/Los_Angeles to my system but it will have a different product and/or version info in it. As such my CUA would not be resending it out in any of my requests, it would use its own internal table w/its own product name and version on it. If the offending spam came in w/the same TZID as my own CUAs then my CUA could safely ignore it (ie: "I already know what ~Lotus/Notes/1/North_America/Los_Angeles/ is so I dont need to use the senders TZ info")
If for some reason my CUA wanted keep the spam TZ info and it was forged so that it appeared to be a 'newer' version of the TZ definition then the CUA should have some reasonable behaviour like prompt the CU that a 'newer' TZ definition is (or "may be") available and what do they want to do w/it. If it came in on some spam then I would expect the CUs to do nothing! Afterall you can only protect a CU from themselves for so long before its just 10 lines of code and 10,000 lines of safety netting. Better that the CUA make it something that takes cogntive action on the part of the CU _before_ the suspect (or real) TZ defs are added to the system!!
> It would also be kind of annoying though to be in the position
> where another vendor's bugs can mess up my TZ database-
Please reread Erics proposal. His proposal does not say that your CUA would absorb and reuse the bogus TZ info. I believe that his intent is still that your CUA would continue to use its own tables for all outbound stuff w/possibly the exception of delegations or "party crashing". Eric can confirm or deny this though. As such, the bogus data wont be mucking up your normal workflow process since it is only applied to the entry(s) that it came in on.
> It would also be kind of annoying though to be in the position
> where another vendor's bugs can mess up my TZ database-
> [Snip, snip] it wouldn't feel
> like my own CUA was very robust.
Given the format of Erics TZID, your vendor and product ID wont match the crufty CUAs vendor and product ID so a poor CUAs defintions wont be messing up your CUAs (unless your CUA is poorly designed too and reuses someone elses TZ info as their own).
Bruce
===========================================================================
Bruce Kahn INet: Bruce_Kahn <at> iris.com
Iris Associates Phone: 978.392.5335
Westford, MA, USA 01886 FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
RSS Feed