ho~x:6i -icjj6 Ministerie van Verkeer en Waterstaat. Directoraat-Generaal Rijkswaterstaat. Meetkundige Dienst. Route 400 Exchanged?

/ h o ~ x : 6 i -icjj6 Ministerie van Verkeer en Waterstaat

Directoraat-Generaal Rijkswaterstaat

^

Meetkundige Dienst

Route 400 Exchanged ? m o

a 4 c

-
ROUTE400 EXCHANGED? A d v i e s r a p p o r t

Opdrachtgever

D i r e c t i e Organisatie & Informatie drs. R.J. Kuiper Postbus 20901 2500 EX DEN H7AAG

Opdrachtnemer

RWS M e e t k u n d i g e D i e n s t Afdeling IBI A.R.J. Wayers Postbus 5023 2600 GA D e l f t

Datum

11 november

Rapportnummer :

MDIBIR964 0

14 FEB 2003

1. Inleiding

3

2. Doel van het onderzoek

3

2.1. Randvoorwaarden bij het onderzoek

3

3. Het beleid

3

4. Elektroniscltepost

bij V& W

3

4.1. Beschrijving ROUTE400

4

4.2. Beschrijving Microsoft Exchange

5

4.3. Wie gebruiken Exchange

5

5. Compatibiliteit van Exchange met het Programma van Eisen

5

5.1. Aspecten van incompatibiliteit

6

5.1.1. apparatuur 5.1.2. software

6 6 6 6 6

5.1.3. adresboeken 5.1.4. het VenWnet 5.1.5. elektronische post toepassingen

6. Investeringen

6

7. Onze visie

7

7.1. Groupware

1

7.2. Het Internet

7

7.3. De Network Computer

8

8. Advies

8

9. Hoe verder

9

ROUT400 EXCHANGED

Adviesrapport

Meetkundige Dienst IBI

11-11-1996

2

1.

Inleiding

In haar schrijven van 19 juli 1996 maakte de plaatsvervangend Secretaris-Generaal het besluit bekend de toekomstige V & W werkplekautomatisering te baseren op het kantoorpakket Microsoft Office onder het Microsoft Windows besturingssysteem. Voor wat betreft de overgang naar het pakket Exchange werd door haar een voorbehoud gemaakt gezien het feit dat meer dan vijfduizend medewerkers van het ministerie gebruik maken van het V & W voorkeursprodukt ROUTE400.

2.

Doel van het onderzoek

Doel van dit onderzoek is te adviseren of het pakket Microsoft Exchange als V&W-breed elektronische post produkt kan worden ingezet en daarmee op termijn het V & W voorkeurspakket ROUTE400 moet gaan vervangen. 2.1.

Randvoorwaarden

bij het onderzoek

1

De randvoorwaarden bij de invoering van het in april 1996 in Nederland gei'ntroduceerde Microsoft Exchange zijn; • het vlekkeloos kunnen cornmuniceren met elektronische post pakketten die gebaseerd zijn op de twee Internationale standaarden van elektronische post: X.400 (Europese overheidsstandaard) en S M T P / M I M E (Internetstandaard). • Communicatie met ROUTE400 moet gewaarborgd zijn. • Een V&W-breed afgestemde aanpak. • Communicatie met partijen buiten het ministerie moet gewaarborgd blijven.

3.

Het beleid 2

Reeds in juni 1992 stelde de Bestuursraad het V & W elektronische post beleid vast. Kernpunten uit dit beleid zijn; • Het gebruik van de X.400 functionaliteit tot op de werkplek (VOSIP ) • Opzet van een gemeenschappelijk X.400 backbone-infrastructuur (VenWnet) • Gebruik van het voorkeursprodukt ROUTE400 3

4.

Elektronische post bij V&W

De V & W elektronische post functie is opgebouwd uit een aantal standaard functies welke door iedereen te gebruiken zijn. Zo zijn alle organisatieonderdelen van het ministerie aan gesloten op het VenWnet zodat elektronische berichten met elkaar kunnen worden uitgewisseld. Telewerkers, thuiswerkers en mobielewerkers kunnen beschikken over dezelfde faciliteiten. B i j het ontwerp van de elektronische post infrastructuur werd er uit efficientie overwegingen voor gekozen alle gemeenschappelijke nineties onder te brengen in het VenWnet en het gebruik ervan centraal te betalen. Een tweede belangrijk ontwerpcriterium was de eis dat V&Wers alle vormen (in/extern) van elektronische post m.b.v. dezelfde faciliteit konden afwikkelen. Met de ontwikkelde elektronische post faciliteiten zijn alle nederlandse partners van V & W elektronisch bereikbaar geworden zoals; de ministeries, de Eerste- en Tweedekamer, de lokale overheden, de universitaire onderzoekswereld, het bedrijfsleven en de burgers. Moeiteloos ROUT400 EXCHANGED

Adviesrapport


11-11-1996

3

kunnen berichten worden uitgewisseld met de EU-organisaties in Brussel, de standaardisatieen onderzoeksorganen zoals de ETSI en wereldwijd alle relevante internationale organisaties zoals de V N , ITU en bedrijven en instellingen. Partijen die nog niet beschikken over een elektronische post functie worden bereikt m.b.v. de gemeenschappelijke elektronische post FAX faciliteit. Ook met gebruikers van G S M draagbare telefoontoestellen kunnen berichten worden uitgewisseld. Een reeks van gemeenschappelijk ontwikkelde hulpmiddelen als handboeken, elektronische add-on's en elektronische adresboeken vereenvoudigen het gebruik van de elektronische postfunctie aanmerkelijk. Vandaag de dag zijn ruim 6000 elektronische postbussen in gebruik. De verspreiding en het gebruik van elektronische post binnen het ministerie neemt toe.

4.1.

Beschrijving

ROUTE400

ROUTE400 is een produkt van het engelse softwarehuis Nettel en wordt in Nederland op de markt gebracht door D A T A D . Het pakket voldoet aan het V & W Programma van Eisen voor Elektronische Post. Hierdoor werkt het goed samen met pakketten zoals Word e.a.. ROUTE400 is het voorkeursprodukt voor elektronische post van het ministerie. Het biedt de volgende faciliteiten; • het elektronische postkantoor voor de elektronische distributie • het pakket op de PC waarmee berichten kunnen worden aangemaakt, verzonden, ontvangen, gelezen en gearchiveerd. 4

ROUTE400 biedt de gebruiker de volgende basisfuncties; • Aanmaken, lezen en archiveren van elektronische postberichten • Aanmaken en archiveren van elektonische FAX-berichten • Folders voor de opslag en distributie van berichten • Adresboek • Conversie naar en van Internetmail en andere (wereldwijde) mailsystemen De ROUTE400 produkten waarvoor het ministerie in 1993 koos stelden geen bijzondere eisen aan de apparatuur. De aanwezige apparatuurlijnen konden worden gebruikt. Met de nederlandse leverancier van het pakket werd een gunstige inkoopovereenkomst afgesloten . Voor de ondersteuning van de beheerders sloot de Meetkundige Dienst namens het ministerie een V&W-breed tweedelijnsupportcontract af. Binnen V & W wordt ROUTE400 massaal gebruikt. Uitzondering hierop vormen (onderdelen van) D G V , R V I , RWS-HW, R L D , H D T P en de Centrale Diensten. Als gevolg hiervan zijn deze organisatie-onderdelen voor de overige onderdelen van het ministerie en voor de buitenwereld niet of slecht bereikbaar. ROUTE400 wordt naast het gebruik voor informed berichtenverkeer in toenemende mate gei'ntegreerd binnen V&W-toepassingen die behoefte hebben aan een robuuste mailfunctie. Binnen de Europese Commissie wordt veel gebruik gemaakt van het pakket.

ROUT400 EXCHANGED

Adviesrapport


11-11-1996

4.2.

Beschrijving Microsoft

Exchange

Het pakket Exchange is een nieuw produkt van Microsoft en werd medio dit jaar in Nederland gelanceerd. Het produkt vervangt een aantal verouderde Microsoft produkten zoals MS-Mail. Exchange bestaat uit vier componenten; • het elektronisch postkantoor • de noodzakelijke additionele programmatuur t.b.v. het elektronisch postkantoor • het pakket op de Personal Computer • de noodzakelijk additionele programma's op de Personal Computer t.b.v. het pakket Exchange Exchange biedt de gebruiker een aantal basis functies; • elektronische post • folders t.b.v. opslag van berichten en de distributie van informatie • adresboek • Mogelijkheden tot berichtbeveiliging • conversiemogelijkheid van en naar andere elektronische post standaarden Exchange werkt alleen in combinatie met Microsoftprodukten op een beperkt aantal computersoorten. Het produkt biedt elektronische postfuncties met een aantal extra's zoals de mogelijkheid tot de versleuteling van berichten. Deze extrafuncties werken alleen maar, en dan nog onder bepaalde voorwaarden, in combinatie met Microsoft produkten. Voor de uitwisseling van berichten met bestemmingen welke geen gebruik maken van Microsoft produkten werken deze extra's niet.

4.3.

Wie gebruiken

Exchange

Exchange is een nieuw produkt. Het gebruik ervan is nog beperkt. Uit onderzoek van een aantal Microsoft cases blijkt dat het produkt met name in gebruik wordt genomen door bedrijven die al op grote schaal Microsoft elektronische post software gebruiken. De reden waarom deze becirijven kiezen voor Exchange is niet primaire de geboden functionaliteit maar omdat Exchange het enige alternatief is. Een weinig benijdenswaardige positie. V & W bevindt zich niet in deze positie als gevolg van de keuze, in 1993 van de top van ons ministerie, om de europese IT standaards voor elektronische post te volgen.

5.

Compatibiliteit van Exchange met het Programma van Eisen 6

Wij onderzochten de mate waarin het produkt Exchange voldoet aan het V & W Programma van Eisen voor elektronische post. Wij legden Microsoft het Programma van Eisen voor. Op basis van de analyse van het antwoord van Microsoft komen wij tot de conclusie dat het produkt Exchange server niet voldoet aan de eisen welke het ministerie stelt aan de elektronische postfunctie. Uit een aanvullende praktijktest blijkt dat het produkt ook enkele hinderlijke bugs bevat. Onze conclusie is dat het produkt zich leent voor informeel berichtenverkeer in een standaard Microsoftproduktomgeving. In een gemengde produktomgeving zoals binnen het ministerie leidt het gebruik van Exchange tot verwarring bij de gebruikers vanwege het afwijkend gedrag van Exchange. Voor formeel berichtenverkeer t.b.v. bedrijfsmatige en -kritische toepassingen zoals workgroup en -flow voldoet het produkt door zijn eigenschappen in het geheel niet. ROUT400 EXCHANGED

Adviesrapport


11-11-1996

5.1.

Aspecten van 5.1.1.

incompatibiliteit

apparatuur

Negentig procent van het ministerie gebruikt apparatuurlijnen waarop de betreffende Exchange produkten niet kunn .n functioneren. Dit geldt zowel voor de server als voor de PC apparatuur. Vervanging van deze apparatuur is daarom noodzakelijk.

5.1.2. software Exchange eist het gebruik van een aantal andere Microsoft produkten (Windows95 als PCclient en Windows/NT als server). Het kan daarom alleen maar functioneren wanneer de automatisermgsinfrastructuur is ingericht met deze Microsoftprodukten. Dit is nu niet het geval. De betreffende programma's zullen moeten worden aangeschaft.

5.1.3.

adresboeken

De Exchange adresboeken zijn niet compatibel met de ROUTE400 adresboeken. Additionele programmatuur zal moeten worden ontwikkeld om Exchange adresboeken voor alle gebruikers toegangkelijk te maken.

5.1.4. het VenWnet VenWnet biedt een reeks van gemeenschappelijke faciliteiten t.b.v. elektronische post. Deze zullen moeten worden aangepast of worden vervangen door andere faciliteiten.

5.1.5. elektronische post toepassingen Verschillende toepassingen binnen het ministerie maken gebruik van de elektronische post functie voor het transport van gegevens. Omdat Exchange afwijkt van de V & W elektronische post standaard zullen deze toepassingen mogelijk moeten worden aangepast. Nader onderzoek naar noodzaak en de omvang van deze softwareaanpassingen is noodzakelijk.

6.

Investeringen

Overgaan op Exchange vereist een reeks van investeringen. Wij hebben deze globaal begroot. Hierbij zijn wij uitgegaan van de vervanging van 60 (ROUTE400, N O V E L L , e.a.) postkantoren en van 6000 werkplekken. We onderscheiden hierbij de volgende investeringscomponenten; • Exchange serversoftware • noodzakelijke additionele Microsoft serverprogrammatuur • serverapparatuur • clientprogrammatuur • noodzakelijke additionele Microsoft clientprogrammatuur • clientapparatuur Er is geen rekening gehouden met de kosten voor de noodzakelijke veranderingen in het VenWnet. Door centrale inkoop kan enige korting worden bedongen. Ook deze korting ROUT400 EXCHANGED

Adviesrapport


11-11-1996

6

hebben wij niet meegenomen in deze berekening. In het kader van de voorbereiding op het gebruik van het pakket MS-Office vinden al investeringen in PC apparatuur plaats. Hiermee is hier geen rekening gehouden. Tenslotte is er ook geen rekening is gehouden met de noodzakelijk (om)scholingskosten van ROUTE400 naar Exchange voor de gebruikers en de beheerders. Op basis van de bovenstaande aanname schatten wij dat het te investeren bedrag voor de aankoop van hardware- en computersoftware zich zal bevinden omstreeks de 30 miljoen gulden.

7.

Onze visie

Microsoft lanceert in toenemend tempo nieuwe produkten. Dit is het gevolg van de strijd welke Microsoft op twee fronten voert. Enerzijds stelt men alles in het werk om grip te krijgen op het "Internet" waardoor Microsoft zich liet verrassen. Anderzijds poogt Microsoft voet aan de grond te krijgen op de lucratieve groupware markt.

7.1.

Groupware

Hierbij positioneert Microsoft zijn Exchange server als een alternatief voor Lotus/Notes, de marktleider. Exchange biedt echter maar beperkte groupware functionaliteit . In juni van dit jaar kondigde Microsoft al aan de Exchange PCsoftware te zullen gaan vervangen door het produkt Outlook 97. Outlook 97 is een nieuw pakket met meer groupware functies. De Exchange-gebruikers van het eerste uur zullen met de overgang naar Outlook 97 opnieuw moeten worden opgeleid. 8

Groupware bevat een reeks van werkgroep ondersteunende IT hulpmiddelen waarvan elektronische post en elektronische agenda de meest bekende zijn. Alleen de elektronische postfunctie is gestandaardiseerd. De overige workgroup functies zoals de agendafunctie zijn leverancierspecifiek en kunnen niet worden gebruikt in combinatie met produkten van andere leveranciers. M.a.w. organisatie-onderdelen die workgrouppakketten gebruiken van verschillende leveranciers zoals Notes van I B M , GrouprWise van N O V E L L en Exchange van Microsoft kunnen deze functies niet gebruiken in gemeenschappelijke samenwerkingsverbanden. Wij verwachten dat deze situatie de komende jaren niet fundamenteel zal veranderen. Ontwikkelingen vanuit het Internetdomein kunnen hier echter voor een doorbraak zorgen. Dit wordt onderzocht in het CCIprogramma.

7.2.

Het Internet

Het Internet werd aanvankelijk door Microsoft genegeerd. Pas in het voorjaar van 1996 besloot het bedrijf tot een drastische koerswijziging. In de Internetvisie van Microsoft moet de toegang tot het Internet lopen via de produkten van het bedrijf. Microsoft als eigenaar van het Internet. In het CCI-project onderzoeken wij de gevolgen van deze ontwikkelingen. Wij zijn van mening dat deze strategic niet zal slagen. Microsoft beheerst nu nog de PC (zie hieronder). De regels op het Internet zullen niet door Microsoft worden bepaald maar wereldwijd door een groot aantal bedrijven.

ROUT400 EXCHANGED

Adviesrapport


11-11-1996

7

7.3.

De Network

Computer

Een nieuwe ontwikkeling is de Network Computer. Een aantal zeer grote marktpartijen uit de wereld van de consumenten-elektronica hebben zich achter dit initiatief van Oracle geschaard. Het doel van dit samenwerkingsverband is de dominante positie van Microsoft in de PC markt te doorbreken en het Internet te ontsluiten voor miljarden nieuwe consumenten. Men wil dit bereiken door een alternatief te ontwikkelen voor de PC, de achilleshiel van Microsoft. De Network Computer. 9

De verwachting is dat door het eenvoudige concept dat ligt achter de Network Computer zowel de aanschaf- als exploitatiekosten aanzienlijk lager zullen uitkomen. Dit wordt mede mogelijk gemaakt door het toepassen van nieuwe onderliggende softwareconcepten. De komst van de Network Computer zal er toe leiden dat voor de eerste keer de consumentenprodukten-, netwerken de computerindustrie zullen gaan samenwerken bij de ontwikkeling en de marketing van de consumentencomputers. Onderzoek wijst uit dat met name de overheid en het bedrijfsleven als eerste de PC zullen gaan vervangen door de Netwo-k Computer om te kunnen komen tot het beheersen van de kosten welke verbonden zijn met het gebruik van de PC. Microsoft scoort nu 90 procent van zijn omzet in de PCmarkt. Met de op handen zijnde vermindering van de rol van de PC zal op termijn een groot deel van deze omzet wegvallen. 10

Investeringen van strategische aard in (Microsoft) software maar ook in nieuwe computertoepassingen op basis van de Microsofttechnologie moeten naar onze mening met de nodige behoedzaamheid worden gedaan rekening houdend met de hierboven geschetste paradigmaverschuiving. De opkomst van het Internet toont aan dat de ingeslagen weg van Open (Internet) standaarden voldoende alternatieven biedt.

8.

Advies

Hier komen wij terug op de vraagstelling van dit onderzoek of Exchange server het produkt ROUTE400 kan vervangen. Op basis van het voorafgaande zijn wij van mening dat; • Het produkt Exchange niet voldoet aan het V & W Programma van Eisen voor elektronische post. • Het gebruik van Exchange in een gemengde automatiseringsinfrastructuuromgeving zoals binnen ons ministerie, geen voordelen biedt t.o.v. het produkt ROUTE400 maar eerder zal leiden meer complexiteit, hogere kosten, verlies van flexibiliteit en verwarring bij de gebruikers. • Exchange geen geschikt platform is voor V&Wbrede groupware functies zoals agenda en planner e.a.. • De investeringen die zijn verbonden aan Exchange in geen verhouding staan tot de meerwaarde die het gebruik van het produkt oplevert. • Door de Internetvisie van Microsoft de Microsoftprodukten, dus ook Exchange, de komende jaren zeer aan verandering onderhevig zullen zijn. • De positie van Microsoft als dominante PC software leverancier zal veranderen door de komst van het Internet en de Network Computer. • Investeringen van strategische aard in Microsoftsoftware naar onze mening met de nodige behoedzaamheid moeten worden gedaan.

ROUT400 EXCHANGED

Adviesrapport


11-11-1996

• De ontwikkelingen in het Internetdomein zullen leiden tot een fundamentele verandering in het gebruik en de ontwikkeling van informatietechnologie en systemen. • Het huidige beleid werkt. Op basis van het voorafgaande adviseren wij de komende 2 jaar niet te kiezen voor het gebruik van het produkt Exchange server maar het huidige beleid, ROUTE400, te continueren. Wij verwachten dat door de snelheid waarmee de ontwikkelingen in het Internetdomein plaatsvinden het op dat moment noodzakelijk zal worden het V & W elektronische postbeleid nogmaals te evalueren.

9.

Hoe verder

/ & W koos voor het gebruik van MS-Ofiice als standaard elektronische werkplek. Dit is een impliciete keuze voor de herinrichting van vele duizenden elektronische werkplekken. Dit is geen sinecure. Wij adviseren daarom de komende 2 jaar alle inspanning te richten op een geordende snelle overgang naar deze pakketten. Gezien de risico's adviseren wij t.b.v. de invoering van de standaardelektronische werkplek een projectorganisatie in te richten met V & W brede verantwoordelijkheden welke rechtstreeks rapporteert aan de top van het ministerie. Met het oog op de aanbesteding van het VenWnet, waar deze vorm van dienstverlening onder de noemer end-to-end zal worden ingekocht, is het aan te bevelen om de Meetkundige Dienst deel te laten nemen in deze projectorganisatie.

1

2

3

4

5

6

7

8

9

DOI/96/5609 DOI/92/13851 MD/CCI001 MD/CCI001 V&W/DATAD EDS/MSXCH01 MD/CCI001 Datamation N R C Handelsblad Datamonitor

Vemieuwing werkplekautomatisering Aanschrijving E-mailbeleid, bijlage bij Aanschrijving E-mailbeleid V & W OSI en I N T E R N E T Profiel V E P V & W Elektronische Post Profiel Raamovereenkomst Meetkundige Dienst V & W - D A T A D Evalueren MS-Exchange binnen de V & W E-mailinfrastructuur V E P V & W Elektronische Post Profiel Groupware: Is it Notes or Nothing Softwaregiganten strijden om de toekomstige PC

1 0

ROUT400 EXCHANGED

Adviesrapport


11-11-1996

EDS

MSXCH01 Evalueren MS-Exchange binnen de VenW Email infrastructuur

Rapport Project MSXCH01

EDS

Status definitief

Registratienummer A2530#06-R-l

Samengesteld door J. Wagemakers, F. Zwaga, Tj. Zwanenburg In opdracht van Meetkundige Dienst

Datum 4oktober 1996

EDS Loire 206 Postbus 406 2260 AK Leidschendam Nederland Telefoon 31(0)70-301 42 00 Fax 31(0)70-320 28 82

Versie 1.0

Evalueren MS-Exchange binnen de VenW Email infrastructuur

Vrijgegeven door Functie

c

EDS, Versie 1.0

Naam

Paraaf

Datum

Pagina 1 van 228

Rapport

EDS

Project MSXCH01 Status definitief


INHOUD 1 Referenties 2 Inleiding 3 Exchange en Microsoft Office 3.1 Algemeen 3.2 Exchange server architectuur 3.3 Organiseren en beheren informatie met folders en forms 3.3.1 Folders 3.3.2 Forms (formulieren) 3.4 Exchange client (behorend bij Exchange Server) 3.5 Schedule + 3.6 Overige componenten Microsoft Office 3.7 Opzet Exchange infrastructuur 3.7.1 Exchange infrastructuur 3.7.2 Domeinen en sites 3.7.3 Directory synchronisatie 3.7.4 Beveiliging 3.7.5 Monitoring 4 Huidige Verkeer en Waterstaat Email infrastructuur 4.1 Functional iteit 4.1.1 Email backbone 4.1.2 Faxen 4.1.3 Remote raadplegen van post 4.2 Naamgeving en adressering 4.2.1 Directory synchronisatie via adresboek uitwisseling 4.2.2 X.500 4.3 Route400 5 Exchange binnen Verkeer en Waterstaat 5.1 Infrastructurele aspecten 5.2 X.500 5.3 Adresboek synchronisatie met Route400 5.4 Instellingen Exchange X.400 connector 5.5 Verschil in functionaliteit voor gebruiker 5.6 Uitwisseling van bijlagen 5.7 Migratie / invoering aspecten 6 Microsoft Office faciliteiten binnen de huidige infrastructuur 7 Exchange en het VOSIP 8 Testen van Exchange 8.1 Uitgevoerde testen 8.2 Testresultaten 9 Conclusies en Aanbevelingen Bijlage A Functionaliteit overzicht client Bijlage B Testplan Bijlage C Gebruikte testomgeving Bijlage D Samenvatting testresultaten Bijlage E Functies Mail client Bijlage F X.400 testset resultaten

0

EDS. Versie 1.0

3 4 5 5 7 8 9 10 10 12 13 13 13 14 18 19 20 21 21 22 22 22 22 22 23 23 24 24 ........."25 26 26 27 29 30 32 33 37 37 37 44 46 49 61 62 74 75

Pagina 2 van 228

Rapport Project MSXCH01 Status definitief


1 Referenties Dit rapport is het resultaat van de opdracht MD-530 van de Meetkundige Dienst, bij EDS geregistreerd als project MSXCH01 (A2530#06).

° EDS, Versie 1.0

Pagina 3 van 228



2 Inleiding Binnen het ministerie van VenW wordt momenteel op een aantal plaatsen Microsoft Mail gebruikt. Microsoft heeft recentelijk een vervangend produkt hiervoor uitgebracht genaamd Microsoft Exchange. Dit rapport is de weerslag van het onderzoek dat naar de produktie versie van Exchange is gedaan. Het onderzoek moest antwoord geven op de vraag wat de gevolgen zijn van de introductie van Exchange voor de VenW (Email) infrastructuur in ruimste zin. Dit is de technische variant van het rapport, er is een management versie van dit zelfde rapport beschikbaar onder nummer A2530#06-R-2. Dat rapport heeft dezelfde opbouw en hoofdstuk indeling, maar bevat niet de technische details uit dit rapport In het project MSXCH01 is een evaluatie uitgevoerd van de produktie versie 1.0 van Microsoft Exchange voor gebruik binnen de VenW (Email) infrastructuur. Bij deze evaluatie is aandacht besteed aan het voldoen aan het VOSIP en aan de operationele consequenties en de migratie aspecten bij invoering (zoals: wat merkt de ROUTE400, Openmail, Wpmail (Groupwise) gebruiker van door Exchange aangeboden mail. Welke maatregelen moeten we nemen om deze pijn te verzachten. B.v. aanpassen naamgeving, beperken bodypart types, adresboek synchronisatie etc.). Invloed op gebruikte platformen. Daar Exchange de kern is van het Microsoft Office concept met diverse additionele faciliteiten zoals agenda's, komt ook deze functionaliteit aan bod. Met name of het mogelijk is deze faciliteiten te gebruiken over de bestaande Email faciliteiten gebaseerd op Route400. Belangrijk hierbij is dat Exchange voor een aantal componenten van Office vervangers heeft met dezelfde naam, maar toch enigszins andere eigenschappen. Tenslotte is Exchange onlosmakelijk verbonden aan Windows NT. Invoering van Exchange betekend dus invoering van Windows NT. Tevens is de relatie tussen Exchange en Windows NT zeer innig. Dit betekend dat invoering van Windows NT zonder rekening te houden met de invoering van Exchange, tot problemen leidt bij het naderhand alsnog invoeren van Exchange. De mogelijkheden van Exchange en Microsoft Office worden in hoofdstuk 3 beschreven. In dat hoofdstuk wordt tevens de wijze beschreven waarop een op Exchange gebaseerde infrastructuur wordt ingericht. Om de consequenties te beoordelen van het gebruik van Exchange wordt in hoofdstuk 4 een beschrijving gegeven van de huidige Verkeer en Waterstaat Email infrastructuur. In hoofdstuk 5 wordt de relatie gelegd tussen de algemene concepten uit hoofdstuk 3 en de organisatie van Verkeer en Waterstaat. Hierbij wordt al vast vooruit gelopen op de ingevulde VOSIP resultaten uit hoofdstuk 7, en de testresultaten uit hoofdstuk 8. In hoofdstuk 6 wordt aangegeven welke functionaliteit over blijft van de Microsoft Office omgeving indien deze gebruikt wordt binnen de huidige infrastructuur. Tenslotte staan in hoofdstuk 9 de conclusies en aanbevelingen, en zijn een aantal bijlagen opgenomen met technische details.

c

EDS. versie l.o

Pagina 4 van 228

Rapport

EDS



3 Exchange en Microsoft Office Dit hoofdstuk beschrijft de functionaliteit van Exchange en Microsoft Office en de eisen die gesteld worden bij het opzetten van een op Exchange gebaseerde (Email) infrastructuur.

3.1 Algemeen Microsoft Exchange is een ondersteunend middel om binnen een organisatie informatie te delen. Hierdoor kunnen gebruikers de juiste informatie op het juiste tijdstip delen met andere gebruikers binnen en buiten de organisatie. Microsoft Exchange integreert hiertoe mail, planning, informatie uitwisseling, business toepassingen en administratie. Uitgangspunt hierbij was dat Exchange moest aansluiten op de gangbare standaards zoals X.400, X.500 en Internet. Exchange bestaat uit de componenten (zie ook Figuur 1): • Een gei'ntegreerde posten informatie uitwisseling server die werkt op het Windows NT operating systeem; • Eindgebruikers Email clients voor Windows, Windows'95, Windows NT, MSDOS, Macintosh en UNIX (aangekondigd) platformen. • Eindgebruikers agenda clients voor Windows, Windows'95, Windows NT, MSDOS, Macintosh en UNIX (aangekondigd) platformen.

Exchanges**

Figuur 1 Overzicht Exchange componenten Microsoft Exchange groepeert servers binnen een lokale geografische eenheid in een site. Servers binnen een site maken gebruik van dezelfde directory en communiceren automatisch met elkaar. Zodra een organisatie verspreid is over meerdere geografische locaties wordt deze onderverdeeld in sites. Sites kunnen onderling worden gekoppeld, zodat informatie uitwisseling binnen de gehele organisatie mogelijk is.

c

EDS, Versie 1.0

Pagina 5 van 228



Microsoft Office vult Exchange aan met personal productivity tools zoals agenda's tekstverwerking en spreadsheets. A l deze produkten zijn Mail aware en kunnen samenwerken met Exchange. Belangrijk hierbij is dat sommige produkten in verschillende varianten aanwezig zijn. Windows'95 bevat, onder de naam "Exchange", Email User Agent (UA) software waarmee werkgroepen onder Windows'95 Email kunnen uitwisselen. Hierbij wordt gebruik gemaakt van het in Windows95 aanwezige workgroup postkantoor of de MSMail structuur voor postkantoren. De naam Exchange is in zoverre misleidend dat dit niet betekent dat er met een Exchange server wordt gecommuniceerd. Microsoft heeft de naamgeving intussen ook gewijzigd in Windows Messaging (beschikbaar als gratis upgrade). De Exchange / Windows Messaging Ua kan communiceren met alle mail systemen die over een (32-bits) Mail Application Programming (MAPI) 1.0 service provider beschikken. Bij Windows'95 is dit standaard MS-Mail en Internet mail connectivity. Voor de communicatie met een Exchange server is software nodig die bij de Exchange server wordt mee geleverd. Wordt deze bij Exchange Server meegeleverde DLL gei'nstalleerd, dan wordt de functionaliteit vanzelf uitgebreid naar de mogelijkheden van Exchange Server, zoals Folders en Forms. Office'95 bevat een agenda en planner systeem (Schedule+) waarmee het mogelijk is groepsplanningen te maken en agenda gegevens uit te wisselen. Hiervoor is de aanwezigheid van een mail systeem gebaseerd op MAPI 1.0 noodzakelijk. Dit kan dus het bij Windows'95 aanwezige op MS-Mail gebaseerde mailsysteem zijn, maar ook Exchange server. Bij Exchange wordt ook een Schedule+ geleverd, echter deze beschikt over een betere functionaliteit dan die van Office'95, zoals instelbare views en remote access. Daarnaast gebruikt de bij Exchange horende versie van Schedule+ de hidden folders functionaliteit van Exchange server, en is daardoor niet bruikbaar op andere mailsystemen. Belangrijk hierbij is dat de reeds aanwezige clients pas kunnen communiceren met Exchange server als de bij de server behorende MAPI Service provider DLL wordt gei'nstalleerd. Bovenstaande wordt in de volgende paragrafen verder uitgewerkt. Tot slot nog een opmerking. In dit rapport is sprake van een aantal programma's om met Exchange server te communiceren. Er zijn echter al weer aankondigingen gedaan door Microsoft voor weer een nieuwe Desktop en Office omgeving. Een herziene versie van de Office suite onder Windows95 komt in 1997 uit onder de naam Office97. Daarnaast worden de Desktop faciliteiten voor Internet en file beheer (Windows verkenner / explorer) samengevoegd tot een information manager genaamd Outlook. Outlook en Office97 vormen samen een geheel, waar ook Email onderdeel van uit maakt.

c

EDS. Versie 1.0

Pagina 6 van 228

Rapport

EDS



3.2 Exchange server architectuur De Exchange server bestaat uit een aantal componenten (zie Figuur 2), die met behulp van processen onder Windows NT lopen. Centrale component binnen Exchange is de information store waarbinnen zich de mailboxen van de gebruikers en andere informatiebronnen bevinden. Raadplegen van deze information store gebeurt met behulp van de client programma's en de API's. Koppeling met 'vreemde' mailsystemen gaat over z.g. connectoren. Connectoren bieden een zelfde functionaliteit als gateways. Microsoft Exchange Server Componenten

Optionele componenten

Key management

Directory synchronisatie

Microsoft mail connector

Internet mail connector

Andere connectoren of gateways

Schedule* Free/Busy connector

Figuur 2 Algemene architectuur Exchange server De Directory bevat alle gegevens over de gebruikers, public folders, servers, distributie lijsten en meer. De directory wordt gebruikt door andere Exchange onderdelen voor de vertaling van adressen en het routeren van berichten. Er vindt automatische replicatie plaats van de directory naar andere servers binnen een site (zie ook 3.7.2). Er is een koppeling tussen de directory van Exchange en de Windows NT gebruikers database. De directory is meer dan een Email adresboek. Het bevat niet alleen Email adressen maar diverse "adresserings" gegevens van de objecten in de Information store. In toekomstige versies van Windows NT zal de directory services naar die van Exchange migreren. De Information store bevat mailboxen van de gebruiker en publieke en prive mappen. Hier worden alle gegevens die door de betreffende server worden beheerd opgeslagen. Zoals aangegeven kunnen dit Email berichten zijn, maar ook meer algemene informatie zoals agenda gegevens en zelf te definieren objecten. De structuur is een beetje vergelijkbaar met die van een filesysteem met directories en files. De mogelijkheid voor automatische acties (zie 3.3) is het belangrijkste verschil met een gewoonfilesysteem.De objecten in de Information store kunnen publiek toegankelijk zijn, maar ook verborgen. Toegang wordt uiteraard beveiligd door het NT beveiligingsmechanisme met ACL's etcetera. De Message Transfer Agent (MTA) routeert berichten naar andere MTA's of Gateways in andere omgevingen. De MTA verzorgt ook de vertaling van adressen en formaten van berichten. Het interne formaat dat Exchange hanteert voor Email is geba-

C

EDS, Versie 1.0

Pagina 7 van 228



seerd op X.400, maar maakt gebruik van een eigen propriarty content type. Tussen Exchange MTA's wordt de informatie verzonden via dit eigen formaat. Voor verbindingen naar niet Exchange omgevingen zijn Connector's nodig. Deze verzorgen samen met de MTA de conversie naar het betreffende exteme formaat / protocol. De System Attendant ondersteunt het verloop van de processen die voor Exchange nodig zijn om te functioneren.

De optionele onderdelen die deel uitmaken van Exchange zijn: De Directory synchronisatie is bestemd voor de uitwisseling van directory informatie tussen Microsoft Mail 3.x en andere mail systemen, waarbij gebruik gemaakt wordt van het Mail 3.x directory synchronisatie protocol. Dit betekent dat directory synchronisatie met die vreemde mail systemen mogelijk is, die het Mail 3.x directory protocol ondersteunen. Het onderdeel Key Management is verantwoordelijk voor het digitaal voorzien van een beveiliging en verzegeling van boodschappen binnen Exchange. Een connector (gateway) maakt het mogelijk om Exchange berichten te laten uitwisselen met andere Email systemen of andere Exchange site's (zie ook 3.7.2). Exchange heeft connectoren voor: • site connector, voor het koppelen van meerdere Exchange site's over een snelle netwerk verbinding middels Remote Procedure Call's; • een dynamic RAS connector, voor het koppelen van remote clients en Exchange site's. Over deze connector wordt een inbellende remote client dezelfde functionaliteit geboden als een locale, via het L A N gekoppelde, client. Ook remote Exchange site's kunnen via deze connector informatie uitwisselen. • MS Mail, voor de uitwisseling van post met MS Mail postkantoren; • Schedule+ Free/Busy voor de uitwisseling van free/busy agenda informatie volgens het 3.x Schedule formaat middels Microsoft Mail; • Internet Mail, voor uitwisseling van bericht verkeer met het internet volgens het SMTP - MIME formaat; • X.400, voor het uitwisselen van Email met X.400 systemen volgens de 1984 / 1988 X.400 standaarden. Afhankelijk van de aanwezige hardware kan gepraat worden met andere X.400 systemen over diverse transport protocollen. Mogelijke protocollen hierbij zijn : • TP0/X.25 • TP4/(CLNP) • TPO/RFC 1006 to TCP/IP

3.3 Organiseren en beheren informatie met folders en forms Folders in Exchange zijn de basis voor het organiseren van informatie. Forms zijn een hulpmiddel om deze te structureren.

c

EDS, Versie 1.0

Pagina 8 van 228



3.3.1 Folders De inhoud van een willekeurige folder kan bestaan uit Email berichten, simpele tekstfiles, faxen, documenten en formulieren (forms). Zo kan bijvoorbeeld per project een folder aangemaakt worden, zodat alle informatie bij elkaar staat. Het is mogelijk om elk type informatie in een folder te plaatsen ongeacht waar deze gemaakt is. Er zijn 3 type folders: • postbus folders • persoonlijke folders • publieke folders. Persoonlijke en postbus folders zijn voor eigen gebruik, publieke folders voor algemeen gebruik. Toegang tot een publieke folder kan beperkt worden tot een aantal individuele personen, een team of een hele organisatie. Binnen de folders heeft de gebruiker de beschikking over: • Finder: Items zoeken die aan bepaalde condities voldoen • Views: De inhoud van een folder op verschillende manieren weergeven door kolommen met informatie te selecteren en deze te groeperen, sorteren of filteren. Zo'n view kan bewaard worden en toegepast worden op andere folders. • AutoAssistants: Het behandelen van inkomende mail met de Inbox Assistant en de Out of Office Assistant. Gebruik makend van deze Assistants kan aan de hand van bepaalde regels (rules) de ingekomen mail geanalyseerd worden, waarna er dan een bepaalde actie(s) volgt zoals het verplaatsen van het bericht naar een andere folder, beantwoorden van het bericht, verwijderen van het bericht en doorsturen van het bericht naar een andere gebruiker. Ook is het mogelijk een applicatie (zoals Excel) te activeren voor het verwerken van het bericht / bestand. • Delegate Access: Het delegeren van werk aan andere gebruikers door deze gebruiker rechten te geven op de eigen postbus of rechten te geven om berichten 'onder autorisatie van' te versturen of beide. De gebruiker kan deze functies van uit de Exchange client gebruiken. Naast de reeds genoemde faciliteiten kan de toegang tot de diverse Folders zeer flexibel ingedeeld worden. Zo kunnen verschillende delen van een organisatie verschillende views op de informatie krijgen. Zo ziet FAZ een ander deel van de beschikbare Folders dan inkoop. (zie Figuur 3)

Figuur 3 Verschillende views op de Folders

° EDS, Versie 1.0

Pagina 9 van 228



De Publieke Folders kunnen gerepliceerd worden naar elke Exchange server met Publieke folders binnen en/of buiten de site. Wijzigingen in deze folders kunnen op elk replicaat worden aangebracht. Exchange houdt hierbij zelf bij welke versie de juiste is. Bij de replicatie wordt geen volledige transactie verwerking uitgevoerd zoals een DBMS dat doet. De replicatie kan dan ook wel eens misgaan. In dat geval moet de gebruiker helpen het conflict op te lossen. Stel er is een bestand of Form in een Folder dat gedupliceerd op een tweetal servers aanwezig is. Op beide servers wordt er een wijziging aangebracht in het bestand. Op het moment dat de servers proberen de bestanden te dupliceren wordt er aan de hand van globaal (over alle servers heen) unieke identificatie/volgnummers geconstateerd dat er een conflict is. In het geval van bestanden wordt het dupliceren niet voltooid, maar wordt er een conflict boodschap in de Folder geplaatst, met het conflicterende bestand als bijlage. De gebruikers worden hiervan op de hoogte gesteld. Deze dienen dan het conflict op te lossen. Op het moment dat dit gebeurt is, wordt middels een "resolve all" commando de zaak alsnog gedupliceerd. Bij Forms is de gang van zaken iets anders. Daar wordt de nieuwste versie van de Form gedupliceerd, en vervolgens de gebruiker op de hoogte gesteld dat er een conflict was, dat met "de botte bijl" is opgelost. Tot slot is het nog mogelijk om bij een Folder een automatisch programma te registreren, dat aangeroepen wordt op het moment van een conflict zich voordoet. Dit programma kan dan eventueel het conflict oplossen.

3.3.2 Forms (formulieren) Om de communicatie in folders te structureren zijn er forms (formulieren). Een Form is een invulblad waar, in vastgelegde velden, informatie moet worden ingevoerd. Op deze manier wordt de informatie die opgeslagen of verstuurd moet worden gestructureerd volgens een voorgeschreven formaat en wordt daarmee voorkomen dat op een verkeerde manier informatie wordt aangeboden. Toepassingsmogelijkheden van forms zijn: • Versturen van informatie aan een persoon, distributie lijst of een folder; • Posten van informatie in een folder; • Reageren op een bericht; • Willekeurige bestanden volgens een standaard formaat. De Microsoft Exchange Client bevat standaard forms, zoals de New Message form om berichten aan te maken. Met behulp van de Forms Designer kunnen eigen specifieke forms gemaakt worden.

3.4 Exchange client (behorend bij Exchange Server) De Microsoft Exchange Client (behorend bij Exchange Server) geeft de mogelijkheid om op een effectieve manier informatie uit te wisselen. Het is mogelijk om berichten te versturen en te ontvangen, informatie te delen, ongeacht de plaats en het formaat van de informatie binnen de information store op de server (zie ook 3.2 en 3.7.1).

C

EDS, Versie l.o

Pagina 10 van 228

Rapport

EDS



Bij het opstarten van de Exchange Client is de zogenaamde 'Viewer', het window naar de informatie, zichtbaar. EDS documentor! - Microsoft Exchange

Jajffi..tfpic7§i$£ 7sP^'" Microsoft Exchange Q - Q Jan's personal folder 81 ~ Deleted 11 Items• •

-is'^ii ™ "

• ^ [ C E I ^ U ^ l l . J ^

•m Inbox & Outbox 1§J Sent Items

;

older

Figuur 4 - Exchange Viewer Het linker gedeelte van de Viewer laat een aantal folders zien, en het rechter gedeelte laat de inhoud zien van een geselecteerde folder. Vanuit deze Viewer, kan de gebruiker mail zenden en ontvangen, informatie organiseren, beheren, en uitwisselen. In de toekomst is Microsoft van plan de Windows verkenner, de Exchange viewer en de Internet verkenner tot een interface te versmelten. De gebruiker heeft dan een tool waarmee alle informatie bekeken kan worden, ongeacht of dit nu Exchange server folders zijn, filesysteem directories of Internet site's. Exchange is gebaseerd op een echte client-server architectuur, waarbij de communicatie op basis van Remote Procedure Calls (RPC) plaats vindt. De client software maakt hierbij gebruik van de Mail Application Programmers Interface (MAPI), die op zijn beurt dan de onderliggende RPC-laag aanstuurt. Microsoft Exchange clients communiceren met de server over bestaande transport protocollen zoals TCP/IP IPX/SPX en NetBEUI.

c

EDS, Versie 1.0

Pagina 11 van 228

Rapport

EDS



NT Server

Server components RPC

-Netwerk protocol-

RPC Provider MAPI Client components

Figuur 5 Client server architectuur Exchange Bij de huidige implementatie van de Microsoft clients geldt dat de Exchange client software niet gebruik maakt van alle functionaliteit die in MAPI aanwezig zijn. Dit betekent dat niet alle aanwezige functionaliteit van de Exchange server op de werkplek aanwezig is. Terwijl deze wel in Exchange Server zit. Dit komt aan bod bij de behandeling van het ingevulde VOSIP (zie 7). Behalve dat de Exchange client contact kan leggen met een Exchange server, is het ook mogelijk om rechtsreeks vanuit de client contact te leggen met: • een MS-Mail postkantoor, • een SMTP / MIME postbus. Dit vergroot uiteraard de inzetbaarheid van de client software, maar kan verwarring wekken bij de gebruikers, immers de Internet toegang kan op twee verschillende manieren vanuit hetzelfde tool verkregen worden. Rechtstreeks vanuit de client, of vanuit het postkantoor.

3.5 Schedule+ MS Scheduled is een middel om afspraken en taken te regelen. Zo kan de gebruiker: • Eigen afspraken vastleggen • Afspraken vastleggen met andere MS Schedule+ (behorende bij Exchange server) gebruikers d.m.v. het versturen van uitnodigingen • Prioriteiten voor taken vastleggen in de To Do lijst • Opslag van gegevens (adres, telefoonnummer., etc.) van contacten • Gebruik maken van waarschuwingen om zich te laten herinneren aan afspraken en taken Schedule+ organiseert deze informatie onder verschillende tabbladen. Deze tabbladen laten de scheduler, To Do lijst, contacten, en andere informatie op verschillende manieren zien. Deze zijn naar eigen behoefte aan te passen. De bij Exchange Server mee

e

EDS, Versie 1.0

Pagina 12 van 228



geleverde versie van Schedule+ maakt deels gebruik van de hidden folders uit de Information store en deels van MAPI.

3.6 Overige componenten Microsoft Office Microsoft Office vult Exchange aan met personal productivity tools zoals tekstverwerking en spreadsheets. A l deze tools kennen de faciliteit Mail en kunnen samenwerken met Exchange. Dat wil zeggen dat vanuit de betreffende programma's bestanden kunnen worden verstuurd. Ze maken hierbij gebruik van standaard MAPI. Word kan hierbij zelfs als volledige Email UA fungeren met beperkte functionaliteit. Voordeel is dan wel dat je bij het samenstellen van een bericht de volledige tekstverwerking faciliteiten van Word ter beschikking hebt. Bij gebruik van Microsoft Office in combinatie met Exchange Server kunnen ook de krachtige Folder en Forms faciliteiten gebruikt worden (zie ook 3.3). Op folders kunnen namelijk diverse acties gedefinieerd worden die automatisch worden uitgevoerd. Zo kan men een actie definieren om, zodra een spreadsheet met een gedefinieerde naam in een bepaalde folder wordt geplaatst, dat spreadsheet aan een applicatie te koppelen en de resultaten weer in een andere folder op te slaan.

3.7 Opzet Exchange infrastructuur Bij het opzetten van een Exchange infrastructuur komen nog een aantal aspecten aanbod die hieronder behandeld worden. Een van de belangrijkste aspecten is de nauwe relatie tussen Exchange en Windows NT.

3.7.1 Exchange infrastructuur Voordat een op Exchange gebaseerde infrastructuur kan worden opgezet, moeten eerst een aantal randvoorwaarden binnen de organisatie worden geidentificeerd. Deze omvatten ondermeer het type applicaties en services dat de gebruikers wordt geboden. Er zijn drie categorieen services: • Informatie services, dit zijn de services die de gebruikers voorzien van applicaties die nodig zijn om alle soorten van informatie zoals elektronische post, bestanden, rapporten en formulieren, te benaderen, te organiseren en uit te wisselen. Exchange biedt de volgende informatie services: • Elektronische post, voor de uitwisseling en organisatie van informatie; • Elektronische formulieren, voor de uitwisseling, routering en distributie van gestructureerde informatie;

C

EDS, Versie 1.0

Pagina 13 van 228



• Agenda, voor de planning en organisatie van persoonlijke tijdsindeling en ontmoetingen met anderen. • Messaging services, deze services ondersteunen de functies om gegevens van de ene plaats binnen de organisatie naar de andere plaats te krijgen, het bijhouden van en de uitwisseling van adresinformatie met vreemde systemen; • Connectivity services, ondersteunt de verbinding tussen gebruikers in verschillende sites, gebruikers op remote locaties en gebruikers van andere mailsystemen. De kwaliteit en de toepasbaarheid van de informatie services is direct afhankelijk van de aanwezige messaging en connectivity services. De aanwezige netwerk infrastructuur bei'nvloeden en beperken de toe te passen topologie. Hierbij zijn met name het type verbinding, bandbreedte en protocol bepalend. Afhankelijk hiervan kan bepaald worden waar de grens van een Exchange site (zie ook 3.7.2) komt te liggen. Communicatie tussen sites gaat over connectoren (zie ook 3.2). Dit kunnen de X.400 connector, dynamic RAS connector of de site connector zijn. De site connector werkt op basis van RPC's en kan alleen gebruikt worden als er snelle communicatie lijnen tussen de sites aanwezig zijn. De RAS connector werkt op basis van dialup verbindingen. De belangrijkste eis die Exchange stelt aan communicatie binnen een Exchange site is de aanwezigheid van Remote Procedure Calls (RPC). RPC wordt gebruikt voor de communicatie tussen Exchange servers onderling, met de clients en het beheerprogramma. Met dit mechanisme vindt tevens directory uitwisseling tussen Exchange servers onderling plaats. Binnen een site gebeurt dit automatisch. Bij RPC wordt gebruik gemaakt van de in Windows NT aanwezige authenticatie voorziening. Dit betekent dat de servers of in hetzelfde domein (zie ook 3.7.2) moeten zitten of dat er een trust relatie aanwezig moet zijn tussen de domeinen. Daarnaast moet er sprake zijn van een communicatieverbinding met hoge snelheid. Als de directory uitwisseling over langzame verbindingen gebeurt heeft dit een negatieve invloed op de performance van alle Exchange servers.

3.7.2

Domeinen en sites

Zoals in 3.7.1 al aangegeven is er een nauwe relatie tussen de Windows NT domeinen en de Exchange site infrastructuur. Deze relatie heeft een directe invloed op de op te zetten (beheer) omgeving middels Exchange en Windows NT. Het een kan niet los van het ander geschieden. Bij de opzet is het belangrijk de volgende definities te kennen die de essentiele verschillen tussen domeinen en sites weergeven: • Microsoft Exchange sites zijn eilanden/groepen van hoge bandbreedte synchrone L A N connectivity, die bepaald worden door de netwerk en messaging topologie. De fysieke infrastructuur is hier dus bepalend.

c

EDS, Versie 1.0

Pagina 14 van 228

Rapport

EDS



Windows NT domeinen zijn basis eenheden van security en administrate in het netwerk, die bepaald worden door administratieve behoeften. Beheersmatige organisatorische structuren zijn hier dus bepalend. Door bovenstaande op een incorrecte manier te combineren ontstaat een onbeheersbare, slecht functionerende infrastructuur. Mogelijkheden die wel goed gaan worden hieronder beschreven. Belangrijk hierbij is nog dat een NT domein gedefinieerd / vastgelegd wordt tijdens de initiele installatie van een NT server. Naderhand aanpassen is niet mogelijk. Het is derhalve belangrijk dat de NT domein omgeving goed wordt opgezet met de Exchange infrastructuur in gedachte. •

Bij het samenstellen van sites en domeinen zijn er de volgende basis mogelijkheden: • 1 site en meerdere domeinen (zie Figuur 6). In deze configuratie dienen er of trust relaties tussen de domeinen te bestaan of service-accounts die toegankelijk zijn vanuit de andere domeinen. • 1 domein en meerdere sites (zie Figuur 7). Het nadeel van het opsplitsen in sites is, dat er voor beheerstaken expliciet verbinding moet worden gemaakt met de individuele site. • 1 site en 1 domein (zie Figuur 8). Bij deze opzet komt de administratieve indeling voor zowel domein als site overeen.

Windows NT domein

Figuur 6 - Meerdere domeinen en 1 site

0

EDS, Versie 1.0

Pagina 15 van 228



Bouwdienst

Figuur 7-1 domein, 2 sites

Bouwdienst

Gebruiker Windows NT domein

Figuur 8-1 domein en 1 site De eenvoudigste topologie is die, waar de site overeen komt met een domein. Een variatie op deze topologie is een indeling waarbij de gebruikers en servers in aparte domeinen zitten (zie Figuur 9). Er hoeft dan enkel een trust relatie aanwezig te zijn tussen de server en gebruikers domeinen.

e

EDS, Versie 1.0

Pagina 16 van 228

Rapport

EDS



Single Master Domain Model Het single master domain model (zie Figuur 10) bestaat uit meerdere domeinen, waarvan er een fungeert als het centrale administratieve punt voor gebruikers accounts. Alle gebruikers en machine accounts zijn gedefinieerd in dit "master" domein. En alle gebruikers loggen in op dit master domein. Resources, zoals printers en file servers, bevinden zich in de andere domeinen. Elk resource domein heeft een oneway trust met het master (account) domein, waardoor gebruikers met accounts in het master domein resources kunnen gebruiken in alle andere domeinen (indien toegestaan). De netwerk beheerder kan hierdoor het complete multidomein netwerk beheren, zowel de gebruikers als de resources, door maar een domein te beheren. De Exchange Site omvat alle beheers domeinen. Vanwege het feit dat die beheer domeinen als het ware een geheel vormen, kunnen de servers in die ene site zonder problemen samenwerken. Uiteraard dienen er wel voldoend snelle netwerk verbindingen aanwezig te zijn.

c

EDS, Versie 1.0

Pagina 17 van 228

Rapport

EDS


Registratienu m mer A2530#06-R-l

Figuur 10 - Single master domein

Het master domein model is bijzonder geschikt voor: • Gecentraliseerd account management. Gebruikers accounts kunnen centraal beheerd worden: gebruikers accounts kunnen worden toegevoegd/verwijderd en aangepast vanaf een plaats. • Gedecentraliseerd resource management of lokaal systeem beheer blijft mogelijk. Lokale domeinen kunnen zelf beheer plegen over resources binnen de locatie. • Resources kunnen logisch gegroepeerd worden, overeenkomstig met de lokale domeinen. Het single master domein concept is bruikbaar voor netwerken met tot 15.000 gebruikers. Het master domein omvat dus een WAN. Om een optimale response en bedrijfszekerheid te verkrijgen kan in elk gekoppeld L A N een Backup Domein Controller worden geplaatst.

3.7.3

Directory synchronisatie

De directory synchronisatie binnen een site gebeurt volledig automatisch via RPC's. Tussen sites onderling gaat dit over connectoren. De Exchange directory service is een uitbreiding op de Windows NT Server directory met mail specifieke eigenschappen. Elke in de directory opgenomen Exchange mailbox, public folder of distributie lijst is gekoppeld aan een Windows NT gebruikers account. De Microsoft Exchange server Directory Information Tree (DIT) (zie Figuur 11) is de weergave van de server topologie en illustreert de relaties tussen de organisatie, site en servers.

C

EDS, Versie 1.0

Pagina 18 van 228

Rapport

EDS



Organization-

Sites

«rSj

Microsoft I—M Organization Recipients BApps-WGA S 4 § » Office £-4^1 WSPU S- tji] Addressing Configuration f f o Connections jjf) Monitors '^J Recipients B- Q Servers DABONE B ~ 3 damen-dog

Servers 1

|j

Server Recipients

Figuur 11 - Directory Information Tree (DIT). Bij de directory synchronisatie tussen sites is er in elke site een z.g. bridgehead server aangewezen. Alle directory synchronisatie loopt via deze server. Een voorbeeld van een directory synchronisatie topologie (gebaseerd op het master domein concept) tussen sites is weergegeven in Figuur 12.

Figuur 12 - Directory synchronisatie tussen sites

3.7.4 Beveiliging Exchange biedt de mogelijkheid tot de encryptie en het voorzien van digitale handtekeningen van berichten. Hiertoe moet binnen de organisatie (eventueel bestaande uit meerdere domeinen en sites) een Key Management server aanwezig zijn. Op deze server worden security tokens gegenereerd voor gebruikers. De gebruiker kan dit to-

c

EDS, Versie 1.0

Pagina 19 van 228

Rapport

EDS



ken dan gebruiken bij het verzenden van berichten. De beveiliging is gebaseerd op het uitwisselen van mail met de Key server, er wordt hierbij geen RPC gebruikt. Hierdoor is deze faciliteit voor alle sites in een organisaties centraal via een server te beheren. Ter verhoging van de performance en de betrouwbaarheid kan de Key server gerepliceerd worden over meerdere locaties.

3.7.5

Monitoring

Exchange bezit een faciliteit die monitoring wordt genoemd, om te controleren of bepaalde mailkoppelingen nog actief zijn, of Exchange servers overal bijvoorbeeld de juiste tijdinstellingen gebruiken en of alle services actief zijn etcetera. Voor de controle van verbindingen (link monitoring) worden testboodschappen (ping) naar andere bestemmingen verzonden en gecontroleerd of hierop binnen een bepaald tijdsbestek wordt gereageerd. In geval van afwijkingen kan een notificatie in de vorm van berichten aan beheerders of piepers worden geactiveerd. Hiermee kan de goede werking van en mailinfrastructuur worden gecontroleerd.

° EDS, Versie 1.0

Pagina 20 van 228

Rapport

EDS



4 Huidige Verkeer en Waterstaat Email infrastructuur Dit hoofdstuk bevat een beschrijving van de huidige VenW Email infrastructuur.

4.1 Functionaliteit De Email infrastructuur van VenW is gebaseerd op het bieden van X.400 functionaliteit tot op de werkplek. Als voorkeursprodukt voor deze functionaliteit hanteert VenW de Route400 software van NetTel. De eisen waar Email aan moet voldoen, zijn opgenomen in het Verkeer en Waterstaat OSI Profiel (VOSIP). In het VenW-net is een backbone structuur aanwezig. Alle VenW-diensten zijn via hun eigen lokale MTA en het VenW-net aangesloten op de Email backbone machine(s). Deze backbone machine(s) zorgen voor de routering van alle Email berichten zodat deze op de juiste MTA's worden afgeleverd. Tevens vinden hier bodypart conversies plaats voor berichten die bestemd zijn voor niet-Route400 omgevingen. De uitbreidingsmogelijkheden van deze structuur zijn groot en de routering is hiermee centraal geregeld. V&W

E-Mail

BackBone v w dd 27Juni 1999

Figuur 13 - VenW Email backbone In • • •

0

de Email backbone zijn de volgende functies aanwezig:: Email X.400 en Internet (MIME-gateway); Versturen van faxen; Remote postbus toegang door middel van inbel faciliteit.

EDS, Versie 1.0

Pagina 21 van 228



4.1.1 Email backbone De Email backbone stelt organisatie-onderdelen van VenW in staat om berichten onderling uit te wisselen en bovendien met partijen die eveneens zijn aangesloten op de backbone. De uitwisseling van berichten gebeurt op basis van het X.400-protocol. De backbone biedt standaard toegang tot diverse externe mailnetwerken: • 400net Via het 400net zijn een groot aantal bedrijven, ministeries en instellingen in binnen- en buitenland bereikbaar. Uitwisseling gebeurt op basis van het X.400protocol; • Internet Veel externe organisaties beschikken niet over X.400, maar kunnen wel elektronische post via het Internet ontvangen. Uitwisseling van berichten gebeurt dan op basis van het SMTP-protocol. Een SMTP-gateway in het VenW-net converteert X.400-berichten naar SMTP-berichten om berichten uitwisseling met deze organisaties mogelijk te maken. Bovendien zorgt de MIME (Multi-purpose Internet Mail Extensions)-gateway ervoor dat onderdelen van berichten die geen platte tekst bevatten toch via SMTP te verzenden zijn.

4.1.2 Faxen Via de Fax-gateway kan men faxen elektronisch versturen naar een fax elders. (Op dit moment enkel uitgaande faxen);

4.13

Remote raadplegen van post

Omdat steeds vaker medewerkers van verschillende plekken hun post willen raadplegen, is de Message Store faciliteit aanwezig. De postbus van een gebruiker is nu op verschillende manieren (inbellen of via LAN) te bereiken.

4.2 Naamgeving en adressering Verkeer en Waterstaat hanteert een aantal regels voor de naamgeving en adressering van X.400 en Internet Email bestemmingen. Dit houdt in dat elk bedrijfsonderdeel van VenW dezelfde regels hanteert bij de invulling van een Email adres voor hun medewerkers. Zo gelden er ook regels t.a.v. de routering. Per dienst zijn maximaal twee OU-velden in gebruik voor het routeren van berichten. Indien er meerdere vestigingen van een dienst op de backbone aangesloten zijn, wordt op de backbone gerouteerd op Surname.

4.2.1

Directory synchronisatie via adresboek uitwisseling

De Email directory met adressen van de medewerkers zijn onder Route400 opgenomen in adresboeken die zich op de MTA's bevinden. Om ervoor te zorgen dat er zo

c

EDS, Versie 1.0

Pagina 22 van 228

Rapport

EDS



min mogelijk problemen bij de adressering voorkomen worden regelmatig adresboeken van alle diensten gedistribueerd, zodat de meest recente adresgegevens beschikbaar zijn. Een probleem hierbij is dat niet elke dienst gebruik maakt van het ROUTE400 mail systeem, maar van bijv. MS-Mail, WP-Office (Groupwise). Deze diensten zijn via een eigen gateway aangesloten op de backbone. De adresinformatie (adresboeken) is dan alleen met conversieprogramma's om te zetten naar ROUTE400 adresboeken.

4.2.2 X.500 X.500 is de OSI gestandaardiseerde directory service. Middels X.500 is voorzien in een wereldwijde gekoppelde directory service voor diverse organisatorisch aspecten zoals Email adressen van medewerkers. Er is in voorzien dat een organisatie de eigen informatie zelf kan beheren en op een eigen X.500 server ter beschikking kan stellen. Alle X.500 servers samen vormen een wereldwijd netwerk. De informatie in de directory kan opgevraagd worden. Email systemen zouden hier gebruik van kunnen maken en geen eigen adresboeken meer hoeven te hebben. VenW is momenteel bezig met een dergelijke faciliteit, er is echter geen directe koppeling aanwezig met Route400.

4.3 Route400 Route400 van NetTel is binnen VenW het voorkeursprodukt voor Email. Dit produkt bestaat uit MTA-software en User Agents (client programma) voor het MSDOS, Windows (16-bits) en UNIX platform. In de hierbij gebruikelijke configuratie communiceert de User Agent via het PC-LAN met een server waarop zich een directory structuur bevindt. In deze directories worden de te verzenden berichten geplaatst, waarna een actief programma op de MTA zorgt voor de verdere verplaatsing van de berichten. Een andere maar niet mindere gebruikelijke mogelijkheid is de communicatie van de User Agent rechtstreeks met een messagestore.

•

Window

Figuur 14 - Route400 omgeving

0

EDS, Versie 1.0

Pagina 23 van 228



5 Exchange binnen Verkeer en Waterstaat 5.1 Infrastructurele aspecten Exchange kan binnen Verkeer en Waterstaat op verschillende manieren worden ingezet: • Totale vervanging van de huidige Email structuur inclusief backbone structuur; • Gebruik van Exchange op locatie bij een bedrijfsonderdeel; • Mengvorm van bovenstaande. Er is nog een vierde mogelijkheid. Hierbij wordt een deel van een bedrijfsonderdeel middels Exchange van Email voorzien. Deze mogelijkheid wordt verder niet behandeld omdat deze slechts realiseerbaar is indien de naamgeving en adressering aangepast wordt aan de routeer mogelijkheden van Exchange (zie 7 en 8). Bij de huidige regels voor naamgeving en adressering moet een bedrijfsonderdeel (uniek bepaald door het adres t/m de OU's) als geheel overgaan op Exchange, of in het geheel niet. Totale vervanging Door de totale Email infrastructuur te vervangen door een Exchange omgeving worden de faciliteiten van Exchange ten voile benut. Alle mogelijkheden van de combinatie Microsoft Office met Exchange server zijn dan Verkeer en Waterstaat breed te gebruiken. Ook het beheer kan dan op eenvoudige wijze centraal geschieden. Bij centraal beheer functioneert de omgeving optimaal. Voorwaarde daarvoor is uiteraard dat de organisatie onderdelen bereid zijn de beheer verantwoordelijkheid ook daadwerkelijk uit handen te geven naar een centrale instantie. Wordt geen centraal beheer toegepast dan worden de mogelijkheden van Exchange veel minder goed benut, en is een goede procedurele afstemming van de decentrale beheer omgevingen vereist. De huidige backbone faciliteit fax-gateway is in een pure Microsoft Exchange omgeving echter niet meer aanwezig. Hiervoor zijn wel produkten van derden beschikbaar die in de Exchange architectuur opgenomen kunnen worden. De huidige backbone functie van Email gateway naar Internet kan zonder problemen door Exchange worden ingevuld. Ondersteuning van UNIX platformen is wel aangekondigd maar nog niet beschikbaar. Remote raadplegen van post is wel mogelijk, alleen gaat dan op een iets andere wijze dan bij Route400. Er wordt een volledige LAN-LAN koppeling gelegd (al of niet via Remote Access Services) waarover dan gewerkt wordt als was het een gewone omgeving. Faciliteiten om selectief berichten uit de message store te halen zijn, net als bij Route400, aanwezig. Vooralsnog lijkt een volledige overgang op Exchange gezien het beleid, de zelfstandigheid van bedrijfsonderdelen en de te ondersteunen platformen binnen de VenW organisatie niet opportuun. Gebruik binnen een bedrijfsonderdeel Gebruik van Exchange binnen een bedrijfsonderdeel verschilt niet wezenlijk van de huidige situatie. Nu wordt ook niet overal Route400 gebruikt. In de nieuwe toestand zullen enkele van de huidige WPO (Groupwise) of MS-Mail omgevingen, en mogelijk enkele Route400 omgevingen vervangen worden door Exchange. De mogelijkhe-

°

E D S

-

V e r s i e 1 0

Pagina 24 van 228

Rapport

EDS



den van Microsoft Office met Exchange blijven beperkt tot het betreffende dienstonderdeel. Beheer dient Iokaal plaats te vinden. Net als nu bij de WPO (Groupwise) of MS-Mail omgevingen zullen de gebruikers verschillen in faciliteiten bemerken afhankelijk van de bestemming. De belangrijke functionaliteit van meesturen van documenten is, by een correcte configuratie, gewoon mogelijk ongeacht de bestemming Net als thans bij Route400 dient hiervoor een binaire bijlage mee gestuurd te worden Dit heeft de gebruikelijke beperking dat informatie als filenamen verloren gaan Op ' het moment dat ook de rest van de infrastructuur het File Transfer Body Part ondersteund, kan daarvan gebruik gemaakt worden. Op dat moment vervallen de nadelen van verlies aan filenamen etc.. Mengvorm Indien er meerdere bedrijfsonderdelen overgaan op Exchange is de mengvorm mogelijk de aangewezen weg. Indien er namelijk gekozen wordt voor een master domein model met een centraal beheersdomein op VenW-net niveau kan er een grote VenW site gerealiseerd worden die de volgende functies verzorgt: • Directory synchronisatie tussen alle sites bij de directie; • Routering van Email naar en van Exchange sites; • Routering van en naar de X.400 mail backbone;' • Import van Route400 adresgegevens in Exchange; • Centrale Key management server voor encryptie functies; • Centrale administratie. De faciliteiten van Microsoft Office met Exchange zijn bij deze oplossing mogelijk tussen de d.enstonderdelen die er gebruik van maken. Dit levert wel een inconsistent gedrag op voor de gebruikers, die naar de ene directie bepaalde faciliteiten wel en naar een andere directie die faciliteiten niet kunnen gebruiken De functionaliteit van centrale administratie is sterk gebonden aan de opzet van de onderl.ggende Windows NT server domeinen. Hierbij is een op het Single Master Dome.n concept gebaseerde indeling noodzakelijk. Dit concept is toereikend voor organisaties tot 15.000 medewerkers, en is dus bruikbaar voor VenW Ook de voorwaarde van snelle L A N - L A N verbindingen is binnen VenW-net geen probleem Net als bij een volledige overgang is delegatie van verantwoordelijkheden naar een centrale organisatie noodzakelijk.

5.2 X.500 De in Exchange aanwezige directory service is een superset van de standaard X 500 duectory service. De reden dat een uitbreiding aanwezig is, ligt in de behoefte aan ondersteuning van file en object services. Hierbij geeft de directory niet alleen informatie over de locatie van netwerk bestemmingen, maar ook over de inhoud hiervan. De voor eind 1996 / begin 1997 aangekondigde versie van de Microsoft directory service zal in staat zijn om te communieren en gegevens uit te wisselen met op X 500 gebaseerde services middels DAP en LDAP. Dit laatste is nog niet het geval in de C

(

}

8

6

D i t b C t e k e n t

V « WX.500 Y S service mogelijk ^ r - worden. VenW zal

C

EDS, Versie 1.0

V

°

0 r d e

t 0 6 k 0 m s t

d a t

°P™™ « ^ n

Pagina 25 van 228

Rapport

EDS



5.3 Adresboek synchronisatie met Route400 Exchange kent z.g. Recipients Containers. Zo'n container bevat adresgegevens van gebruikers. Dit kunnen Exchange gebruikers (of distributielijsten) zijn binnen de organisatie, maar ook gebruikers van andere mail systemen. De laatste zijn de Custom recipients. Door subcontainers te maken kunnen groepen gebruikers logisch gerangschikt worden. Er kan bijvoorbeeld een hoofdcontainer gemaakt worden voor VenW, waarin subcontainers aanwezig zijn per directie/dienst. Alle Recipients kunnen worden gei'mporteerd en geexporteerd naar ASCII bestanden. Door templates te maken kan het formaat van deze bestanden worden bei'nvloed. Op deze wijze kunnen Route400 adresboeken worden gei'mporteerd in Exchange en Exchange adresgegevens geexporteerd naar Route400. Helaas zijn de ASCII bestanden die hierbij gebruikt worden niet onmiddellijk geschikt voor export of import. Deze zullen handmatig of met behulp van een (te bouwen) conversieprogramma moeten worden aangepast. Ook zullen er binnen de beheersorganisatie afspraken moeten worden gemaakt over de te volgen procedures.

5.4 Instellingen Exchange X.400 connector De communicatie tussen een Exchange X.400 connector en een vreemde X.400 MTA kan lopen over een TP0/X.25, TP4(CLNP) en TPO/RFC 1006 over TCP/IP koppeling. Binnen de VenW infrastructuur kan naar keuze de TP4(CLNP) of TPO/RFC 1006 koppeling gebruikt worden. Beiden functioneren naar behoren, vooropgesteld dat voor de communicatie op X.400 niveau de monologue methode gebruikt wordt, en niet de two-way alternate methode. De configuratie en installatie is vrij recht toe rechtaan. De enige onduidelijkheid is dat bij de configuratie van de TP/4 protocol stack als parameters het Local Address en het NSAP adres moeten worden opgegeven. Voor beide moet hierbij hetzelfde hexadecimale (aangegeven door het teken '$') NSAP-adres worden ingevuld: "S39528F110401000100010000000000881". ISO TP4/CLNP Configuration

Figuur 15 - TP/4 adressering

Bij TPO/RFC 10006 hoeft slechts een TCP/IP adres van de andere MTA opgegeven te worden. In beide gevallen dient uiteraard ook het X.400 gedeelte met de routeringsregels ingevuld te worden.

°EDS, Versie 1.0

Pagina 26 van 228

Rapport

EDS



5.5 Verschil in functionaliteit voor gebruiker Route400 biedt aan de gebruiker, conform het beleid, de functionaliteit van X.400 Email op de werkplek. Dit is bij Exchange niet het geval. Voor de gebruiker is dit merkbaar door het ontbreken van functies in de Exchange client die hij wel tot zijn beschikking heeft in de Route400 user agent. De volgende tabel geeft een overzicht van de functies die in beide client programme's aanwezig zijn. Hierbij is uitgegaan van de Route400 versie 5.1 en Exchange versie 4.0 client. In de onderstaande tabel is aangegeven of een functionaliteit aanwezig is. In bijlage A is aangegeven hoe de functionaliteit geactiveerd wordt in het user interface. Indien een functionaliteit zowel bij Exchange als bij Route400 aanwezig is, wil dat nog niet zeggen dat dit ook van toepassing is bij het versturen van berichten tussen Exchange en Route400 onderling. Sommige functies worden binnen Exchange namelijk op een propriarty manier ingevuld en niet op een standaard X.400 manier. Hier is dan meestal iets over vermeld in de kolom Opmerkingen.

Functionaliteit Folder/berichten/documenten beheer Nieuwe folder Shortcut op desktop Open Sluit Sla op Sla op als Kopieer naar Verplaats naar Afdrukken van Pagina layout Printer setup Hernoem Eigen schappen Importeer Delete Cabinet (of Folder) Doorsturen van bericht Beantwoord afzender Beantwoord alle adressanten Beantwoord aan distributie lijst Beantwoord met behoud van bericht aan afzender Beantwoord met behoud van bericht aan alle bestemmingen Beantwoord met behoud van bericht aan distributielijst Verbind met externe message store Haal kopie van boodschappen op van externe message store Haal boodschappen op van externe message store Wijzig wachtwoord

c

EDS, Versie 1.0

Exchange

J J J N J J J J J N N

Route400 5.1

Opmerkingen

Intray J N J J J J J J J J J N J N J J J J J

J J J J J J J N N

J

N

J

N J J J

J

1

1

J

Pagina 27 van 228

Rapport

EDS



Functionaliteit Communicatie parameters Layout Aanpassen van toolbar Gebruikers voorkeuren Automatisch verwerken van binnengekomen berichten

Exchange J J J J J

Route400 5.1 J J J J N

Automatisch verwerken van binnengekomen berichten bij afwezigheid Schrijven van Post Nieuw bericht Open bericht Voor gedefinieerde berichten laden Voor gedefinieerde berichten aanmaken Invoeren bestemming

J

N

J J J

J J J

J

J

J

J

Bijsluiten van bijlagen tekst Bijsluiten van bijlagen files Bijsluiten van bijlagen bericht Bijsluiten van bijlagen object

N J J J

J J N N

Bijsluiten van bijlagen enclosure

N

J

Opnieuw beginnen Enkelvoudige bestemming verwijderen Alle bestemmingen verwijderen Relateer delivery report aan verzonden bericht. Verzend bericht Zend als proef Zend alle klaarstaande berichten Test op berichten Kenmerken van bericht Vraag om ontvangstbevestiging Vraag om leesbevestiging Retourneer inhoud indien niet bestelbaar Lever bericht af op tijdstip

J J

J J

J N

J J

J N J J

J J J J

J J N

J J J

J

J

N

J

N N N J J N

J J J J J J

N

J

Verklaar verzonden bericht als ongeldig Leg relaties tussen berichten Vraag iedereen om antwoord Prioriteit van bericht Importantie van bericht Gevoeligheid van bericht Verzend lijst van bestemmingen met bericht Bericht afleveren bij afwijkende

c

EDS, Versie 1.0

Opmerkingen

wel voor de nieuwste versie (5.2) in combinatie met de message store idem

Route400 biedt meer mogelijkheden voor individuele adressen en distributielijsten.

een OLE object dat de ontvanger zo kan activeren bij Route400 kan de gebruiker kiezen uit verschillende soorten bijlagen

bij exchange dient de user agent actief te blijven totdat het bericht verstuurd is

wordt bij exchange altijd gedaan

Pagina 28 van 228

Rapport

EDS

Project MSXCH01 Status definitief Functionaliteit adressering Verbiedt conversie van bericht verbiedt doorsluizen van berichten Verbiedt conversie als er informatie verloren gaat Maak geen gebruik van distributielijst expansie Encrypt bericht Voeg digitale handtekening toe Edit Maak ongedaan Knip Kopieer Plak Venvijder Selecteer alles Zoek naar Zoek en vervang

Registratienummer A2530#06-R-l Exchange

Route400 5.1

N N

J J

N

J

N

J

J J

N N

J J J J J J J J

J J J J J J N N

Opmerkingen

Exchange beschikt wel over functies voor de gebruiker, die niet aanwezig zijn in Route400. Dit zijn functies zoals Rules, Out Of Office tools, Public folders en Elektronische formulieren. In de nieuwste versie van Route400 (UA 5.2 + MTA 3.5) zijn Rules en Out Of Office faciliteiten wel aanwezig.

5.6 Uitwisseling van bijlagen Bij de uitwisseling van bijlagen tussen verschillende mailsystemen treedt altijd verlies van informatie op. Route400 kent bijvoorbeeld de mogelijkheid om bestandsnamen toe te voegen aan een bodypart. Deze informatie gaat verloren zodra een bericht naar een niet Route400 bestemming wordt verzonden. De mail backbone converteert dit bericht naar een bodypart van het type Undef. Het type Undef is een puur binaire vorm van de bijlage, waarbij de ontvangende gebruiker zelf moet bepalen wat hij met de inhoud moet toen. Hierbij gaat zelfs de naam van de bijlage verloren. Het zelfde geldt ook voor bijlagen in de Exchange omgeving. Bij berichten verkeer tussen Exchange sites onderling kunnen bijlagen in de vorm van documenten en/of OLE-objecten worden verzonden. De ontvangende kant herkent dit. Zodra naar een niet Exchange omgeving een bericht wordt verzonden, vindt er een conversie plaats naar een Undef formaat. Ook hierbij gaat naamgeving informatie verloren. De gebruiker zal in beide gevallen in zijn bericht moeten aangeven wat voor bijlagen hij met het bericht mee verzend. Zaken als dubbelklikken op de bijlage waarna de bijlage op de juiste wijze wordt geopend is er dus niet meer bij. Er is dus geen verschil tussen een situatie met Exchange en de situatie nu voor wat betreft het versturen van bijlagen. Voor beide geldt dat in een uniforme omgeving meer mogelijk is dan in een gemengde omgeving.

C

EDS, Versie 1.0

Pagina 29 van 228

Rapport

EDS



Exchange en de volgende releases van Route400 ondersteunen het File Transfer Body Part. In die situatie kunnen gegevens als filenaam, omvang en type (word document, lotus spreadsheet etc.) op een gestandaardiseerde manier verstuurd worden.

5.7 Migratie / invoering aspecten Bij het migreren van bestaande Email omgevingen naar een Exchange server omgeving zijn ongeacht het uitgangspunt (MS-Mail omgeving, Route400 omgeving of overige (WP-Office / Groupwise)) een aantal punten van belang. De volgende punten kunnen onderscheiden worden: • hardware platformen Zoals reeds is aangegeven draait een Exchange server uitsluitend op een NT platform. Dit betekend dat huidige omgevingen waar MS-DOS, MS-Windows of UNIX platformen gebruikt worden om de MTA software op te draaien over moeten gaan tot invoering van Windows NT. Bovendien stelt exchange hoge eisen aan de hardware. Een 130 Mhz Pentium processor met 32 Mbyte intern geheugen is ongeveer de minimum omgeving waarbinnen het kan functioneren. Voor omvangrijke postkantoren zijn nog zwaardere systemen nodig. Dit betekend dat locaties waar al Windows NT gebruikt wordt mogelijk ook zwaardere systemen moeten aanschaffen. • beheer (NT) omgevingen Voor beheer van een Exchange omgeving wordt gebruik gemaakt van de standaard faciliteiten in Windows NT. De onderlinge relatie is zo sterk, dat als de Windows NT omgeving niet goed is opgezet ook de Exchange omgeving niet goed kan functioneren. Dit heeft dan met name betrekking op de beheer omgeving met domeinen zoals beschreven in 3.7.2. Indien bestaande NT domeinen niet zodanig zijn opgezet dat ze de gewenste Exchange infrastructuur ondersteunen, kan het nodig zijn de software opnieuw te installeren. Dit is een belangrijke ingreep in de operationele omgeving. • software licenties De kosten zijn op te splitsen naar kosten voor de Server omgeving, en kosten per werkplek. Bij dat laatste moet men zich realiseren dat de bestaande faciliteiten binnen Windows95 niet kunnen communiceren met Exchange Server zonder de correcte DLL. Voor die laatste dient men per werkplek te betalen. De prijsstructuur van de Exchange Server + clients is redelijk complex. lets vereenvoudigd komt het neer op: basis server 6.300,per 50 gebruikers 9.800,standaard connector ongelimiteerd 1.000,Internet connector ongelimiteerd 1.000,X.400 connector ongelimiteerd 1.800,client licences per 20 2.800,• adresboeken Tenzij VenW als geheel overgaat op Exchange, zal er bij invoering van Exchange op diverse locaties een gemengde Exchange niet-Exchange (Route400) omgeving ontstaan. Om de VenW infrastructuur als geheel goed te laten blijven functioneren zullen dan een aantal maatregelen genomen moeten worden.

c

EDS, Versie 1.0

Pagina 30 van 228



Een belangrijk integrerend hulpmiddel is momenteel de uitwisseling van adres boeken. Bij invoering van Exchange is het belangrijk ook adres gegevens met de Exchange omgeving uit te wisselen. Technisch is dit zonder meer mogelijk. Procedureel zullen hiervoor de noodzakelijke randvoorwaarden geschapen dienen te worden. • applicaties Er zijn momenteel mogelijk applicaties die geschreven zijn met behulp van de Route400 programmeer mogelijkheden. Deze dienen geconverteerd te worden. Alleen eenvoudige Simple MAPI applicaties kunnen waarschijnlijk zonder aanpassingen gebruik maken van Exchange. • backbone Afhankelijk van hoe Exchange wordt ingevoerd dient ook de huidige backbone functionaliteit te worden aangepast. Indien geheel VenW overgaat op Exchange wordt uiteraard ook de backbone ingevuld middels exchange. Indien een deel van VenW overgaat op Exchange, maar er wel een centrale Exchange site wordt opgenomen, is het voor de hand liggend om deze in de backbone op te nemen. In beide gevallen dienen er dus aanpassingen in de backbone en het bijbehorende contract gepleegd te worden. Uitsluitend indien slechts op enkele locaties Exchange wordt ingevoerd hoeft er aan de huidige backbone niets te veranderen.

c

EDS, Versie 1.0

Pagina 31 van 228

Rapport

EDS



6 Microsoft Office faciliteiten binnen de huidige infrastructuur Een van de aanleidingen om naar de Exchange Server omgeving over te gaan is het gebruik van de extra faciliteiten die ontstaan binnen de Microsoft Office omgeving. Het is echter de vraag of die faciliteiten niet ook op een andere manier ingevuld kunnen worden binnen de VenW infrastructuur. Een deel van de functionaliteit werkt zonder problemen over elke goede 32 bit MAPI 1.0 implementatie, zoals uit onderstaande tabel blijkt. Exchange client uit Windows95 Exchange client behorend bij Exchange server

J N

Forms Publieke folders Key management Word Excel Schedule+ uit Office95 Schedule+ behorend bij Exchange server

N N N J J J N

maar is niet relevant vanwege het feit dat het enige verschil in functionaliteit te maken heeft met de Folders van Exchange Server is geen MAPI feature

heeft hidden folders nodig

Voorwaarde is een goede MAPI server implementatie. Bij het huidige Email produkt Route400 is Simple MAPI ondersteuning aanwezig. Aan een uitgebreide MAPI ondersteuning wordt gewerkt. Naar verwachting komt er eind 1996 een eerste (beperkte) implementatie als beta beschikbaar. Dit betekend dat waarschijnlijk in de loop van 1997 de met een J aangegeven faciliteiten middels Route400 mogelijk zullen worden. Ten aanzien van folders en uitwisseling van documenten worden binnen de VenW Intranet omgeving momenteel andere faciliteiten ontwikkeld. Zodra die operationeel zijn bieden die een goede mogelijkheid voor implementatie van de functionaliteit. Het hebben van verschillende mogelijkheden vergroot weliswaar de flexibiliteit, maar ook de verwarring en dus fouten. Nadeel van de Intranet faciliteiten is dat ze minder geintegreerd zijn met de Microsoft Office faciliteiten. Voorde Key-management faciliteiten, o.a. benodigd voor versleutelen van berichten, zijn geen alternatieven voorhanden. Met dien verstande dat ook Route400 mogelijk-' heden kan bieden voor beveiligd berichten verkeer. Het ziet er derhalve naar uit dat op korte termijn (nog in 1996) alle functies die van belang zijn, uitgezonderd een deel van de beveiligingsmogelijkheden ook op een andere manier geimplementeerd kunnen worden dan middels Exchange Server.

°EDS, Versie 1.0

Pagina 32 van 228

Rapport

EDS



7 Exchange en het VOSIP In een eerder rapport (A2530#04-R-l) is het door Microsoft ingevulde VOSIP vragenformulier opgenomen. In dit hoofdstuk wordt de samenvatting van de belangrijkste omissies herhaald en aangevuld met bevindingen uit de testresultaten. Hieronder volgt een tabel met daarin de geconstateerde afwijkingen ten opzichte van het VOSIP voor de verplichte (M) elementen. Er wordt aangegeven of het element wel (Y) of niet (N) ondersteund wordt door de huidige UA en door MAPI. Soms wordt onderscheidt gemaakt tussen verzenden (Orginator / Orig.) en ontvangen (Recipient / Rec). Verder worden de consequenties aangegeven. Hierbij wordt onderscheid gemaakt tussen Inter Personal Mail (IPM) en meer bedrijfsmatig gebruik van mail. Service element

UA

MAPI

opmerkingen

Content Type Indication

N

Y

De gebruiker kan niet zien welke bodypart typen in binnenkomende berichten zitten. Ook kan niet worden aangegeven welk type gebruikt moet worden bij verzenden. De gebruikte waarde voor verzenden is bij installatie wel in te stellen. Uit de testen blijkt dat als een forwarded bericht wordt ontvangen wel keurig middels een envelop in het bericht wordt aangegeven dat er doorgestuurd bericht is bijgesloten. Door activeren kan dit ook gewoon gelezen worden. Voor dagelijks gebruik voor IPM verkeer is dit geen probleem.

Converted Indication

N

Y

Typed Body

N

Disclosure of other recipients

Y (Orig) N (Rec)

N (Orig) N (Orig) Y (Rec)

De gebruiker kan niet zien of een bericht door de MTA is geconverteerd, en wat het oorspronkelijke bodypart type was. Slechts van belang bij problemen, als alles normaal verloopt is dit geen probleem. Hoewel verphcht in het VOSIP niet relevant in dagelijks gebruik Deze vorm van ondersteuning is wel erg vreemd, en duidt mogelijk op een invul fout. De praktijk leert dat meerdere adressanten wel worden getoond. Uit de testen blijkt dat dit inderdaad niet goed is ingevuld. Bij verzenden is het niet in te stellen. Ondersteuning bij ontvangst kon door de testen niet bevestigd worden. De correcte invulling moet zijn: N (Orig.) N (Orig.) Y (Rec.) Y (Rec.)

Grade of delivery selection

N

N (Orig)

De gebruiker is niet in staat om aan te geven of het bericht met spoed, normaal of met lage prioriteit verstuurd moet worden. Voor gewoon IPM gebruik is dit geen probleem. Voor toekomstige mail enabled applicaties mogelijk wel. Wordt bevestigd door de testen.

c

EDS, Versie 1.0

Pagina 33 van 228



Service element

UA

MAPI

opmerkingen

Conversion Prohibition

N

Y

Hiermee kan de gebruiker aangeven of automatische conversie van een bodypart door de MTA toegestaan is. In de dagelijkse praktijk momenteel geen probleem. Voor toekomstige mail enabled applicaties mogelijk wel.

Autoforwarded Indication

N

Y

Wordt bevestigd door de testen. De gebruiker is niet in staat om automatisch berichten door te sturen, dan wel als het wel mogelijk is wordt niet aangegeven dat het gebeurt. Bij ontvangst is niet te zien dat het bericht automatisch is doorgestuurd. Uit de testen blijkt dat de functie van autoforwarden wel aanwezig is, maar dat daarbij niet het service element gebruikt wordt.

Authorizing Users Indication

N

N (Orig)

Dit kan oneindige loops veroorzaken. Hiermee kan aangegeven worden wie toestemming gaf / opdracht gaf voor het versturen van een bericht. Bijvoorbeeld voor versturen middels een secretariaat. Bij het huidige IPM gebruik nog geen probleem. Zodra mail een formelere status krijgt is het element zeer gewenst. Uit de testen blijkt dat bij ontvangst er toch een vorm van ondersteuning is. De persoon in wiens naam iets verstuurd is wordt als afzender getoond.

Expiry date Indication

N

Y

Cross-referencing Indication

N

N (Orig)

Replying IP message indication

N (Orig)

Y

c

EDS, Versie 1.0

De gesignaleerde bezwaren blijven desondanks van toepassing. Hiermee kan de verzender aangeven na welke datum / tijdstip naar zijn mening het bericht niet meer geldig is. Bij het huidige IPM gebruik nog geen probleem. Bij toekomstige geautomatiseerd gebruik van Email wel belangrijk. Wordt bevestigd door de testen. De gebruiker is niet in staat om in een mail bericht te verwijzen naar de unieke bericht identificatie van andere berichten. Voor mail enabled applicaties als EPR is dit wel belangrijk. Wordt bevestigd door de testen. Hoewel de gebruiker middels de UA wel berichten kan beantwoorden, gebeurt dit niet op de standaard X.400 manier. Dat wil zeggen het protocol element dat daarvoor bedoeld is wordt niet gebruikt, evenmin als het meesturen van de identiflcatie van het originele bericht. De Microsoft UA regelt dit middels tekst in het bericht. Gewenst.

Pagina 34 van 228

Rapport

EDS



Service element

UA

MAPI

opmerkingen

R e p l y Request I n d i c a t i o n : to originator only

N (Orig)

Y

De gebruiker kan niet aangeven dat een bericht beantwoord moet worden. Dit is wel oplosbaar middels tekst in het bericht, maar dat is onbruikbaar voor automatische applicaties. Gewenst.

Body P a r t E n c r y p t i o n Indication

N

Y

De gebruiker kan niet aangeven dat het verstuurde bericht versleuteld is. Hierdoor komt een ontvanger voor verassingen te staan. Ook is niet te zien dat een ontvangen bericht versleuteld is. Dit is vreemd want Exchange ondersteunt wel versleuteld. Voor toekomstig bedrijfsmatig belangrijk verkeer is dit wel gewenst.

Multi-part

N

Y

Wordt bevestigd door de testen.

Wordt bevestigd door de testen.

Body

88 Functional groups support N

i™ Kernel f u n c t i o n a l group

N

Deze groep omvat o.a. de verplichte service elementen: A u t o f orwarded I n d i c a t i o n , E x p i r y date I n d i c a t i o n , Crossr e f e r e n c i n g I n d i c a t i o n , Body P a r t

E n c r y p t i o n I n d i c a t i o n die niet worden ondersteund (zie aldaar). De functional group is echter wel gewenst.

Iinpleiueulatie aspecten Auto-rorward

N

Y

1

Management aspecten N

uit de testen blijkt dat per connector aangegeven kan worden welke berichten over die connector verstuurd moeten worden aan de hand van de adres elementen t/m de OU's. Hoewel het instellen gebruikers vriendelijk is, is een totaal overzicht niet te verkrijgen. Controle op consistentie van de routeringsregels is daardoor lastig. Echter Exchange doet hier niet onder voor Route400.

N

uit de testen blijkt dat je wel een remote MTA kunt beheren. Er is echter geen samenhang tussen de verschillende MTA's. Consistentie controle is derhalve niet automatisch mogelijk.

flexible definition routing tables

Central

management of

rout-

ing/topology

A l t e r n a t e MTA

N

X.500 o r predecessor

N

X.500 o r predecessor + personal address book and m a i l i n g l i s t

N

f l e x i b l e maintenance of information

address

N

timing windows f o r transmission

N

wordt volgens de documentatie wel ondersteund Uit de testen blijkt dat dit een configuratie parameter is voor een verbinding.

Logs with e r r o r messages

N

Uit de testen blijkt dat er uitgebreid gelogd kan worden.

0

EDS, Versie 1.0

Pagina 35 van 228

Rapport

EDS



Logs f o r message t r a n s f e r ( s e p a r a t e d p e r c o n n e c t e d MTA ?)

N

management

N

logs/processing f o r . Accounting

N

logs f o r performance

Samenvattend kan gesteld worden dat Exchange Server niet voldoet aan het VOSIP. De afwijkingen zijn van een dusdanige aard dat gebruik voor eenvoudige Inter Personal Mail nog wel acceptabel is, al is er inconsistent gedrag afhankelijk van het feit of partners die berichten uitwisselen wel of niet Exchange gebruiken. Voor toekomstig gebruik, waarbij meer bedrijfsmatig omgegaan wordt met Email, is de ondersteuning van het VOSIP onvoldoende. Zeker als het VOSIP opgewaardeerd wordt naar de 1992 versie van de X.400 standaard.

0

EDS, Versie 1.0

Pagina 36 van 228

Rapport

EDS



8 Testen van Exchange 8.1 TJitgevoerde testen In bijlage B is het testplan opgenomen van de uitgevoerde testen in het kader van dit project. De daarbij gebruikte testomgeving is opgenomen in bijlage C. De uitgebreide omschrijving van de testen is samen met de resultaten opgenomen in bijlage F. Niet alle testen zijn uitgevoerd in het kader van dit project. Een deel van de test resultaten zijn afkomstig van eerdere testen. Deze testen zijn niet overnieuw gedaan omdat er geen reden was om aan te nemen dat de resultaten anders zouden zijn. Daar waar verwacht werd dat dit wel het geval zou zijn, zijn de testen opnieuw uitgevoerd.

8.2 Testresultaten In dit hoofdstuk worden de niet geslaagde testen en de consequenties besproken. De samenvattende resultaten van alle testen zijn te vinden in bijlage D.

Num.

Omschrijving.

Res

Samenvatting

consequenties

SR108

Test for delivery and nondelivery based on PersonalName attribute.

n

Routeren is slechts mogelijk tot en met OU's.

groot, dit betekent dat een organisatie onderdeel of als geheel Exchange moet gebruiken of in het geheel niet. Een andere mogelijkheid is dat speciale OU's ingevoerd moeten gaan worden om binnen een organisatie onderdeel te kunnen routeren.

SR203

Test blind kopie recipient indication IPM service element - single recipients.

n

Bcc veld getoond in Route400

SR203A

Test blind kopie recipient indication IPM service element - multiple recipients. Test blind kopie recipient indication IPM service element - blind kopie recipient only.

n


Groot, bij verzenden naar een X.400 bestemming wordt het BCC mechanisme niet gebruikt. Intern Exchange echter wel. Dit is inconsistent in gebruik, onbegrijpelijk voor de gebruiker en daarmee onbruikbaar voor serieus gebruik. zie SR-203

n


zie SR-203

SR203B

0

SR204

Test reply request indication service element - specifically the RepIyBy IPM heading component.

n

optie niet aanwezig

Matig, voor informed IPM gebruik niet belangrijk, voor meer bedrijfsmatig gebruik wel. N.B. men claimed in het VOSIP ondersteuning bij ontvangst, dit is echter niet het geval.

SR204A

Test reply request indication service element - specifically the ReplyToUsers IPM heading component.

n

optie niet aanwezig voor verzenden. Ontvangst wordt goed ondersteund.

Matig, voor informed IPM gebruik niet belangrijk, voor meer bedrijfsmatig gebruik wel.

EDS, Versie 1.0

Pagina 37 van 228

Rapport

EDS

Project MSXCH01 Status definitief Num.

Omschrijving.

Res

Samenvatting

consequenties

SR204B

Test reply request indication service element - specifically both Reply By and the ReplyToUsers (with multiple ORNames) IPM heading components.

n

optie niet aanwezig

Matig, voor informed IPM gebruik niet belangrijk, voor meer bedrijfsmatig gebruik wel.

SR204C

Test reply request indication service element, multiple recipients - specifically the ReplyBy IPM heading component. Test reply request indication service element, multiple recipients. Test the Replying IP-message Indication IPM service element.

n

optie niet aanwezig

zie SR-204C

n

optie niet aanwezig

zie SR-204D

n

optie niet aanwezig

Groot, voor gewoon IPM gebruik lukt hel wel. Een gebruiker ziet een en ander wel aan het subject. Voor meer bedrijfsmatig gebruik, en gebruik door applicaties is beschikbaarheid essentieel.

Test the Replying IP-message Indication and Reply Requested Indication service elements in combination. Test Cross-Referencing Indication IPM service element (single value).

n

optie niet aanwezig

zie SR-205

n

optie niet aanwezig

Test Cross-Referencing Indication IPM service element (multiple value). Test Obsoleting Indication IPM service element (single value).

n

optie niet aanwezig

Groot, voor gewoon IPM gebruik lukt het wel. Een gebruiker ziet een en ander wel aan het subject. Voor meer bedrijfsmatig gebruik, en gebruik door applicaties is beschikbaarheid essentieel. zie SR-206

n

optie niet aanwezig

Test Obsoleting Indication IPM service element (multiple values). Test Authorizing Users Indication IPM service element (multiple ORNames). Test Expiry Date Indication IPM Service Element.

n

optie niet aanwezig

n

Exchange ondersteund slechts een autorizing user.

Zie SR-208. Wordt pas nuttig als b.v. een secretariaat iets namens een directieteam verstuurd.

n

Wordt uitgaand naar X.400 en binnen Exchange wel ondersteund, bij ontvangst niet.

Groot. Voor meer bedrijfsmatig gebruik beslist gewenst.

SR204D SR205

SR205A

SR206

SR206A SR207

SR207A SR208A

SR209 SR213

c


Test Auto-forwarded Indication IPM service element (with no added text).

EDS, Versie 1.0

n

Groot, voor gewoon IPM gebruik lukt hel wel. Een gebruiker ziet een en ander wel aan het subject. Voor meer bedrijfsmatig gebruik, en gebruik door applicaties is beschikbaarheid essentieel. zie SR-207

Matig, voor een gebruiker is het minder relevant dat de functionaliteit niet conform de standaard is. Voor applicaties zal het niet snel gebruikt worden.

Pagina 38 van 228

Rapport

EDS

Project MSXCH01 Status definitief Num.

Omschrijving.

Res

Samenvatting

consequenties

SR301

Test Deferred Delivery MT service element.

n

Wordt niet conform de standaard door de MTA gedaan, maar door deUA.

SR302

Test disclosure of Other Recipients M T service element - Disclosure requested.

n

optie niet aanwezig

Matig, immers op het moment dat de gebruiker uit wil loggen kan het zijn dat de boodschap nog niet verzonden is. Dit betekend: • niet uitloggen • alsnog (te vroeg) verzenden • geheel niet verzenden Matig, wordt in de praktijk niet veel gebruikt. Bcc is veel belangrijker (zie SR203).

SR302A

Test disclosure of Other Recipients MT service element - Non-Disclosure requested.

n

optie niet aanwezig

zie SR-302

SR303

Test return of contents MT service element.

n

optie niet aanwezig

SR305

Test Conversion Prohibitation MT service element.

n

optie niet aanwezig

Matig, gebruikers zullen meestal aan subject genoeg hebben om te zien waar het om ging. Matig, momenteel voor gewoon IPM verkeer nauwelijks relevant. In de naaste toekomst bij meer bedrijfsmatig gebruik wel relevant.

SR306

Test recognition of Grade of Delivery Selection M T service element (Normal).

n

Priority is gelijk importance

SR306A

Test recognition of Grade of Delivery Selection M T service element (Urgent). Test recognition of Grade of Delivery Selection M T service element (Nonurgent).

n


Matig, momenteel voor gewoon IPM verkeer nauwelijks relevant, In de naaste toekomst bij meer bedrijfsmatig gebruik wel relevant. zie SR-306

n


zie SR-306

Matig, probe faciliteit wordt voor gewoon IPM verkeer niet of nauwelijks gebruikt. zie SR-307

SR306B

SR307

Test Probe MT service element - valid recipient.

n

SR307A SR307B

Test Probe MT service element - invalid recipient. Test Probe MT service element - invalid Encoded information type. Test Alternate Recipient Allowed/Alternate Recipient Assignment M T service elements, with Alternate Recipient assigned and Alternate Recipient Allowed specified.

n

optie niet aanwezig voor verzenden. Bij ontvangst wel correcte afhandeling. zie SR-307

n

zie SR-307

zie SR-307

n

Alternate recipient is niet te zetten voor uitgaande post, het staat altijd aan. Voor binnenkomende post wordt de functionaliteit niet ondersteund. Exchange kent wel de term alternate recipient, maar gebruikt die voor iets anders.

Matig, momenteel voor gewoon IPM verkeer nauwelijks relevant, In de naaste toekomst bij meer bedrijfsmatig gebruik wel relevant.

SR308

c


EDS, Versie 1.0

Pagina 39 van 228

Rapport

EDS



Num.

Omschrijving.

Res

Samenvatting

consequenties

SR308A

Test Alternate Recipient Allowed/Alternate Recipient Assignment MT service elements, with no Alternate Recipient assigned and Alternate Recipient Allowed specified.

n

Alternate recipient niet mogelijk

zie SR-308

SR308B

Test Alternate Recipient Allowed/Alternate Recipient Assignment MT service elements, with Alternate Recipient assigned and Alternate Recipient Allowed not specified.

n


zie SR-308

TI007

Controleer of illegale karakters per abuis in een bericht terecht kunnen komen. Studie naar continulteit en stabiliteit van leverancier. Positionering en visie achter de Email produkten.

n

SO001

AL001 AL002

onderzoeken of "rich text" ondersteund wordt. controleren of leading / trailing spaties van belang zijn bij routeren.

matig, in de praktijk niet een al te groot probleem.

x

Microsoft is een stabiel bedrijf. De visie waarmee Exchange ontwikkeld is getuigd van een duidelijk belang van messaging volgens standaarden met grote functionaliteit. Recent is de aandacht echter verlegd naar Internet. Kennis is in NL matig aanwezig.

Consequentie onduidelijk.

n

versturen lukt wel, ontvangst niet

matig, levert inconsistent gedrag op.

n

in tegenstelling tot de eisen uit de standaard zijn ze wel significant

matig, bij gebruik van goede adresboek informatie geen probleem

De consequenties van de gebreken die met groot worden aangegeven in de bovenstaande tabel kunnen als volgt worden verduidelijkt. Geen routering op Surname: Exchange kan niet berichten afleveren naar externe X.400 bestemmingen op basis van Surname. Alle Email adressen bepaald t/m de OU's horen in de optiek van Exchange thuis bij de betreffende Exchange MTA('s) verantwoordelijk voor dat domein. Als er bestemmingen zijn die buiten de betreffende omgeving (zelfde OU's maar andere Surname) liggen, kunnen berichten daarvoor niet worden afgeleverd. Dit betekent dat bijvoorbeeld Directie Noord Nederland, waar momenteel alle 6 locaties gekoppeld zijn aan de backbone, niet meer op die manier kan werken bij gebruik making van Exchange. Alleen indien additionele adres elementen ingevoerd worden 0=minvenw, OUl=rws, OU2=dnn, OU3=leeuwarden etc., kan de huidige situatie gehandhaafd blijven. Indien men niet wil overgaan op een ander naamgeving en adressering beleid,dient DNN volledig over te gaan op Exchange met maar een koppeling naar de backbone. Dit betekend dat een stuk beheer wat momenteel binnen de backbone wordt uitgevoerd dan door DNN zelf gedaan moet worden. Geen ondersteuning Blind Carbon Copy:

" EDS, Versie 1.0

Pagina 40 van 228



BCC is een mechanisme waarbij een gebruiker een bericht naar iemand stuurt en tevens een kopie naar een ander. De eigenlijke bestemming ziet dan echter niet dat iemand anders een kopie van het bericht heeft gekregen. Hoewel Exchange binnen de eigen omgeving wel het BCC mechanisme ondersteund, wordt dit naar externe X.400 bestemmingen niet ondersteund. Dit betekent dat de bestemming buiten Exchange ziet dat er een kopie naar een ander is verstuurd. Bij ontvangst van berichten van buiten ziet de Exchange ontvanger dat er een kopie is gestuurd naar een ander. Geen ondersteuning van Replying IP message indication en Cross-Referencing Indication: X.400 voorziet (evenals Exchange) in een unieke identificatie van boodschappen. Bij beantwoording van boodschappen wordt het unieke nummer van de boodschap waarop gereageerd wordt mee gestuurd. Ook kan het zijn dat een nieuw bericht verstuurd wordt dat refereert aan een eerder verstuurd bericht. Ook in dit geval kan de unieke identificatie van dat andere bericht mee gestuurd worden. Dit gebruik van de unieke identificatie wordt door Exchange niet ondersteund. Voor applicaties is dit echter een zinvolle faciliteit. Deze hoeven daarmee immers niet zelf een unieke identificatie te verzinnen en op te nemen in het onderwerp of de inhoud van het bericht. Geen ondersteuning van Obsoleting Indication en Expiry Date Indication: Middels Obsoleting Indication kan aangegeven worden dat een eerder verstuurd bericht niet meer van toepassing is. Voor aanschrijvingen van management aan medewerkers, of uitnodigingen aan de pers die niet meer van toepassing zijn is dit een zinvol feature. Dit zelfde is van toepassing voor de Expiry Date Indication, waarmee reeds bij het verzenden van een bericht aangegeven kan worden tot wanneer het bericht nog geldig is.

Samenvattend kan gesteld worden dat Exchange Server een aantal beperkingen kent. Deze bevestigen de in het VOSIP vragenformulier gesignaleerde zaken. De afwijkingen zijn van een dusdanige aard dat gebruik voor eenvoudige Inter Personal Mail nog wel acceptabel is, al is er inconsistent gedrag afhankelijk van het feit of partners die berichten uitwisselen wel of niet beide Exchange gebruiken. Voor toekomstig gebruik, waarbij meer bedrijfsmatig omgegaan wordt met Email, zijn de geconstateerde afwijkingen niet acceptabel. Tot op heden wordt de Email infrastructuur van VenW uitsluitend gebruikt voor interpersonal mail. Hoewel er centraal is vastgelegd dat Email dezelfde status heeft als een faximile bericht, zijn vrijwel alle berichten van een vrijblijvende aard. Men stuurt berichten van de volgende aard: • persoonlijke berichten • een bijlage met een besprekingsverslag of een concept van een rapport • een voorstel voor een datum en een agenda van een vergadering • etc. Vaak wordt een Email bericht daarna bevestigd middels een papieren schrijven, en worden de papieren rapporten verstuurd en gearchiveerd. Men stuurt geen berichten van de aard: • een aanschrijven dat een bepaalde dag een verplichte ATV dag is

C

EDS, Versie 1.0

Pagina 41 van 228



• een bestuurlijke mededeling dat er per datum ... een nieuwe versie van het VOSIP van kracht is • alleen nog maar per Email bijhouden en aanvragen van verlof dagen • goedkeuring verlenen aan een uitvoerend onderdeel van de organisatie om iets aan te schaffen of te beginnen met de aanleg van een weg • etc. Dit is deels nog een gevolg van onvoldoende Email awareness, maar vooral van de formele status van Email. Ten einde de formele status van Email te kunnen verhogen dient de bedrijfszekerheid, de integriteit en de flexibiliteit van het medium Email verhoogd te worden ten opzichte van de huidige status. Zo moet het bijvoorbeeld mogelijk worden dat: • hoofden / directeuren berichten af laten handelen door secretariaten. Dit dient zodanig te geschieden dat voor de ontvanger duidelijk is dat dit gebeurt en dat het bericht toch dezelfde status heeft, als was het door de directie zelf verstuurd. • mensen die met vakantie gaan hun berichten door kunnen sturen naar collega's voor afhandeling. Dit dient zodanig te geschieden dat de ontvanger kan zien dat het bericht is doorgestuurd en zowel de verzender als de ontvanger zeker weten dat het bericht niet gemodificeerd wordt doorgestuurd. • verzenders zeker weten of een bericht aangekomen is, maar ook of het tijdig en ongeschonden aangekomen is. Mocht het niet tijdig zijn aangekomen en / of gelezen dan moet de verzender hiervan op de hoogte gesteld worden. • verzenders berichten kunnen herroepen • ontvangers zeker zijn dat een bericht van een bepaalde afzender afkomstig is • berichten, indien nodig, beveiligd worden door encryptie • etc. Microsoft Exchange ondersteunt weliswaar een deel van de aangegeven faciliteiten, maar dan op een leveranciers eigen manier. Hierdoor is de functionaliteit niet beschikbaar indien gecommuniceerd wordt met bestemmingen die geen Exchange gebruiken maar bijvoorbeeld Route400. Tijdens de testen zijn nog enkele beperkingen gesignaleerd die als "bug" te kwalificeren zijn.: • spaties aan het begin of einde van bijvoorbeeld een Organisation in een X.400 adres zijn significant voor het routeren van boodschappen. Dit is uitermate hinderlijk voor de gebruiker (een tikfout met een spatie is immers snel gemaakt), maar bovendien in strijd met de standaarden. • een gewoon tekstberichtje met diacritische tekens (e etc.) gestuurd van Exchange naar een X.400 (route400) bestemming gaat goed, maar in omgekeerde richting niet. Een dergelijk bericht komt niet aan! • het herhaald doorsturen van een bericht gaat niet goed. Onder bepaalde omstandigheden kan Exchange het bericht nog wel lezen en presenteren, maar niet meer doorsturen. Tot slot is er nog de status van de leverancier Microsoft en diens positionering van Exchange. Microsoft is een stabiel bedrijf. De visie waarmee Exchange ontwikkeld is getuigt van een duidelijk belang van messaging volgens standaarden met grote functionaliteit. Recent is de aandacht van Microsoft echter verlegd naar het Internet en alles daaromheen. Voor de volgende release van Exchange heeft Microsoft koppelingen met X.500 aangekondigd, alsmede versterking van de Internet connecties. In hoe° EDS, Versie 1.0

Pagina 42 van 228

Rapport

EDS



verre dit betekend dat X.400 geen aandacht meer krijgt is onbekend. De produkt strategic van Microsoft is minder stabiel dan het bedrijf zelf. Kennis van specifieke X.400 zaken van Exchange is in Nederland matig aanwezig.

e

EDS, Versie 1.0

Pagina 43 van 228

Rapport

EDS



9 Conclusies en Aanbevelingen Conclusies Gezien: • de documentatie met daarin de plannen van Microsoft, • de faciliteiten die nu al middels MAPI geboden worden, maar nog niet via de client, kan het produkt omschreven worden als een produkt met groei potenties. Het past beter in de VenW infrastructuur dan MS-mail doet. Tevens past het beter in de infrastructuur dan WP-office (Groupwise) dit doet. Voor het gebruik op het huidige niveau (niet bedrijfskritische IPM berichten met bijlage), is het produkt goed toepasbaar. Vervanging van bestaande MS-Mail en WPoffice (Groupwise) omgevingen door Exchange omgevingen is een verbetering en derhalve aan te bevelen. Het produkt vertoont nog een aantal bugs. Deze zijn weliswaar niet van zodanige aard dat gebruik onmogelijk is, maar ze zijn wel vervelend. Voor het gebruik van Exchange is een Windows NT infrastructuur noodzakelijk die goed is opgezet. MS-DOS, MS-Windows of UNIX systemen zijn ongeschikt om als Exchange server te fungeren. Tevens vereist Exchange zware systemen als server. Dit betekend dat er op ruime schaal gei'nvesteerd moet worden. Mogelijk moeten reeds bestaande NT omgevingen opnieuw geconfigureerd worden. Er zijn nog geen User Agents voor UNIX omgevingen beschikbaar. Inzet van Exchange voor delen van een dienst onderdeel kan slechts onder zeer beperkende voorwaarden. Exchange voor een gehele dienst is mogelijk. In dat geval mag de betreffende dienst echter slechts een aansluiting op de backbone hebben onder de huidige regels voor naamgeving en adressering. Worden die regels aangepast, dan is inzet van Exchange eenvoudiger mogelijk. Exchange wordt pas optimaal ingezet als geheel VenW over gaat tot het gebruik ervan, en daarvoor een centrale beheersorganisatie opzet. Indien niet overgegaan wordt tot centraal beheer vallen een aantal van de faciliteiten van Exchange + Microsoft Office uit. Indien geheel VenW, inclusief backbone, overgaat op Exchange, dient er een separaat produkt aangeschaft te worden om faxen te versturen vanuit de backbone. Koppeling met Internet Mail kan in dit geval zonder problemen door exchange worden uitgevoerd. Naast Mail biedt Exchange ook de functionaliteit van Folders en Forms. Hiermee kunnen krachtige applicaties gerealiseerd worden. Deze functionaliteit is echter ook op andere manieren in te vullen. De functionaliteit van Microsoft Office + Route400 en gebruik makend van de voorziene Intranet faciliteiten, is vrijwel gelijkwaardig aan de combinatie Microsoft Office + Exchange. Voorwaarde is de beschikbaarheid van een correcte MAPI ondersteuning door route400. Deze is momenteel nog in ontwikkeling.

c

EDS, Versie 1.0

Pagina 44 van 228



Leverancier Microsoft is een stabiele leverancier. De status van de Office en Mail produkten is echter minder stabiel. Deze markt is nog sterk in ontwikkeling, en Microsoft probeert door voortdurende aanpassingen en verbeteringen haar positie te versterken. Dit betekend dat men rekening moet houden met een korte levensduur van de huidige produkten. Het replicatie mechanisme dat in gebruik is voor synchronisatie van Server omgevingen is niet volledig betrouwbaar. Er zijn, niet vergezochte, omstandigheden waaronder het mechanisme faalt en de gebruiker / beheerder het probleem handmatig moet oplossen. Voor een gebruik in de naaste toekomst, waarbij gedacht moet worden aan: • een herzien VOSIP met 1992 standaardisatie aspecten • een toenemend gebruik voor meer bedrijfsmatige (en bedrijfskritische) toepassingen voldoet het produkt in een gemengde Exchange / Route400 omgeving door zijn eigenschappen niet. In een volledig op Exchange gestandaardiseerde omgeving is het produkt redelijk bruikbaar.

Aanbevelingen: Indien een meer bedrijfsmatig gebruik van Email van belang geacht wordt, ga dan niet over tot de invoering van Exchange. Indien toch besloten wordt tot invoering van Exchange zorg dan: • dat de UNIX, MS-DOS en MS-Windows omgevingen migreren naar Windows NT en Windows95 omgevingen • dat er een centraal (VenW) beheerde infrastructuur komt • dat alle NT omgevingen goed op elkaar zijn afgestemd (dit kan betekenen dat op diverse locaties de NT omgeving opnieuw moet worden opgezet.). • dat er voldoende geinvesteerd wordt in de infrastructuur. Afgezien van eventuele noodzakelijke hardware en operating systeem upgrades, dient hierbij rekening gehouden te worden met 29.700,- voor de server en 14.000,- voor de werkplekken voor een organisatie van 100 personen.

° EDS, Versie 1.0

Pagina 45 van 228



Bijlage A Functionaliteit overzicht client. In deze bijlage wordt aangegeven hoe een bepaalde functionaliteit in de UA's van Route400 en Exchange geactiveerd kan worden.

Functionaliteit Folder/berichten/documenten beheer

Exchange

Route400 S.l

Nieuwe folder

File[New Folder

Intray File|New Filing Folder New Filing Cabinet

Shortcut op desktop Open Sluit Sla op Sla op als Kopieer naar Verplaats naar Afdrukken van Pagina layout Printer setup Hemoem Eigen schappen Importeer Delete Cabinet / Folder Doorsturen van bericht Beantwoord afzender Beantwoord alle iedereen Beantwoord aan distributie lijst Beantwoord met behoud van bericht aan afzender Beantwoord met behoud van bericht aan alle bestemmingen Beantwoord met behoud van bericht aan distributielijst Verbind met exteme message store Haal kopie van boodschappen op van externe message store Haal boodschappen op van externe message store Wijzig wachtwoord

File|New ShortCut File|Open

Communicatie parameters Layout Aanpassen van toolbar Gebruikers voorkeuren Automatisch verwerken van binnengekomen berichten Automatisch verwerken van binnengekomen berichten bij afwezigheid Schrijven van Post

c

EDS, Versie 1.0

File|Save File|Save As File|Copy File|Move File|Print

File|Rename File|Properties File|Import File|Delete Forward Reply To Sender Reply to All

File|Open File|Close File|Save File|Save As File|Copy Items to folder File|Move Items to folder File|Print File|Page Setup File|Print Setup Cabinet|Item properties Cabinet|Delete Item Forward Reply to Originator Reply to all recipients Reply to distribution list Reply With contents to originator

Tools|Services|Remote mail

Reply With contents to all recipients Reply With contents to distribution list Message store connect


Retreive messages (copy)


Retreive messages (move)

Tools| Servicesl Properties|Persona Options|Password 1 Folder Tools|Services|Properties|Exchan ge Server File|Design Views Tools|Customize toolbar Tools|Options Tools|Inbox assistant

Options|Connection parameters Options|Message filters Options]Tool bar Options|Preferences

Tools|Out of Office assistant

Pagina 46 van 228

Rapport

EDS

Project MSXCH01 Status definitief Functionaliteit Nieuw bericht Open bericht Voorgedefinieerde berichten laden Voorgedefinieerde berichten aanmaken Invoeren bestemming Invoeren bestemming Invoeren bestemming Invoeren bestemming Bijsluiten van bijlagen Bijsluiten van bijlagen Bijsluiten van bijlagen Bijsluiten van bijlagen Bijsluiten van bijlagen Opnieuw beginnen Enkelvoudige bestemming verwijderen Alle bestemmingen verwijderen Relateer delivery report aan verzonden bericht Verzend bericht Zend als proef Zend alle klaarstaande berichten Test op berichten Kenmerken van bericht Vraag om ontvangstbevestiging Vraag om leesbevestiging Retourneer inhoud indien niet bestelbaar Lever bericht af op tijdstip Verklaar verzonden bericht als ongeldig Leg relaties tussen berichten Vraag iedereen om antwoord Prioriteit van bericht Importance van bericht

Gevoeligheid van bericht

Registratienummer A2530#06-R-l Exchange

Route400 S.l

Compose|New message File|Open Compose|select E-form

Mail|Write File|Open File|Load Template

Compose|New form

File|Save template

To.. To... (distributionlist) To... (distributionlist) To... (distributionlist)

Recipient address File|Load mailing list File|Merge mailing list FiIe|Save mailing list File|Load text File|Attach files

Insert|File Insert|Message Insert|Object Close Windows Select, Edit|Cut

Mail|Enclosure Abandon and restart Delete recipient

Select All, Edit|Cut

Delete all recipients Correlate reports with journal

Send

Send now Send as probe Submit outtray Poll now

Tools|Deliver Now Tools|Remote Mail|Update headesr Delivery Receipt Read Receipt

Send item in .. min/hours/days

Importance (high/normal/low)

Sensitivity (confidentional/private/personal/ Normal)

Verzend lijst van bestemmingen met bericht

Reports option Delivery Reports option Receipt Reports option Contents returned by non Delivery/Receipt Dates Obsolete items Cross references Reply requested from all Priority (urgent/normal/parcel) Importance (important/normal/nonimportant) Sensitivity (confidentional/private/personal/ Normal) Disclose recipients

Bericht afleveren bij afwijkende adressering

Allow alternative recipients

Verbiedt conversie van bericht verbiedt doorsluizen van berichten

Prohibit conversion Prohibit re-assignment

Verbiedt conversie als er informatie verloren gaat Maak geen gebruik van distributielijst expansie Encrypt bericht

Prohibit Loss

c

EDS, Versie 1.0

prohibit distribution list expansion Security - encrypt

Pagina 47 van 228



Functionaliteit

Exchange

Voeg digitale handtekening toe Edit Maak ongedaan Knip Kopieer Plak Venvijder Selecteer alles Zoek naar Zoek en vervang

Security - digital signature

°EDS, Versie 1.0

Undo Cut Copy Paste Delete Select all Find Replace

Route400 5.1

Undo Cut Copy Paste Delete Select all

Pagina 48 van 228

Rapport

EDS

Project MSXCH01 Status


definitief

Bijlage B Testplan Voor het testen van Exchange dient de volgende testomgeving gebruikt te worden:

Figuur 16 Geplande proefopstelling De koppeling met de Iciml2 is gebaseerd op OSI, en niet op TCP/IP. De in het PRMD VENWTEST aanwezige Route400 MTA wordt MTA-A genoemd. De daar aanwezige exchange MTA wordt MTA-B genoemd. Op de betreffende MTA's zijn de volgende gebruikers gedefinieerd. Op MTA-A: UserlD's en X.400 O/R names User21

User22

User23

User24

User25

Country ADMD PRMD O OU1 OU2

NL 400NET VENWTEST VENWTEST ORG-A


s

TESTER-A1 A

TESTER-A1 B

NL 400NET VENWTEST VENWTEST ORG-A AFD-A TESTER-A1 A

NL 400NET VENWTEST VENWTEST ORG-A AFD-B TESTER-A2 A

NL 400NET VENWTEST VENWTEST ORG-A AFD-B TESTER-A3 B

User26

User27

User28

User29

User30

Country ADMD PRMD O OU1 OU2 OU3

NL 400NET VENWTEST VENWTEST RWS MD TI



NL 400NET VENWTEST VENWTEST DOI ORG-A

NL 400NET VENWTEST VENWTEST DOI ORG-A

'EDS, Versie

1.0

I

Pagina49 van 228

Rapport

EDS

Project MSXCH01 Status definitief OU4

s

G

I

Registratienummer A2530#06-R-l ORG-A WAYERS TOINE ARJ

ORG-A WAYERS ANTOINE ARJ

ORG-A WAYERS TOINE T

User31

User32

NL 400NET VENWTEST VENWTEST PSG ORG-A

NL 400NET VENWTEST VENWTEST RWS BD UTRECHT AZ-ORG-A SITE

T-HART ROB R 1

T-HART ROB R 2

User33

User34

User35

NL 400NET VENWTEST VENWTEST RWS


NL 4O0NET VENWTEST VENWTEST ORG-A

REDIRECT

VAKANTIE

Q

Country ADMD PRMD

0

OU1 OU2 0U3 OU4

s

BOS

G

PERSOON ARNOLD

Password voor alle users: mailtest Verkorte namen (alias/shortname etc.): bovengenoemde aanduidingen USER 15 t/m USER35. Distributielijst TESTERS-A waarop opgenomen alle bovengenoemde O/R names. Distributielijst TESTERS waarop opgenomen alle bovengenoemde O/R names en alle O/R names van MTA B.

Voor het uitwisselen van binaire fdes wordt het bodypart 14 gebruikt.

c

EDS, Versie 1.0

Pagina 50 van 228

Rapport

EDS



Op MTA-B dienen de volgende gebruikers geconfigureerd te worden: Userid's en X.400 O/R names

Country ADMD PRMD O OU1 OU2 S I

Country ADMD PRMD O OU1 OU2 OU3 OU4 S G I Q

Country ADMD PRMD O OU1 OU2 OU3 OU4 S G

Country ADMD PRMD O S G I Q

e

User21

User22

User23

User24

User25

NL 400NET VENWTEST VENWTEST ORG-B

NL 400NET VENWTEST VENWTEST ORG-B

TESTER-A1 A

TESTER-A1 B

NL 400NET VENWTEST VENWTEST ORG-B AFD-A TESTER-A1 A

NL 400NET VENWTEST VENWTEST ORG-B AFD-B TESTER-A2 A

NL 400NET VENWTEST VENWTEST ORG-B AFD-B TESTER-A3 B

User26

User27

User28

User29

User30

NL 400NET VENWTEST VENWTEST RWS MD TI ORG-B WAYERS TOINE ARJ

NL 400NET VENWTEST VENWTEST RWS MD TI ORG-B WAYERS ANTOINE ARJ

NL 400NET VENWTEST VENWTEST RWS MD TI ORG-B WAYERS TOINE T

NL 400NET VENWTEST VENWTEST DOI ORG-B

NL 400NET VENWTEST VENWTEST DOI ORG-B

T-HART ROB R 1

T-HART ROB R 2

User31

User32

User33

NL 400NET VENWTEST VENWTEST PSG ORG-B

NL 400NET VENWTEST VENWTEST RWS

BOS

NL 400NET VENWTEST VENWTEST RWS BD UTRECHT AZ-ORG-B SITE

User41

User42

User43

User44

User45

NL 400NET VENWTEST ORG-B LINCOLN ABRAHAM

NL 400NET VENWTEST ORG-B LINCOLN JOHN

NL 400NET VENWTEST ORG-B TRUMAN HARRY H

NL 400NET VENWTEST ORG-B TRUMAN HARRY X

NL 400NET VENWTEST ORG-B CLINTON BILL WJ I

EDS, Versie 1.0

PERSOON BERNARD

Pagina 51 van 228

Rapport

EDS



User46

User47

NL 400NET VENWTEST ORG-B

NL 400NET VENWTEST VENWTEST RWS BD ORG-B IEMAND

Country ADMD PRMD 0 OU1 OU2 OU3 S G 1

CLINTON BILL WJ

Q

n

Password voor alle users: mailtest Verkorte namen (alias/shortname etc.): de bovengenoemde aanduidingen USER1 t/m USER15 te worden geconfigureerd. Distributielijst TESTERS-B waarop opgenomen alle bovengenoemde O/R names. Distributielijst TESTERS waarop opgenomen alle bovengenoemde O/R names en alle O/R names van MTA A. Voor het uitwisselen van binaire fdes wordt het bodypart 14 gebruikt.

In de onderstaande tabel is aangegeven welke testen uitgevoerd dienen te worden. Deze zijn aangegeven middels VET. De niet vet gedrukte testen hoeven slechts bij problemen uitgevoerd te worden om te achterhalen wat er mis is. In principe dienen alle fases uitgevoerd te worden. Denk er bij het uitvoeren om dat de testen steeds in twee richtingen worden uitgevoerd (van A naar B en omgekeerd). Voor sommige testen is een ander PRMD noodzakelijk. Hiervoor zijn testers in het Icim domein gebruikt.

De testen zijn verdeeld over zes fasen. Na elke fase kan worden bepaald of het zinvol is om door te gaan met testen. De fasen die doorlopen worden zijn ook afhankelijk van het type produkt dat getest moet worden. Fase 1: Fase 2: Fase 3: Fase 4: Fase 5: Fase 6:

C

bevat testen die gedurende de voorselectie en installatie van een produkt uitgevoerd kunnen worden. bevat de testen die als oplevertesten voor een produkt kunnen dienen. bevat testen op het gebied van gebruikersaspecten. Deze testen worden alleen uitgevoerd bij produkten die geschikt zijn als eindpunt MTA. bevat testen om algemene functionaliteit van produkten te bepalen, die geschikt zijn als eindpunt en/of knooppunt MTA bevat testen om relay-functionaliteit te bepalen voor produkten die geschikt zijn als knooppunt MTA. bevat overige EurOSInet testen die niet in de vorige fasen aan de orde zijn gekomen.

EDS, Versie 1.0

Pagina 52 van 228


Registratien u m m e r A2530#06-R-l

Voor produkten die alleen geschikt zijn als eindpunt MTA worden de fasen 1,2,3,4 en 6 doorlopen. Voor produkten die alleen geschikt zijn als knooppunt MTA worden de fasen 1,2,4,5 en 6 doorlopen. Voor produkten die geschikt zijn om zowel de eindpunt als knooppunt functie te vervullen, worden alle fasen doorlopen. In onderstaande tabellen is beschreven welke testen in welke fase worden uitgevoerd. Elke fase bevat een of meer elemenataire testen die uitgevoerd moeten worden. Deze testen zijn vet gedrukt. De niet-vet afgedrukte testen zijn afhankelijke testen, d.w.z. testen die uitgevoerd worden als het resultaat van een elementaire test onduidelijk is. Het testen van een 'slecht' produkt kost dus meer tijd dan het testen van een 'goed' produkt. Bij elke test is aangegeven uit welke EurOSInet en/of aanvullende VOSIPtesten de test is samengesteld.

° EDS, Versie 1.0

Pagina 53 van 228

Rapport

EDS



definitief

FASE 1 TEST

:

Gedurende de voorselectie en installatie

AFHANKELIJKHEID

EUROSINET/VOSIP

101

SO-001

102

SI-001

103

SI-002

104

SI-003

105

SI-004

106

TI-001 (slechts middels documentatie)

107

CI-004

108

CI-002

109

CI-003, CI-005, SR-001

110

104

CI-006

111

105

CI-008

Toelichting op de tabel kolom TEST:

Icim testnummer, opgebouwd uit een cijfer welke de fase weergeeft en een twee cijferig volgnummer. kolom AFHANKELIJKHEID: De resultaten van de test in deze kolom bepalen of de test in genoemd in de TEST-kolom uitgevoerd moet worden. kolom EUROSINET/VOSIP: Verwijzing naar de oude testen in het testplan (TI1992-1061), waaruit de nieuwe test is samengesteld.

e

EDS, Versie 1.0

Pagina 54 van 228

Rapport

EDS

Project MSXCH01 Registratienummer A2530#06-R-l

Status definitief

FASE 2 TEST

AFHANKELIJKHEID

Gedurende de oplevering EUROSINET/VOSIP

SR-002, SR-004, SR-005, SR-101, SR-102, SR103, SR-312A, SR-214A, TI-002A, CI-007, C O 003

201

C

:

202

201

SR-003

203

201

SR-309

204

201

SR-310B

205

201

SR-311

205A

201

SR-311A

205B

201

SR-311B

206

201

SR-312

207

201

SR-214

EDS, Versie 1.0

Pagina 55 van 228

Rapport Project MSXCH01 Status


definitief

FASE 3

:

TEST

c

Testen gebruikersaspecten

AFHANKELIJKHEID

EUROSINET/VOSIP

301

LM-001, LM-002, LM-003, L.M-004

302

CI-001

303

TI-004

304

11-005

305

TI-006

306

CI-009

307

TI-007

308

CO-004

309

301

LM-001

310

301

LM-002

311

301

LM-003

312

301

LM-004

EDS, Versie 1.0

Pagina 56 van 228



FASE 4

:

TEST

c

Testen MTS en service elementen

AFHANKELIJKHEID

EUROSINET/VOSIP

401

SR-108

402

SR-104A, SR-105A, SR-109, SR-110

403

SR-217, SR-204B, SR-204D, SR-306B

404

SR-210B, SR-213

405

RT-001, RT-002, RT-003, RT-006, RT-007, RT009

406

RT-004

407

RT-005

408

RT-008

409

RT-010

410

401

SR-107C

411

410

SR-107B

412

411

SR-107A

413

412

SR-107

414

413

SR-106

415

402

SR-104

415A

402

SR-104B

416

402

SR-105

417

402

SR-109 A

418

403

SR-201

419

403

SR-202

419A

403

SR-202A

419B

403

SR-202B

420

403

SR-203

420A

403

SR-203A

420B

403

SR-203B

EDS, Versie 1.0

Pagina 57 van 228



421

403

SR-204

421A

403

SR-204A

422

403

SR-205

422A

403

SR-205A

423

403

SR-206A

424

403

SR-207A

425

403

SR-208A

426

403

SR-209

427

403

SR-211

427A

403

SR-211A

427B

403

SR-2UB

428

403

SR-212

428A

403

SR-212A

428B

403

SR-212B

428C

403

SR-212C (=SR-2UC)

429

403

SR-215

429A

403

SR-215A

430

403

SR-216

430A

403

SR-216A

431

403

SR-306A

431A

403

SR-306

432

404

SR-210

432A

404

SR-210A

433

405

RT-001

434

405

RT-002

435

405

RT-003

436

405

RT-006

437

405

RT-007

438

405

RT-009

° EDS, Versie 1.0

Pagina 58 van 228

Rapport

EDS



FASE 5

:

Testen knooppunt MTA

Deze testen hoeven alleen uitgevoerd te worden als het produkt geschikt is om als knooppunt MTA te functioneren. Let er op dat het produkt in deze testen als relay station gebruikt moet worden en niet als initiator. TEST

AFHANKELIJKHEID

EUROSINET/VOSIP

551

RL-001, RL-001A

552

RL-003A, RL-004A, RL-005, RL-006A, RL-007, RL-008

553

RL-010A

554

TO-001

555

TO-002

556

CO-001

557

CO-002

558

552

RL-002

559

552

RL-002A

560

552

RL-003

561

552

RL-004

562

552

RL-006

563

553

RL-009A

564

563

RL-009

565

553

RL-010

Test 551 is niet altijd uitvoerbaar (n.a.u.), maar is voor de volledigheid van de testset opgenomen.

c

EDS, Versie 1.0

Pagina 59 van 228

Rapport

EDS



FASE 6 TEST

c

AFHANKELUKHEID

:

Wrap-up-testen EUROSINET/VOSIP

601

SR-301

602

SR-302A

603

SR-303

604

SR-304

605

SR-305

606

SR-307, SR-307A

607

SR-307B

608

SR-308

609

SR-308B

610

602

SR-302

611

608,609

SR-308A

612

602

TI-003

EDS, Versie 1.0

Pagina 60 van 228

Rapport

EDS


Bijlage C


Gebruikte testomgeving

Voor het uitvoeren van de test is uiteindelijk een iets andere test omgeving gebruikt dan in het testplan was opgenomen. De omgeving was opgezet volgens:

Figuur 17 Gebruikte testopstelling De routering in de test opstelling hing af van de uitgevoerde test. Voor het merendeel van de testen werden de berichten van OU=ORG-A naar O U O R G - B en vice versa gerouteerd via de ICIM01 middels de RFC 1006 (TCP/IP) lower layer verbinding. Voor enkele testen werden de berichten van OU=ORG-A naar OU=ORG-B en vice versa rechtstreeks tussen betreffende MTA's uitgewisseld middels RFC 1006 (TCP/IP). Voor enkele testen werden de berichten vanuit OU=ORG-B via de iciml2 gerouteerd middels een CLNS (TP4) verbinding. Voor enkele zeer specifieke testen (Exchange naar Exchange via X.400) werd gebruik gemaakt van het feit dat er een tweede Exchange omgeving beschikbaar was. Deze was echter niet vrij inzetbaar voor de testen en dus slechts beperkt gebruikt worden.

° EDS, Versie 1.0

Pagina 61 van 228



Bijlage D Samenvatting testresultaten In deze bijlage zijn de resultaten van alle testen kort samengevat. Toelichting Een samenvatting van de resultaten van de uitgevoerde testen volgt hierna in tabelvorm. Uitgebreide testresultaten staan in bijlage , daar waar ook de testen in detail zijn uitgewerkt. De testen zijn of in het verleden in het kader van eerdere onderzoeken uitgevoerd op de Beta versie van Exchange, of in het kader van het onderhavige project op de productie versie van Exchange. In lijn met het testplan worden de formulieren gesorteerd in de volgende testcatagorien: SR - Send/Receive tests, De vier groepen van testen controleren respectievelijk de X.400 basisfuncties, de (foutieve) adresseringsmogelijkheden/gevolgen, de UA services en de MTA services. L M - Limitation tests, Testen om grenswaarden te controleren, bijvoorbeeld maximum aantal te adresseren personen, lengte van velden etc. RT - Reliable transfer tests Test opbouw/verbreken verbinding tussen MTA's en betrouwbare transport berichten in het algemeen RL - Relay tests, Hierbij zijn minimaal drie MTA's betrokken, met name twee verschillende potentiele Eindpunt MTA's en een potentiele Knooppunt MTA of een Eindpunt MTA en twee Knoop/Service punt MTA's. incl. routing van berichten loopdetectie etc. TI - Implementatie testen, Hierbij worden een aantal aspecten van de manier waarop het produkt geimplementeerd is getest. CI - Implementatie Controle, Hierbij worden een aantal functionaliteiten van het produkt, niet direct gerelateerd aan X.400 service elementen gecontroleerd. SI - Implementatie Studie, Hierbij worden een aantal functionaliteiten aan de hand van documentatie onderzocht. A L - Algemene zaken, Hierin worden nog een aantal aspecten die in de overige testen niet aan bod zijn gekomen afgehandeld.

c

EDS, Versie 1.0

Pagina 62 van 228

Rapport

EDS

Project MSXCH01 S t a t u s


definitief

In de tabel zijn de volgende kolommen te vinden: • Het nummer van de test (num.). Dit is opgebouwd uit de code (SR) plus een volgnummer. • Een korte omschrijving van de test (oms.). De volledige beschrijving is te vinden in de bijlage. • Het resultaat van de test (res.). Een n geeft aan dat de test niet geslaagd is, een j * geeft aan dat de test geslaagd is met een 'kleine' afwijking van het ideale resultaat. Een - geeft aan dat de test in de testomgeving niet uitgevoerd kon worden. Deze testen zijn tevens middels een lichtte arcering geaccentueerd. • Een korte samenvatting van de belangrijkste test resultaten (samenvatting). • De consequenties voor het gebruik binnen Verkeer en Waterstaat (consequenties). Met een zware arcering wordt aangegeven dat de test bewust niet uitgevoerd is in het kader van het project omdat dit weinig tot geen toegevoegde waarde zou hebben, dan wel teveel inspanning zou kosten binnen de beperkte opdracht.

1 Bnum

1

Oms.

Res

Samenvatting

consequenties

SR001

Test message delivery to a single recipient

j*

De velden from, to en subject niet ingevuld. (Unknown)

onhandig, maar verder geen probleem

SR002

Test message non-delivery to a single recipient. Nondelivery is due to an invalid O/R attribute value.

j

Test message delivery to multiple recipients at the same destination MTA.

j*



Test message delivery to multiple recipients at different destination MTA's. Test message delivery to local and remote recipients. Test message delivery based on valid surname.

j*



j*





I 003 SR004 SR005 SR101 cn

i>R102 SR103 CD

5>R104 CD

104 A CD

6R104B

C

Test message non-delivery based on invalid surname. Test message based on completely specified PersonalName. Test message non-delivery based on ambiguous Surname.

j j j*

j

Test message non-delivery based on ambiguous Givenname.

j

Test message non-delivery based on ambiguous Initials.

j

EDS, Versie 1.0

.

Pagina 63 van 228

Rapport

EDS

Project MSXCH01 Status definitief Bnum

Oms.

Res

SR105

Test Message Transfer System respons to an overspecified ORName (overspecified with givenname).

j

Test Message Transfer System respons to an overspecified ORName (overspecified with initials). Test message delivery based on Organization Name Attribute. Test message delivery based on Organizational Unit attribute. Test message delivery based on two Organizational Unit attributes. Test message delivery based on three Organizational Unit attributes. Test message delivery based on four Organizational Unit attributes. Test for delivery and nondelivery based on PersonalName attribute. Test the ability of the Message Transfer System to use the Initials attribute in the name discrimination. Test the ability of the Message Transfer System to use the GenerationQualifier attribute in the name discrimination. Test message non-delivery based on invalid PRMD.

j

fl SR105A

SR106 SR107 SR| 107A SR107B SR107C SR108 SR109

SR109A

SR110 SR201 SR202 SR202A SR202B

e


Test the originator indication IPM service element. Test the primary and kopie recipients IPM service element - single recipients. Test the primary and kopie recipients IPM service element - multiple recipients. Test the primary and kopie recipients IPM service element - kopie recipient only.

EDS, Versie 1.0

Samenvatting

consequenties

Routeren is slechts mogelijk tot en met OU's.

groot, dit betekent dat een organisatie onderdeel of als geheel Exchange moet gebruiken of in het geheel niet.

j

j

j

j

j

n

j

j

j j j

j

j

Pagina 64 van 228

Rapport

EDS



definitief

Bnum

Oms.

Res

Samenvatting

consequenties

SR203

Test blind kopie recipient indication IPM service element - single recipients.

n


SR203A

Test blind kopie recipient indication IPM service element - multiple recipients. Test blind kopie recipient indication IPM service element - blind kopie recipient only.

n


Groot, bij verzenden naar een X.400 bestemming wordt het BCC mechanisme niet gebruikt. Intern Exchange echter wel. Dit is inconsistent in gebruik, onbegrijpelijk voor de gebruiker en daarmee onbruikbaar voor serieus gebruik. zie SR-203

n


zie SR-203

SR203B

SR204

Test reply request indication service element - specifically the ReplyBy IPM heading component

n

optie niet aanwezig

Matig, voor informed IPM gebruik niet belangrijk, voor meer bedrijfsmatig gebruik wel. N.B. men claimed in het VOSIP ondersteuning bij ontvangst, dit is echter niet het geval.

SR204A

Test reply request indication service element - specifically the ReplyToUsers IPM heading component. Test reply request indication service element - specifically both ReplyBy and the ReplyToUsers (with multiple ORNames) IPM heading components.

n

optie niet aanwezig voor verzenden. Ontvangst wordt goed ondersteund.

Matig, voor informeel IPM gebruik niet belangrijk, voor meer bedrijfsmatig gebruik wel.

n

optie niet aanwezig

Matig, voor informeel IPM gebruik niet belangrijk, voor meer bedrijfsmatig gebruik wel.

n

optie niet aanwezig

zie SR-204C

n

optie niet aanwezig

zie SR-204D


SR204B

SR204C

SR204D SR205

Test the Replying IP-message Indication IPM service element.

n

optie niet aanwezig

SR205A

Test the Replying IP-message Indication and Reply Requested Indication service elements in combination. Test Cross-Referencing Indication IPM service element (single value).

n

optie niet aanwezig

n

optie niet aanwezig

n

optie niet aanwezig

SR206

SR206A

0

Test reply request indication service element, multiple recipients - specifically the ReplyBy IPM heading component. Test reply request indication service element, multiple recipients.

Test Cross-Referencing Indication IPM service element (multiple value).

EDS, Versie 1.0


Pagina 65 van 228

Rapport

EDS

Project MSXCH01

Status

Registratienummer

definitief

A2530#06-R-l

I Bnum

Oms.

Res

Samenvatting

consequenties

SR207

Test Obsoleting Indication IPM service element (single value).

n

optie niet aanwezig

SR207A

Test Obsoleting Indication IPM service element (multiple values). Test Authorizing Users Indication IPM service element (single value).

n

optie niet aanwezig


j*

Niet herkenbaar als authorised message van en naar X.400. Binnen Exchange ondersteund middels tekst in envelop. Exchange ondersteund slechts een autorizing user.

SR208

SR208A

Test Authorizing Users Indication IPM service element (multiple ORNames). Test Expiry Date Indication IPM Service Element.

n

Test Forwarded IP-message Indication IPM service element (with no added text). Test Forwarded IP-message Indication IPM service element (with added text).

j

Test Forwarded IP-message Indication IPM service element (multiple forwarding).

j*

SR211

Test Importance Indication IPM service element (Normal).

j

SR211A SR21 IB SR211C

Test Importance Indication IPM service element (High). Test Importance Indication IPM service element (Low). Test Importance Indication IPM service element (unspecified). Test Sensitivity Indication IPM service element (Personal). Test Sensitivity Indication IPM service element (Private). Test Sensitivity Indication IPM service element (CompanyConfidential).

j

SR209 SR210 SR210A

SR210B

SR212 SR212A SR212B

c

EDS, Versie 1.0

n

j*

Matig, voor gewoon IPM gebruik geen probleem. Voor meer bedrijfsmatig gebruik is beschikbaarheid gewenst. Zie SR-208. Wordt pas nuttig als b.v. een secretariaat iets namens een directieteam verstuurd.

Wordt uitgaand naar X.400 en binnen Exchange wel ondersteund, bij ontvangst niet.

Groot. Voor meer bedrijfsmatig gebruik beslist gewenst.

Exchange forward niet middels een additioneel bodypart voor de toegevoegde tekst, maar middels modificatie van het bestaande IA5 bodypart. Bij herhaald forwarden gaat het

Matig, menselijke gebruikers zien het wel (al bestaat de mogelijkheid dat het originele bericht aangepast wordt), en voor applicaties zal dit niet snel gebruikt worden. Matig, in de praktijk zal zo vaak herhaald forwarden niet snel voorkomen.

soms bij het versturen vanuit Exchange fout met een "contains a content type that is not supported " foutmelding.

j j*

unspecified kan niet gezet worden

Geen, dit gedrag wordt door vele pakketten vertoond en is in dagelijks gebruik niet relevant.

j

j

j

Pagina 66 van 228

Rapport

EDS

Project MSXCH01 Status definitief Bnum

Oms.

SR213

Test Auto-forwarded Indication IPM service element (with no added text).

SR214

Test Multi-Part Body IPM service element (two bodyparts of the same type).

SR214A

Test Multi-Part Body IPM service element (two bodyparts of different types). Test Receipt Notification IPM service element (no Delivery Notification). Test Receipt Notification IPM service element (in combination with Delivery Notification).

SR215 SR215A

SR216

SR217

Test Non-Receipt Notification IPM service element (non Delivery Notification). Test Non-Receipt Notification IPM service element (in combination with Delivery Notification). Test multiple IPM service elements in combination.

SR218 SR301

Test Subject Indication service element. Test Deferred Delivery MT service element.

SR302

Test disclosure of Other Recipients MT service element - Disclosure requested. Test disclosure of Other Recipients MT service element - Non-Disclosure requested.

SR216A

SR302A

SR303

C

Test return of contents MT service element.

EDS, Versie 1.0

Registratienummer A2530#06-R-l Res

Samenvatting

consequenties

Matig, voor een gebruiker is het minder relevant dat de functionaliteit niet conform de standaard is. Voor applicaties zal het niet snel gebruikt worden. Bij verzenden geen mogelijkheid voor meerdere IAS bodyparts.

Nauwelijks, gebruikers zullen niet snel meerdere IA5 bodyparts nodig hebben. Voor applicaties zullen doorgaans andere bodyparts gebruikt worden.



j*



j*

Voorzover de individuele elementen ondersteund worden, wordt ook een combinatie ondersteund.

j*

Wordt niet conform de standaard door de MTA gedaan, maar door deUA.

optie met aanwezig

Matig, immers op het moment dat de gebruiker uit wil loggen kan het zijn dat de boodschap nog niet verzonden is. Dit betekend: niet uitloggen alsnog (te vroeg) verzenden geheel niet verzenden Matig, wordt in de praktijk niet veel gebruikt. Bcc is veel belangrijker (zie SR203).

optie met aanwezig

zie SR-302

optie niet aanwezig

Matig, gebruikers zullen meestal aan subject genoeg hebben om te zien waar het om ging.

Pagina 67 van 228

Rapport

EDS

Project MSXCH01 Status definitief Oms.

Res

Samenvatting

consequenties

SR305

Test Conversion Prohibitation M T service element

n

optie niet aanwezig

SR306

Test recognition of Grade of Delivery Selection MT service element (Normal).

n


SR306 A

Test recognition of Grade of Delivery Selection MT service element (Urgent). Test recognition of Grade of Delivery Selection MT service element (Nonurgent). Test Probe MT service element - valid recipient.

n


Matig, momenteel voor gewoon IPM verkeer nauwelijks relevant In de naaste toekomst bij meer bedrijfsmatig gebruik wel relevant. Matig, momenteel voor gewoon IPM verkeer nauwelijks relevant, In de naaste toekomst bij meer bedrijfsmatig gebruik wel relevant. zie SR-306

n


zie SR-306

n

Test Probe MT service element - invalid recipient. Test Probe MT service element - invalid Encoded information type. Test Alternate Recipient Allowed/Alternate Recipient Assignment MT service elements, with Alternate Recipient assigned and Alternate Recipient Allowed specified. Test Alternate Recipient Allowed/Alternate Recipient Assignment MT service elements, with no Alternate Recipient assigned and Alternate Recipient Allowed specified. Test Alternate Recipient Allowed/Alternate Recipient Assignment MT service elements, with Alternate Recipient assigned and Alternate Recipient Allowed not specified. Test Multi-Destination Delivery MT service element. Test Delivery Notification MT service element - mixed valid Primary and CC: Recipients. Test Delivery Report Notification MT service element - single invalid Primary Recipient.

n

optie niet aanwezig voor verzenden. Bij ontvangst wel correcte afhandeling. zie SR-307

Matig, probe faciliteit wordt voor gewoon IPM verkeer niet of nauwelijks gebruikt. zie SR-307

n

zie SR-307

zie SR-307

n

Matig, momenteel voor gewoon IPM verkeer nauwelijks relevant, In de naaste toekomst bij meer bedrijfsmatig gebruik wel relevant.

n

Alternate recipient is niet te zetten voor uitgaande post, het staat altijd aan. Voor binnenkomende post wordt de functionaliteit niet ondersteund. Exchange kent wel de term alternate recipient maar gebruikt die voor iets anders. Alternate recipient niet mogelijk

n


zie SR-308

1 Bnum

SR306B

SR307 SR307A SR307B SR308

SR308A

SR308B

SR309 SR310B

SR311

c


EDS, Versie 1.0

zie SR-308

j j

j

Pagina 68 van 228

Rapport

EDS

Project MSXCH01 Status definitief | Bnum

RL004 RL004A

RL006 RL006A

RL

I" 8I " RL

008

RL009 RL009A RL010 RL010A RT001

RT003 RT004 RT005 RT006


Oms.

Res

Test Relay (PRMD-PRMD) of a single Non- Delivery Notification. Test Relay (PRMD-PRMD) of multiple Non- Delivery Notifications.

j

Test Relay (PRMD-PRMD) of a single Receipt Notification. Test Relay (PRMD-PRMD) of multiple Receipt Notifications. Test Relay (PRMD-PRMD) of Receipt and Non-Receipt Notifications. Test Relay (PRMD-PRMD) of Receipt and Delivery Notifications. Test MTA for Inter-MD loop detection - single recipient. Test MTA for Inter-MD loop detection - multiple recipients. Test MTA for intra-PRMD loop detection - single recipient. Test MTA for intra-PRMD loop detection - multiple recipients. Test recovery following session suspension.

Test ability to send multiple messages in one session connection. Test ability to detect an invalid MTA name. Test ability to detect an invalid MTA password. Test ability to handle multiple messages from both partners simultaneously and avoid "collisions".

° EDS, Versie 1.0

Samenvatting

consequenties

j

j

j

j

j

j j

j

j

j

j

j j j

Pagina 70 van 228

Rapport

EDS



Bnum

Oms.

Res

SR311A

Test Delivery Report Notification MT service element - multiple invalid Primary Recipient.

j

SR31 IB

SR-311B Test Delivery Report Notification MT service element - mixed invalid Primary and CC: Recipients.

j

SR312

Test Delivery Notification MT service element - mixed valid/invalid Primary Recipients.

j

Test Delivery Notification MT service element - mixed valid/invalid Primary and CC: Recipients. L M - Test maximum lenght ORName attribute values. 001 LMTest maximum body lenght. 002 LMTest message delivery to many recipients. 003 LMTest maximum subject lenght. 004

j

SR312A

1

RL002

RL002A

RL003

RL003A

c

Test Relay (PRMD-PRMD) of a single message - valid ORName - with no Delivery Notification requested. Test Relay (PRMD-PRMD) of multiple messages - valid ORName - with no Delivery Notification requested. Test Relay (PRMD-PRMD) of a single message - valid ORName - with Delivery Notification requested and relay of Delivery Notification. Test Relay (PRMD-PRMD) of multiple messages - valid ORName - with Delivery Notification requested and relay of Delivery Notification.

EDS, Versie 1.0

Samenvatting

consequenties

j j

50 Mb succesvol

j j

j

j

j

j

Pagina 69 van 228

Rapport

EDS

Project MSXCH01

Status

Registratienummer

definitief

A2530#06-R-l

CI002

CI003

CI004

CI

1" 005

Controleren of de implementatie naamgeving ondersteund zoals deze werd opgesteld in beleidsonderzoek naamgeving en adressering. Controleren of NSAP adresstructuur omschreven in het profiel wordt ondersteund. Controleren of diverse relevante OSI communicatie parameters opgenomen in het profiel kunnen worden ingesteld in het produkt. Controleren hoe eenvoudig de route die een bericht aflegt, van bron naar bestemming uit de routeregels kan worden afgeleid en kan worden geconfigureerd.

°EDS, Versie 1.0

j*

Deels bepaald aan de hand van configuratie mogelijkheden en documentatie, deels middels testen.

j*

Deels bepaald aan de hand van configuratie mogelijkheden en documentatie, deels middels testen.

j

N

Slechts per aangesloten MTA te controleren.

Vergeleken met Route400 heeft Exchange dezelfde mogelijkheden.

Pagina 71 van 228

Rapport

EDS

Project MSXCH01 Status definitief 1 Bnum

Oms.

Res

Samenvatting

consequenties

SI002

Vaststellen op welke operating systems het Email produkt functioneert. Zowel voor de U A als de MTA. Nu en op de korte termijn.

X

MTA alleen onder Windows NT, UA onder MS-DOS, Windows, Windows95 en Windows NT. UA's voor een aantal UNIX platformen zijn aangekondigd.

Niet alle OS platformen van VenW worden ondersteund.

SI003

Implementatie studie, P3-link UA-MTA

j

Implementatie controle document formaten/bodyparts Implementatie studie, transport profiel PI-link MTAMTA

j

\ci007 SI004

j

TI006

Test of de UA over de mogelijkheid beschikt van een eigen adressenlijst (O/Rname formaat) en hoe de adressen hierin worden bijgewerkt en up to date blijven.

J

CI009

Controleer of de UA over de mogelijkheid beschikt om een bericht automatisch, op regelmatige tijdstippen te verzenden.

N

Geen, ook Route400 ondersteund deze mogelijkheid niet

TI007

Controleer of illegale karakters per abuis in een bericht terecht kunnen komen. Studie naar continui'teit en stabiliteit van leverancier. Positionering en visie achter de Email produkten.

n

matig, in de praktijk niet een al te groot probleem.

SO001

1 TO001

002

c


Test van operationeel aspect; beheer aspecten, routering en uitwijken.

X

Dubbelklikken is positief gewaardeerd.

Microsoft is een stabiel bedrijf. De visie waarmee Exchange ontwikkeld is getuigd van een duidelijk belang van messaging volgens standaarden met grote functionaliteit. Recent is de aandacht echter verlegd naar Internet. Kennis is in NL matig aanwezig.

Geen, ook Route400 ondersteund deze mogelijkheid niet. Op zich biedt de adreslijst redelijke faciliteiten.

Consequentie onduidelijk.

j

Controle van operationeel aspect; beheer aspecten, logs. Controle van < operationeel aspect; overige beheer aspecten.

EDS, Versie 1.0

Pagina 72 van 228

Rapport

EDS



Bnum

Oms.

Res

CO003

Controle van operationeel aspect; performance

j

CO004

Toets van de meest minimale beveiligingswensen in afwachting van de volledige 1988 implementatie. onderzoeken of "rich text" ondersteund wordt. controleren of leading / trailing spaties van belang zijn bij routeren.

j

AL001 AL002

c

EDS, Versie 1.0

consequenties

naast normale toegangsbeveiliging, zijn er voor boodschappen propriarty oplossingen

n

—

Samenvatting

versturen lukt wel, ontvangst niet

matig, levert inconsistent gedrag op.

in tegenstelling tot de eisen uit de standaard zijn ze wel significant

matig, bij gebruik van goede adresboek informatie geen probleem

—_j

Pagina 73 van 228

Rapport

EDS



Bijlage E Functies Mail client Hieronder is een tabel opgenomen waar op hoofdpunten het verschil in functionaliteit is vastgelegd voor de diverse combinaties van Email UA en MTA voor Microsoft Mail 3.x en Exchange Server.

E-mail HtnctionaMy

Tool Tips Rich-text support

•i

BCC support

•i

Auto reply

•i

Rules

•i

Inbox Assistant Out of Office Assistant Information exchange

Access to public folders

•i

Flexible views Delegate access Remote functionality Offline folder synchronization Rich searches Group scheduling

V

Customizable views Printing

«

Remote access Forms development tools

Easy-to-use forms Central forms registry OLE

c

EDS, Versie 1.0

Pagina 74 van 228

Rapport

EDS

Project MSXCH01

Status

Registratienummer

definitief

A2530#06-R-l

Bijlage F X.400 testset resultaten Deze bijlage bevat de ingevulde resultaten van de uitgebreide testen uitgevoerd met Microsoft Exchange in combinatie met Route400 onder Windows NT. De testset is ontwikkeld in het kader van het X400PROD project voor de Meetkundige Dienst vai Rijkswaterstaat en grotendeels gebaseerd op de Eurosinet interoperability testen. De testset is gericht op 84/88 systemen. Dat wil zeggen er zijn geen testen aanwezig om de 1992 en nieuwere features te testen.

De testen op de volgende bladzijden zijn allemaal op de volgende manier opgebouwd: Activiteitnummer:

XX-nnn

Categorie:

korte omschrijving categorie van de test.

Doel:

korte beschrijving van het doel van de test.

Prioriteit:

de prioriteit van de test, A = hoog, B = middel, C = laag

Noodzakelijke ondersteuning: mate van ondersteuning die nodig is van een X.400 OSI standaardisatie deskundige op een schaal van 0 - 10, 0= niet, 10= volledig. Werkwijze:

een beschrijving van de uit te voeren werkzaamheden.

Verwacht resultaat:

een beschrijving van het te verwachten resultaat.

Gevonden resultaat: hier moeten de gevonden resultaten beschreven worden, geef o.a. omschrijving verschijnselen, gebruiksgemak, configuratie inspanningen, en verder verschillen tussen de UA's, gaf de gevolgde werkwijze problemen en zo ja waar etc.

Een gedeelte waarin aangekruist kan worden of de test: • mislukt is • geslaagd is •

of geslaagd is met een geringe/onverwachte afwijking van het te verwachten sultaat

TEST GESLAAGD: () NEE ( ) JA, ZONDER KANTTEKENING () JA, M A A R M E T DE VOLGENDE KANTTEKENING: Een bondige samenvatting van de geconstateerde afwijking van de te verwachten resultaten.

° EDS, Versie 1.0

Pagina 75 van 228



Activiteitnummer: Categorie:

SR-001

Send/Receive

Doel: Test message delivery to a single recipient Prioriteit: A Noodzakelijke ondersteuning: 0 Werkwijze: 1.

Originator creates a message to one valid remote X.400 Primary recipient.

2.

Originator sends the message with Delivery Notification requested.

Verwacht resultaat: Originator should receive a Delivery Notification for this test message. Gevonden resultaat: Exchange naar Route400: Delivery notification ontvangen, echter de messagebody bevat de niet ingevulde regels: To: Unknown Subject Unknown Sent: Unknown Als de test uitgevoerd wordt naar een Exchange bestemming zijn deze velden wel ingevuld. Route400 naar Exchange: Delivery notification ontvangen

Opmerking 1: van een remote X.400 locator kan aan gegeven worden of het een Mapi client is of niet. Staat dit aan dan wordt er altijd een binaire bijlage (msmail.dat) mee gestuurd met het bericht Staat het uit dan wordt dit niet gedaan. Opmerking 2: adres componenten moeten zonder voor of naloop spaties worden ingevuld anders vindt geen aflevering plaats. Hoewel de X.400 standaard stelt dat voor en naloop spaties niet significant zijn voor routeren, maakt Exchange wel verschil. TEST GESLAAGD: ()NEE ( ) JA, ZONDER KANTTEKENING (x) JA, MAAR MET DE VOLGENDE KANTTEKENING: Niet alle velden worden goed ingevuld., spaties.

c

EDS, Versie 1.0

Pagina 76 van 228

Rapport Project MSXCH01 Status definitief Activiteitnummer:

Registratienummer A2530#06-R-l SR-002

Categorie: Doel: Test message non-delivery to a single recipient. Non-delivery is due to an invalid O/R attribute value. Prioriteit: A Noodzakelijke ondersteuning: 0 Werkwijze: 1. Originator creates a message to one invalid remote X.400 Primary recipient. The Surname attribute should be invalid (i.e., indicate a non-existent user). 2. Originator sends the message - does not request a Delivery Notification.

Verwacht resultaat: Originator should receive a Non-Delivery Notification (due to Unrecognized ORName) for this test message. Gevonden resultaat: Exchange naar Route400: Non-Delivery notification ontvangen Route400 naar Exchange: Non-Delivery notification ontvangen

TEST GESLAAGD: () NEE (x) JA, ZONDER KANTTEKENING ( ) JA, MAAR MET DE VOLGENDE KANTTEKENENG:

c

EDS, Versie 1.0

Pagina 77 van 228



Activiteitnummer:

SR-003

Categorie: Doel: Test message delivery to multiple recipients at the same destination MTA. Prioriteit: A Noodzakelijke ondersteuning: 0 Werkwijze: 1. Originator creates a message to two valid remote X.400 Primary recipients. 2. Originator sends the message with Delivery Notification.requested. Verwacht resultaat: Originator should receive one combined or two separate Delivery Notifications for this test message. Gevonden resultaat: Exchange naar Route400: Gecombineerde Delivery notification ontvangen, met niet ingevulde velden Route400 naar Exchange: Gecombineerde Non-Delivery notification ontvangen

TEST GESLAAGD: ()NEE ( ) JA, ZONDER KANTTEKENING (x) JA, M A A R M E T DE VOLGENDE K A N T T E K E N I N G : Velden niet ingevuld. (zie ook SR-001)

° EDS, Versie

l.o

Pagina 78 van 228



Categorie: Doel: Test message delivery to multiple recipients at different destination MTA's. Prioriteit: A Noodzakelijke ondersteuning: 0 Werkwijze: 1. Originator creates one message to two valid remote X.400 Primary recipients, each in a different management domain - PRMD or ADMD). 2. Originator sends the message with Delivery Notification requested. Verwacht resultaat: Originator should receive two separate Delivery Notifications for this test message.

Gevonden resultaat: Exchange naar Route400: Twee Delivery notifications ontvangen, met niet ingevulde velden Route400 naar Exchange: Twee Delivery notifications ontvangen

TEST GESLAAGD: ()NEE ( ) JA, ZONDER KANTTEKENING (x) JA, MAAR MET DE VOLGENDE KANTTEKENING: Velden

°

E D S

-

V e r s i e10

Pagina 79 van 228

Rapport Project MSXCH01 Registratienummer A2530#06-R-l

Status definitief Activiteitnummen

SR-005

Categorie: Doel: Test message delivery to local and remote recipients. Prioriteit: A Noodzakelijke ondersteuning: 0 Werkwijze: 1. Originator creates a message to two valid X.400 Primary recipients, one remote and one local. . 2. Originator sends the message with Delivery Notification requested. Verwacht resultaat: Originator should receive two separate Delivery Notifications for this test message. Gevonden resultaat: Exchange naar Route400: Twee Delivery notifications ontvangen, met niet ingevulde velden Route400 naar Exchange: Twee Delivery notifications ontvangen Exchange naar Exchange wel ingevulde velden.

TEST GESLAAGD: ()NEE ( ) JA, ZONDER KANTTEKENING (x) JA, MAAR MET DE VOLGENDE KANTTEKENING: Velden

" EDS, Versie

l.o

Pagina 80 van 228


Registratienummer

A2530#06-R-l SR-101

Categorie: Doel:

Test message delivery based on valid surname.

Prioriteit: A Noodzakelijke ondersteuning: 6 Werkwijze: 1. Originator creates a message to one valid remote X.400 Primary recipient. The recipient's ORName is specified down to the PersonalName attribute. The PersonalName contains only a valid SurName component. 2. Originator sends the message - does not request a Delivery Notification. 3. Recipient generates a specific ackowledgement back to the originator stating that the message was received.

Verwacht resultaat: Originator should receive a specific ackowledgement for this test message. Gevonden resultaat: Exchange naar Route400: Acknowledgement ontvangen. Route400 naar Exchange: Acknowledgement ontvangen.

TEST GESLAAGD: () NEE (x) JA, ZONDER KANTTEKENING () JA, M A A R M E T DE VOLGENDE K A N T T E K E N I N G :

0

EDS, Versie 1.0

Pagina 81 van 228


Regis t r a t i e n u m mer A2530#06-R-l SR-102

Categorie: Doel: Test message non-delivery based on invalid surname. Prioriteit: A Noodzakelijke ondersteuning: 6 Werkwijze: 1. Originator creates a message to one invalid remote X.400 Primary recipient. The recipient's ORName is specified down to the PersonalName attribute. The PersonalName contains only an invalid SurName component. 2. Originator sends the message - does not request a Delivery Notification. Verwacht resultaat: Originator should receive a Non-Delivery Notification (due to Unrecognized ORName) for this test message. Gevonden resultaat: Exchange naar Route400: Non-Delivery Notification ontvangen. Route400 naar Exchange: Non-Delivery Notification ontvangen.

TEST GESLAAGD: () NEE (x) JA, ZONDER K A N T T E K E N I N G ( ) J A , M A A R MET DE VOLGENDE K A N T T E K E N I N G :

0

EDS, Versie 1.0

Pagina 82 van 228



Activiteitnummer:

SR-103

Categorie: Doel: Test message based on completely specified PersonalName. Prioriteit: A Noodzakelijke ondersteuning: 3 Werkwijze: 1. Originator creates a message to one valid remote X.400 Primary recipient. The recipient's ORName is specified down to the PersonalName attribute. The PersonalName is fully specified and contains the following components: NIST Profile: EN/ENV Profile: Note: this test.

SurName, GivenName, Initials, and GenerationQualifier Surname, GivenName, and Initials

Both implementations must support the same profile(s) to execute

2. Originator sends the message with Delivery Notification requested.

Verwacht resultaat: Originator should receive a Delivery Notification for this test message. Gevonden resultaat: Exchange naar Route400: Delivery notification ontvangen, echter de messagebody bevat de niet ingevulde regels: To: Unknown Subject: Unknown Sent: Unknown Als de test uitgevoerd wordt naar een Exchange bestemming zijn deze velden wel ingevuld. Route400 naar Exchange: Delivery notification ontvangen

TEST GESLAAGD: ()NEE ( ) J A , ZONDER K A N T T E K E N I N G (x) JA, M A A R M E T DE V O L G E N D E K A N T T E K E N I N G : Niet alle velden ingevuld

c

EDS, Versie 1.0

Pagina 83 van 228



Categorie: Doel: Test message non-delivery based on ambiguous Surname. Prioriteit: A Noodzakelijke ondersteuning: 3 Werkwijze: 1. Partner's MTA defines two users with the same SurName but different GivenNames (e.g., "Lincoln, Abraham." and "Lincoln, John"). 2. Originator creates a message to one of the valid remote X.400 Primary recipients. The recipient's ORName is specified down to the PersonalName attribute. The PersonalName contains only a valid SurName component. 3. Originator sends the message - does not request a Delivery Notification. Verwacht resultaat: Originator should receive a Non-Delivery Notification (due to Ambiguous or Unrecognized ORName) for this test message. Gevonden resultaat: Exchange naar Route400: Route400 precise routing aan: dan non delivery notification Route400 flexible routing aan: dan afgeleverd bij de eerste die voldoet. Exchange stuurt boodschappen altijd met alternate recipient allowed aan. Route400 naar Exchange: alternate recipient allowed aan of uit: non delivery notification :ambiguous recipient name" opmerking: als er een shared addres space aan staat binnen Exchange, worden berichten doorgerouteerd om te controleren of het bericht elders wel is af te leveren. TEST G E S L A A G D : ()NEE (x) JA, ZONDER KANTTEKENING ( ) JA, M A A R M E T DE VOLGENDE K A N T T E K E N I N G :

C

EDS, Versie 1.0

Pagina 84 van 228


Registratienummer A2530#06-R-l SR-104A

Categorie: Doel:

Test message non-delivery based on ambiguous Givenname.

Prioriteit: A Noodzakelijke ondersteuning: 3 Werkwijze: 1. Partner's MTA defines two users with the same SurName and GivenName but different Initials (e.g., "Lincoln, Abraham A." and "Lincoln, Abraham B."). 2. Originator creates a message to one of the valid remote X.400 Primary recipients. The recipient's ORName is specified down to the PersonalName attribute. The PersonalName contains only valid SurName and GivenName components. 3. Originator sends the message with Delivery Notification requested. Verwacht resultaat: Originator should receive a Non-Delivery Notification (due to Ambiguous or Unrecognized ORName) for this test message. Gevonden resultaat: Exchange naar Route400: Non-Delivery notification ontvangen (ambiguous name) Route400 naar Exchange: Non-Delivery notification ontvangen (ambiguous recipient)

TEST GESLAAGD: ()NEE (x) JA, ZONDER K A N T T E K E N I N G ( ) JA, M A A R M E T DE VOLGENDE K A N T T E K E N I N G :

0

EDS, Versie 1.0

Pagina 85 van 228


Status definitief Activiteitnummer:

SR-104B

Categorie: Doel:

Test message non-delivery based on ambiguous Initials.

Prioriteit: A Noodzakelijke ondersteuning: 3 Werkwijze: 1. Partner's MTA defines two users with the same SurName, GivenName, and Initials but different GenerationQualifier (e.g., "Lincoln, Abraham A.II" and Lincoln, Abraham A. III"). 2. Originator creates a message to one of the valid remote X.400 Primary recipients. The recipient's ORName is specified down to the PersonalName attribute. The PersonalName contains only valid SurName, GivenName, and Initials components. 3. Originator sends the message with Delivery Notification requested. Verwacht resultaat: Originator should receive a Non-Delivery Notification (due to Ambiguous or Unrecognized ORName) for this test message. Gevonden resultaat: Exchange naar Route400: Non-Delivery notification ontvangen (ambiguous name). Let op binnen Route400 moet op verplichte velden de waarde "NONE" worden ingevuld om het veld als unambiguous te defin'ieren. Route400 naar Exchange: Non-Delivery notification ontvangen (ambiguous name).

TEST GESLAAGD: () NEE (x) JA, ZONDER KANTTEKENING () JA, M A A R MET DE VOLGENDE K A N T T E K E N I N G :

c

EDS, Versie 1.0

Pagina 86 van 228



Categorie: Doel: Test Message Transfer System respons to an over-specified ORName (overspecified with givenname). Prioriteit: A Noodzakelijke ondersteuning: 3 Werkwijze: 1. Partner's MTA defines one user qualified down to PersonalName, with only the SurName component being significant for message delivery. Partner's MTA has no Alternate Recipient defined. 2. Orginator creates a message to that user. The recipient's ORName is specified down to the PersonalName attribute. The PersonalName contains only the valid SurName and a GivenName. 3. Orginator sends the message with Delivery Notification requested. Allow alternate recipients: determines whether or not the message may be delivered to a recipient whose details do not exactly match the details you have supplied. A/levering is afhankelijk van het service element alternate recipient allowed. Als dit element de waarde 'allowed' heeft en het adres bevat genoeg attributen om een gebruiker eenduidig te identiftceren, dan wordt het bericht bij die gebruiker afgeleverd. Is de waarde van alternate recipient 'not allowed'dan ontvangt de verzender een nondelivery report. Verwacht resultaat: Originator should receive a Non-Delivery Notification (due to Unrecognized ORName) for this test message. Note: Refer to NIST SP 500-162, section 7.5.3.5, "ORName Protocol Elements," which states that "Overspecified ORNames.... are to be non-delivered or sent to the alternate recipient as appropriate." Gevonden resultaat: Exchange naar Route400: Route400 precise routing aan: dan non delivery notification Route400 flexible routing aan: dan afgeleverd bij de eerste die voldoet. Exchange stuurt boodschappen altijd met alternate recipient allowed aan. Route400 naar Exchange: alternate recipient allowed aan of uit: non delivery notification .-ambiguous recipient name"

c

EDS, Versie 1.0

Pagina 87 van 228



opmerking: als er een shared addres space aan staat binnen Exchange, worden berichten doorgerouteerd om te controleren of het bericht elders wel is af te leveren.

TEST GESLAAGD: () NEE (x) JA, ZONDER K A N T T E K E N I N G ( ) JA, M A A R M E T DE V O L G E N D E KANTTEKENING:

c

EDS, Versie 1.0

Pagina 88 van 228



Categorie: Doel: Test Message Transfer System respons to an over-specified ORName (overspecified with initials). Prioriteit: A Noodzakelijke ondersteuning: 3 Werkwijze: 1. Partner's MTA defines one user qualified down to PersonalName, with only the GivenName component being significant for message delivery. Partner's MTA has no Alternate Recipient defined. 2. Orgininator creates a message to that user. The recipient's ORName is specified down to the PersonalName attribute. The PersonalName contains only the valid SurName and GivenName and some Initials. 3. Originator sends the message with Delivery Notification requested. Verwacht resultaat: Originator should receive a Non-Delivery Notification (due to Unrecognize ORName) for this test message. Note: Refer to NIST SP 500-162, section 7.5.3.5, "ORName Protocol Elements," which states that "Overspecified ORNames... are to be non-delivered or sent to the alternate recipient as appropriate". Gevonden resultaat: Exchange naar Route400: Geen Non-Delivery notification ontvangen, bericht wordt afgeleverd. Binnen Route400 is het niet mogelijk de waarde "NONE" in te vullen in het veld Initials, (probleem Route400) Route400 naar Exchange: Non-Delivery notification ontvangen (Unrecognized recipient)

TEST GESLAAGD: () NEE (x) JA, ZONDER K A N T T E K E N I N G ( ) JA, M A A R M E T DE V O L G E N D E K A N T T E K E N I N G :

c

EDS, Versie 1.0

Pagina 89 van 228



Categorie: Doel: Test message delivery based on Organization Name Attribute. Prioriteit: A Noodzakelijke ondersteuning: 3 "Werkwijze: 1. Orginator defines his/her MTA routing such that the OrganizationName attribute is necessary for routing to the Recipient's MTA. 2. Partner's MTA defines one user qualified down to OrganizationName, with the OrganizationName being significant for message delivery. 3. Originator creates a message to that user. The recipient's ORName is specified down to the OrganizationName attribute. 4. Originator sends the message with Delivery Notification requested.

Verwacht resultaat: Orginator should receive a Delivery Notification for this test message. Note: This will test the Originator MTA's ability to route on the Organization Name attribute, which demonstrates NIST "Class 1" routing within that MTA. Gevonden resultaat: Exchange naar Route400: Delivery notification ontvangen Route400 naar Exchange: Delivery notification ontvangen

TEST GESLAAGD: ()NEE (x) JA, ZONDER KANTTEKENING ( ) JA, MAAR MET DE VOLGENDE KANTTEKENING:

° EDS, Versie 1.0

Pagina 90 van 228



Categorie: Doel:

Test message delivery based on one Organizational Unit attribute.

Prioriteit: A Noodzakelijke ondersteuning: 3 Werkwijze: 1. Orginator defines his/her MTA routing such that one OrganizationalUnit attribute is necessary for routing to the Recipient's MTA. 2. Partner's MTA defines one user qualified down to OrganizationalUnit, with one OrgUnit component being significant for message delivery. 3. Originator creates a message addressed to two Primary recipients. The recipients' ORNames are specified down to the OrgUnit attribute. The two ORNames are the same up to the OrgUnit - one includes the OrgUnit of the valid recipient and the other has an invalid OrgUnit. 4. Originator sends the message with Delivery Notification requested.

Verwacht resultaat: Originator should receive a Delivery Notification for the valid recipient and a NonDelivery Notification (due to Unrecognized ORName) for the invalid one. Note: This will test the Originator MTA's ability to route on the Organization Unit attributes, which demonstrates NIST "Class2" routing within that MTA.

Gevonden resultaat: Originator ontvangt Delivery Notification for valid recipient en een Non-delivery Notification voor the ongeldige

TEST G E S L A A G D : () NEE (x) JA, ZONDER K A N T T E K E N I N G ( ) JA, M A A R M E T DE VOLGENDE K A N T T E K E N I N G :

0

EDS, Versie 1.0

Pagina 91 van 228



SR-107A

Categorie: Doel: Test message delivery based on two Organizational Unit attributes. Prioriteit: A Noodzakelijke ondersteuning: 3 Werkwijze: 1. Originator defines his/her MTA routing such that two OrganizationalUnit attributes are necessary for routing to the Recipient's MTA. 2. Partner's MTA defines one user qualified down to OrganizationalUnit, with two OrgUnit components being significant for message delivery. 3. Originator creates a message addressed to two Primary recipients. The recipients' ORNames specified down to the OrgUnit attributes. The two ORNames are the same up to the second (least significant) OrgUnit one includes the least-significant OrgUnit of the valid recipient and the other has an invalid least-significant OrgUnit. 4. Originator sends the message with Delivery Notification requested.

Verwacht resultaat: Originator should receive a Delivery Notification for the valid recipient and an NonDelivery Notification (due to Unrecognize ORName) for the invalid one. Note: This will test the Originator MTA's ability to route on the Organization Unit attributes, which demonstrates NIST "Class 2" routing within that MTA. Gevonden resultaat: Originator ontvangt Delivery Notification for valid recipient en een Non-delivery Notification voor the ongeldige.

TEST G E S L A A G D : ()NEE (x) JA, ZONDER KANTTEKENING ( ) JA, M A A R M E T DE VOLGENDE K A N T T E K E N I N G :

c

EDS, Versie 1.0

Pagina 92 van 228


Registratienummer A2530#06-R-l SR-107B

Categorie: Doel:

Test message delivery based on three Organizational Unit attributes.

Prioriteit: A Noodzakelijke ondersteuning: 3 "Werkwijze: 1. Originator defines hisfter MTA routing such that three OrganizationalUnit attributes are necessary for routing to the Recipient's MTA. 2. Partner's MTA defines one user qualified down to OrganizationalUnit, with three OrgUnit components being significant for message delivery. 3. Originator creates a message addressed to two Primary recipients. The recipients' ORNames specified down to the OrgUnit attributes. The two ORNames are the same up to the third (least significant) OrgUnit - one includes the least-significant OrgUnit of the valid recipient and the other has an invalid least-significant OrgUnit. 4. Orginator sends the message with Delivery Notification requested.

Verwacht resultaat: Originator should receive a Delivery Notification for the valid recipient and a NonDelivery Notification (due to Unrecognized ORName) for the invalid one. Note: This will test the Originator MTA's ability to route on the Organization Unit attributes, which demonstrate NIST "Class 2" routing within that MTA.

Gevonden resultaat: Originator ontvangt Delivery Notification for valid recipient en een Non-delivery Notification voor the ongeldige.

TEST G E S L A A G D : () NEE (x) JA, ZONDER KANTTEKENING ( ) JA, M A A R M E T DE VOLGENDE K A N T T E K E N I N G :

0

EDS, Versie 1.0

Pagina 93 van 228


Registratienummer A2530#06-R-l SR-107C

Categorie: Doel:

Test message delivery based on four Organizational Unit attributes.

Prioriteit: A Noodzakelijke ondersteuning: 3 Werkwijze: 1. Originator defines his/her MTA routing such that four OrganizationalUnit attributes are necessary for routing to the Recipient's MTA. 2. Partner's MTA defines one user qualified down to OrganizationalUnit, with four OrgUnit components being significant for message delivery. 3. Originator creates a message addressed to two Primary recipients. The recipients' ORNames specified down to the OrgUnit attributes. The two ORNames are the same up to the fourth (least significant) OrgUnit, one includes the least-significant OrgUnit of the valid recipient and the other has an invalid least-significant OrgUnit. 4. Originator sends the message with Delivery Notification requested.

Verwacht resultaat: Originator should receive a Delivery Notification for the valid recipient and a NonDelivery Notification (due to Unrecognized ORName) for the invalid one. Note: This will test the Originator MTA's ability to route on the Organization Unit attributes, which demonstrates NIST "Class 2" routing within that MTA. Gevonden resultaat: Originator ontvangt Delivery Notification for valid recipient en een Non-delivery Notification voor the ongeldige.

TEST GESLAAGD: () NEE (x) JA, ZONDER KANTTEKENING ( ) JA, M A A R MET DE V O L G E N D E KANTTEKENENG:

C

EDS, Versie 1.0

Pagina 94 van 228

Rapport

EDS

Project MSXCH01 Status definitief Activiteitnummer:


Categorie: Doel:

Test for delivery and non-delivery based on PersonalName attribute.

Prioriteit: A Noodzakelijke ondersteuning: 3 Werkwijze: 1. Originator defines his/her MTA routing such that the PersonalName attribute (specifically, the GivenName) is necessary for routing to the Recipient's MTA. 2. Partner's MTA defines one user qualified down to PersonalName, with the GivenName component being significant for message delivery. 3. Originator creates a message addressed to two Primary recipients. The recipients' ORNames are specified down to the PersonalName attribute. The PersonalNames contain only the SurName and GivenName components; the SurNames are the same for both but one has a valid GivenName and the other has an invalid GivenName. 4. Originator sends the message with Delivery Notification requested. Verwacht resultaat: Originator should receive a Delivery Notification for the valid recipient and a NonDelivery Notification (due to Unrecognized ORName) for the invalid one. Note: This will test the Originator MTA's ability to route on the PersonalName attribute, which demonstrates NIST "Class 3" routing within that MTA. Gevonden resultaat: Definite van de routing tabel (Addressspace) van Exchange is enkel mogelijk tot op het ORName attnbuut Organisation en OrganisationalUnit. De adres elementen voor PersonalName kunnen niet gebruikt worden.

TEST G E S L A A G D : (x) NEE ( ) JA, ZONDER K A N T T E K E N I N G () J A , M A A R M E T DE V O L G E N D E K A N T T E K E N I N G : ° EDS, Versie 1.0

Pagina 95 van 228



SR-109

Categorie: Doel: Test the ability of the Message Transfer System to use the Initials attribute in the name discrimination. Prioriteit: A Noodzakelijke ondersteuning: 3 Werkwijze: 1. Partner's MTA defines two users with the same SurName and GivenName but different Initials (e.g., "Lincoln, Abraham A." and "Lincoln, Abraham B.") 2. Originator creates a message to one of the valid remote X.400 Primary recipients. The recipient's ORName is specified down to the PersonalName attribute. The PersonalName contains a valid SurName, GivenName, and Initials for one of the users. 3. Originator sends the message with Delivery Notification requested. Verwacht resultaat: Originator should receive a Delivery Notification requested. Gevonden resultaat: Delivery Notification is ontvangen.

TEST GESLAAGD: () NEE (x) JA, ZONDER KANTTEKENING ( ) JA, MAAR MET DE VOLGENDE KANTTEKENING:

c

EDS, Versie 1.0

Pagina 96 van 228



SR-109A

Categorie: Doel: Test the ability of the Message Transfer System to use the GenerationQualifier attribute in the name discrimination. Prioriteit: A Noodzakelijke ondersteuning: 3 Werkwijze: 1. Partner's MTA defines two users with the same SurName, GivenName, and Initials but different GenerationQualifiers (e.g., "Lincoln, Abraham A. II" and "Lincoln, Abraham A. III"). 2. Originator creates a message to one of the valid remote X.400 Primary recipients. The recipients's ORName is specified down to the PersonalName attribute. The PersonalName contains a valid SurName, GivenName, Initials, and GenerationQualifier for one of the users, 3. Originator sends the message with Delivery Notification requested.

Verwacht resultaat: Originator should receive a Delivery Notification for this test message. Gevonden resultaat: Delivery Notification is ontvangen.


°EDS, Versie 1.0

Pagina 97 van 228


EDS

Status definitief


Activiteitnummer:

SR-110

Categorie: Doel:

Test message non-delivery based on invalid PRMD.

Prioriteit: A Noodzakelijke ondersteuning: 3 Werkwijze: L

r

^

°

U t i n

S

"ZAL D P ^ n " V ! ^ abled

^

3

s u c h

t0

t h a t

m e s s a

§

e s w

P a r t n e r S MTA

'

d

°

e S

"

i t h a PRMD name of of

-

0 t h a V C

Partnerd o e s N 0 T a n y

d e f a u l t

r o u t i n

8

e n

"

2. Originator creates a message to one invalid remote X.400 Primary recipient The recipient s ORName is specified down to the PersonalName attribute M

NLYANINVA,IDP R M D C MPONENTSPECIFIEDAS

SJVSRSD^ °

°

3. Originator sends the message - does not request a Delivery Notification. Verwacht resultaat: Originator should receive a Non-Delivery Notification (due to Unrecognized ORName) for this test message. 5

Gevonden resultaat: Originator ontvangt een Non-Delivery Notification (unrecognized recipient name)


°EDS, Versie 1.0

Pagina 98 van 228



SR-201

Categorie: Doel:

Test the originator indication IPM service element.

Prioriteit: B Noodzakelijke ondersteuning: 6 Werkwijze: 1. Originator creates a message to one valid remote X.400 Primary recipient.The message should include the Originator Indication service element in the IP message content header. 2. Originator sends the message - does not request a Delivery Notification. 3. Recipient generates a specific acknowledgement back to the originator stating that the message was received and stating whether or not the message contained the Originator Indication. Verwacht resultaat: Originator should receive a specific acknowledgement for this test message. Gevonden resultaat: Originator adres is zichtbaar in envelope informatie van ontvangen boodschap

TEST GESLAAGD: () NEE (x) JA, ZONDER K A N T T E K E N I N G () JA, M A A R M E T DE V O L G E N D E K A N T T E K E N I N G :

°EDS, Versie 1.0

Pagina 99 van 228

Rapport Project MSXCH01 S t a t u s


definitief Activiteitnummer:

EDS

"

SR-202

Categorie: Doel: Test Primary and Copy Recipients Indication IPM service element - single recipients. 6

Prioriteit: B Noodzakelijke ondersteuning: 6 Werkwijze: 1. Originator creates a message to two valid remote X.400 recipients. - one Primary recipient and one Copy recipient. 2. Originator sends the message - does not request a Delivery Notification. 3. Recipients generate a specific acknowledgement back to the originator stating that the message was received. The Primary and Copy recipients should state that they were indicated as such in the messages they received and that the other recipient was disclosed to them as well.

Verwacht resultaat: Originator should receive two specific ackowledgements for this test message. Gevonden resultaat: Originator, Primary- en Copy-recipient adressen zijn zichtbaar in envelope informatie van ontvangen boodschap

TEST G E S L A A G D : () NEE (x) JA, ZONDER KANTTEKENING () JA, M A A R M E T DE VOLGENDE K A N T T E K E N I N G :

° EDS, Versie 1.0

Pagina 100 van 228


Regis t rat ie n u m m er

A2530#06-R-l SR-202A

Categorie: Doel: Test Primary and Copy Recipients Indication IPM service element - multiple recipients. Prioriteit: B Noodzakelijke ondersteuning: 3 Werkwijze: 1. Originator creates a message to four valid remote X.400 recipients - two Primary recipients and two Copy recipients. 2. Originator sends the message - does not request a Delivery Notification. 3. Recipients generate a specific acknowledgement back to the originator stating that the message was received. The Primary and Copy recpients should state that they were indicated as such in the messages they received and that the other recipients were disclosed to them as well. Verwacht resultaat: Originator should receive four specific ackowledgements for this test message.

Gevonden resultaat: Originator, alle Primary- en Copy-recipient adressen zijn zichtbaar in envelope informatie van ontvangen boodschap

TEST G E S L A A G D : () NEE (x) JA, ZONDER K A N T T E K E N I N G () JA, M A A R M E T DE VOLGENDE K A N T T E K E N I N G :

0

EDS, Versie 1.0

Pagina 101 van 228

Rapport

EDS

Project MSXCH01 Status definitief Activiteitnummer:


Categorie: Doel: Test Primary and Copy Recipients Indication IPM service element - Copy recipient only. Prioriteit: B Noodzakelijke ondersteuning: 3 Werkwijze: 1. Originator creates a message to one valid remote X.400 Copy recipient only - no Primary recipient. 2. Originator sends the message - does not request a Delivery Notification. 3. Recipient generates a specific acknowledgement back to the originator stating that the message was received, and that he/ she was indicated as the Copy recipient in the message. Verwacht resultaat: Originator should receive a specific acknowledgement for this test message. Note: Some implementations may not allow the creation/submission of a message without at least one Primary recipient. Gevonden resultaat: Bericht komt aan. Originator en Copy-recipient adressen zijn zichtbaar in envelope informatie van ontvangen boodschap

TEST GESLAAGD: () NEE (x) JA, ZONDER K A N T T E K E N I N G () JA, M A A R M E T DE V O L G E N D E KANTTEKENEVG:

c

EDS, Versie 1.0

Pagina 102 van 228



SR-203

Categorie: Doel:

Test Blind Copy Recipient Indication IPM service element - single recipients.

Prioriteit: B Noodzakelijke ondersteuning: 3 Werkwijze: 1. Originator creates a message to two valid remote X.400 recipients - one Primary recipient and one Blind Copy recipient. 2. Originator sends the message - does not request a Delivery Notification. 3. Recipients generate a specific acknowledgement back to the originator stating that the message was received. The Primary and Blind Copy recipients should state that they were indicated as such in the messages they received. The Primary recipient should state that the Blind Copy recipient was not disclosed to him/her. Verwacht resultaat: Originator should receive two specific acknowledgements for this test message. Gevonden resultaat: Exchange naar Route400: de Route400 ontvanger ziet zowel de To: als de BCC: adressanten (dit gebeurt niet als een ander X.400 pakket de berichten verstuurd). Route400 naar Exchange: de To: ontvanger ziet alleen zichzelf, de Bcc: ontvanger ziet alleen zichzelf en heeft geen indicatie dat hij/zij een Bcc ontvanger is. Door Exchange wordt het dus slechts bij ontvangst ondersteund. TEST G E S L A A G D : (x) NEE ( ) JA, ZONDER K A N T T E K E N I N G ( ) JA, M A A R M E T DE V O L G E N D E K A N T T E K E N I N G :

c

EDS, Versie 1.0

Pagina 103 van 228


EDS



Categorie: Doel:

Test Blind Copy Recipient Indication IPM service element - multiple recipi-

Prioriteit: B Noodzakelijke ondersteuning: 3 Werkwijze: 1. Originator creates a message to four valid remote X.400 recipients - two Primary recipients and two Blind Copy recipients. 2. Originator sends the message - does not request a Delivery Notification. 3. Recipients generate a specific acknowledgement back to the originator stating that the message was received. The Primary and Blind Copy recipients should state that they were indicated as such in the messages they received. The Primary recipients should state that the Blind Copy recipients were not disclosed to them 1 he Blind Copy recipients should state whether or not the other Blind Copy recipient was disclosed to them. Verwacht resultaat: Originator should receive four specific acknowledgements for this test message. Gevonden resultaat: zie 203

TEST GESLAAGD: (x) NEE ( ) JA, ZONDER K A N T T E K E N I N G () JA, M A A R M E T DE V O L G E N D E KANTTEKENING:

C

EDS, Versie 1.0

Pagina 104 van 228



SR-203 B

Categorie: Doel: Test Blind Copie Recipient Indication IPM service element - Blind Copy recipient only. Prioriteit: B Noodzakelijke ondersteuning: 3 Werkwijze: 1. Originator creates a message to one valid remote X.400 Blind Copy recipient only - no Primary recipient. 2. Originator sends the message - does not request a Delivery Notification. 3. Recipient generates a specific acknowledgement back to the originator stating that the message was received, and that he/she was indicated as the Blind Copy recipient in the message. Verwacht resultaat: Originator should receive a specific acknowledgement for this test message. Note: Some implementations may not allow the creation/ submission of a message without at least one Primary recipient.

Gevonden resultaat: zie 203

TEST GESLAAGD: (x) NEE ( ) JA, ZONDER K A N T T E K E N I N G ( ) JA, M A A R M E T D E V O L G E N D E K A N T T E K E N I N G :

0

EDS, Versie 1.0

Pagina 105 van 228



Categorie: Doel: Test Reply Request Indication IPM service element - specifically the ReplyBy IPM heading component. Prioriteit: B Noodzakelijke ondersteuning: 3 Werkwijze: 1. Originator creates a message to one valid remote X.400 Primary recipient. The message should include the ReplyBy IPM heading component with a specific UTCTime value (e.g.,"8904180900-0800" which is 9 am local time in San Francisco on April 18, 1989). 2. Originator sends the message - does not request a Delivery Notification. 3. Recipient generates a specific acknowledgement back to the originator stating that the message was received and stating whether or not the message contained the ReplyBy IPM heading component with the date and time correctly formatted. Verwacht resultaat: Originator should receive a specific acknowledgement for this test message. Gevonden resultaat: Route400 naar Exchange: wordt niet getoond, ook al claimed men in het VOSIP support bij ontvangst. Exchange naar Route400: kan niet gezet worden

TEST G E S L A A G D : (x) NEE () JA, ZONDER K A N T T E K E N I N G () JA, M A A R M E T DE VOLGENDE K A N T T E K E N I N G :

0

EDS, Versie 1.0

Pagina 106 van 228



SR-204A

Categorie: Doel: Test Reply Request Indication IPM service element - specifically the ReplyToUsers IPM heading component. Prioriteit: B Noodzakelijke ondersteuning: 3 Werkwijze: 1. Originator creates a message to one valid remote X.400 Primary recipient. The message should include the RelplyToUsers IPM heading component with one ORName specified. 2. Originator sends the message - does not request a Delivery Notification. 3. Recipient generates a specific acknowledgedment back to the originator stating that the message was received and stating whether or not the message contained the ReplyToUsers IPM heading component with the correct ORName. Verwacht resultaat: Originator should receive a specific ackowledgement for this test message. Gevonden resultaat: Route400 naar Exchange: functioneerd correct, de reply wordt naar de gevraagde user gestuurd. Exchange naar Route400: kan niet gezet worden

TEST G E S L A A G D : (x) NEE () JA, ZONDER K A N T T E K E N I N G () JA, M A A R M E T DE VOLGENDE K A N T T E K E N I N G :

0

EDS, Versie 1.0

Pagina 107 van 228



Categorie: Doel: Test Reply Request Indication IPM service element - specifically both ReplyBy and the ReplyToUsers (with multiple ORNames) IPM heading components. Prioriteit: B Noodzakelijke ondersteuning: 3 Werkwijze: 1. Originator creates a message to one valid remote X.400 Primary recipient The message should include the ReplyBy IPM heading component with a specific UTCT.me value (e.g., "8904180900-0800" which is 9am local time in San Francisco on April 18, 1989). The message should also include the ReplyToUsers IPM heading component with two ORNames specified. 2. Originator sends the message - does not request a Delivery Notification. 3. Recipient generates a specific acknowledgement back to the originator stating that the message was received and stating whether or not the message contained the ReplyToUsers IPM heading component wiht the correct ORNames and also whether or not the message contained the ReplyBy IPM heading component with the date and time correctly formatted. Verwacht resultaat: Originator should receive a specific acknowledgement for this test message. Gevonden resultaat: Exchange kent en herkent dit IPM service element niet.

TEST G E S L A A G D : (x) NEE ( ) JA, ZONDER KANTTEKENING ( ) JA, M A A R M E T DE VOLGENDE K A N T T E K E N I N G :

c

EDS, Versie 1.0

Pagina 108 van 228



SR-204C

Categorie: Doel: Test Reply Request Indication IPM service element, multiple recipients - specifically the ReplyBy IPM heading component. Prioriteit: B Noodzakelijke ondersteuning: 3 Werkwijze: 1. Originator creates a message to two valid remote X.400 Primary recipients. The message should include the ReplyBy IPM heading component with a specific UTCTime value (e.g., "8904180900-0800" which is 9am local time in San Francisco on April 18, 1989). 2. Originator sends the message - does not request a Delivery Notification. 3. Recipients generate a specific acknowledgement back to the originator stating that the message was received and stating whether or not the message contained the ReplyBy IPM heading component with the date and time correctly formatted.

Verwacht resultaat: Originator should receive a specific acknowledgement for this test message from each of the recipients.

Gevonden resultaat: zie 204 en 204B

TEST G E S L A A G D : (x) NEE ( ) JA, ZONDER K A N T T E K E N I N G ( ) JA, M A A R M E T DE V O L G E N D E K A N T T E K E N I N G :

°EDS, Versie 1.0

Pagina 109 van 228

ho~x:6i -icjj6 Ministerie van Verkeer en Waterstaat. Directoraat-Generaal Rijkswaterstaat. Meetkundige Dienst. Route 400 Exchanged?

Recommend Documents