|
|
 | 'Gennemlæsning' af mails
Fra : Bertel Lund Hansen |
Dato : 02-12-01 11:27 |
|
Hej alle
I sikkerhedsgruppen blev det nævnt at der i Tyskland er servere
der advarer modtageren *på forhånd* om at der ligger en
virusbefængt mail i hans postboks. Der blev så fremsat det
postulat at en sådan tjeneste ville være ulovlig i Danmark på
grund af brevhemmeligheden.
Det kan da ikke passe? I sin yderste konsekvens må serveren jo så
heller ikke læse modtageradressen så mailen kan ekspederes.
Er det ikke korrekt forstået/gættet at brevhemmeligheden kun
omfatter personers læsning (mere præcist kundskab) og ikke et
maskinelt tjek for f.eks. virussmitte af indholdet?
Det ville i øvrigt overraske mig om ikke der også er
brevhemmmelighed i Tyskland.
--
Bertel
http://lundhansen.dk/bertel/ FIDUSO: http://fiduso.dk/
| |
 Peter G C (02-12-2001)
| Kommentar
Fra : Peter G C |
Dato : 02-12-01 11:32 |
|
"Bertel Lund Hansen" <nospam@lundhansen.dk> wrote in message
news:p60k0ugpg1g1on6ecaqhumi8j5svdv7d6e@sunsite.auc.dk...
[klip]
> Det kan da ikke passe? I sin yderste konsekvens må serveren jo så
> heller ikke læse modtageradressen så mailen kan ekspederes.
Enig. Det andet lyder helt utænkeligt.
>
> Er det ikke korrekt forstået/gættet at brevhemmeligheden kun
> omfatter personers læsning (mere præcist kundskab) og ikke et
> maskinelt tjek for f.eks. virussmitte af indholdet?
Uden at have kontrolleret det, så vil jeg give dig ret.
>
> Det ville i øvrigt overraske mig om ikke der også er
> brevhemmmelighed i Tyskland.
Det må der da være....
/Peter
--
http://www.grauslund.com/
http://politiken.dk/VisArtikel.iasp?PageID=182594 - når det går galt....
| |
Peter G C (02-12-2001)
| Kommentar
Fra : Peter G C |
Dato : 02-12-01 11:39 |
|
"Bertel Lund Hansen" <nospam@lundhansen.dk> wrote in message
news:p60k0ugpg1g1on6ecaqhumi8j5svdv7d6e@sunsite.auc.dk...
[klip]
> Det ville i øvrigt overraske mig om ikke der også er
> brevhemmmelighed i Tyskland.
Jeg fandt en NG om emnet:
news:de.soc.recht.misc
Stiller du spørgsmålet eller gør jeg?
/Peter
--
http://www.grauslund.com/
http://politiken.dk/VisArtikel.iasp?PageID=182594 - når det går galt....
| |
Povl H. Pedersen (02-12-2001)
| Kommentar
Fra : Povl H. Pedersen |
Dato : 02-12-01 11:52 |
|
On Sun, 02 Dec 2001 11:27:24 +0100,
Bertel Lund Hansen <nospam@lundhansen.dk> wrote:
> Hej alle
>
> I sikkerhedsgruppen blev det nævnt at der i Tyskland er servere
> der advarer modtageren *på forhånd* om at der ligger en
> virusbefængt mail i hans postboks. Der blev så fremsat det
> postulat at en sådan tjeneste ville være ulovlig i Danmark på
> grund af brevhemmeligheden.
>
> Det kan da ikke passe? I sin yderste konsekvens må serveren jo så
> heller ikke læse modtageradressen så mailen kan ekspederes.
Der har været megen snak om dette i FIL (Foreningen af Internet
Leverandører) i gamle dage.
Det regnes normalt for OK at læse det der teknisk defineres som
"envelope" på en mail. Dette er alle headers ned til første tomme
linie (som adskiller leveringsinformationer fra indholdet). Der
har man info om afsender, modtager, subject, dato, og hvilke
maskiner mailen har været igennem. Det er enhver mailserver pligt
jvf. standarden at ændre envelop'en, og skrive en modtagekvittering
ind i toppen af denne.
Det der kaldes "envelope" sammenlignes altså med information
udenpå kuverten.
> Er det ikke korrekt forstået/gættet at brevhemmeligheden kun
> omfatter personers læsning (mere præcist kundskab) og ikke et
> maskinelt tjek for f.eks. virussmitte af indholdet?
Jo, det vil jeg umiddelbart sige. Så man kan godt have et filter
der leder efter interessant mail. Men før disse videresendes til
eller læses af 3die mand, så er der vel ingen problemer. Men jeg
er dog ikke sikker herpå.
> Det ville i øvrigt overraske mig om ikke der også er
> brevhemmmelighed i Tyskland.
Det er der vel.
| |
Henning Makholm (02-12-2001)
| Kommentar
Fra : Henning Makholm |
Dato : 02-12-01 17:08 |
|
Scripsit nospam@home.terminal.dk (Povl H. Pedersen)
> Det regnes normalt for OK at læse det der teknisk defineres som
> "envelope" på en mail. Dette er alle headers ned til første tomme
> linie (som adskiller leveringsinformationer fra indholdet).
Så vidt jeg ved plejer "envelope" at betyde de adresser der angives i
SMTP-kommandoerne "MAIL FROM:" og "RCPT TO:". Headerne *i* mailen bør
ikke have nogen indflydelse på leveringen (undtagen hvis de bliver
gennemset af spamfiltre o.l.).
--
Henning Makholm "En tapper tinsoldat. En dame i
spagat. Du er en lykkelig mand ..."
| |
 Povl H. Pedersen (02-12-2001)
| Kommentar
Fra : Povl H. Pedersen |
Dato : 02-12-01 22:34 |
|
On 02 Dec 2001 17:07:48 +0100,
Henning Makholm <henning@makholm.net> wrote:
> Scripsit nospam@home.terminal.dk (Povl H. Pedersen)
>
>> Det regnes normalt for OK at læse det der teknisk defineres som
>> "envelope" på en mail. Dette er alle headers ned til første tomme
>> linie (som adskiller leveringsinformationer fra indholdet).
>
> Så vidt jeg ved plejer "envelope" at betyde de adresser der angives i
> SMTP-kommandoerne "MAIL FROM:" og "RCPT TO:". Headerne *i* mailen bør
> ikke have nogen indflydelse på leveringen (undtagen hvis de bliver
> gennemset af spamfiltre o.l.).
Jvf. SMTP standarden, så SKAL enhvert SMTP server som beskeden
går gennem ændre indholdet af headers. Der SKAL tilføjes en
Received: header. At der så er enkelte softwarepakker som
ikke overholder kravene til dette er noget andet.
Men det er korrekt at leveringsinformation normalt holdes
andetsteds end i mailen, og at To: CC: Bcc: etc headers
absolut intet betyder når først mailen har ramt en SMTP server.
| |
Henning Makholm (03-12-2001)
| Kommentar
Fra : Henning Makholm |
Dato : 03-12-01 13:20 |
|
Scripsit nospam@home.terminal.dk (Povl H. Pedersen)
> Henning Makholm <henning@makholm.net> wrote:
> > Så vidt jeg ved plejer "envelope" at betyde de adresser der angives i
> > SMTP-kommandoerne "MAIL FROM:" og "RCPT TO:". Headerne *i* mailen bør
> > ikke have nogen indflydelse på leveringen (undtagen hvis de bliver
> > gennemset af spamfiltre o.l.).
> Jvf. SMTP standarden, så SKAL enhvert SMTP server som beskeden
> går gennem ændre indholdet af headers. Der SKAL tilføjes en
> Received: header.
De skal tilføje Received: i toppen af indholdet - uanset hvad det
hidtidige indhold er. De skal normalt ikke give sig til at fortolke
det indhold der kommer efter deres Received:-linjen, det skal bare
kopieres råt.
RFC-821 siger:
| When the receiver-SMTP accepts a message either for relaying
| or for final delivery it inserts at the beginning of the
| mail data a time stamp line. The time stamp line indicates
| the identity of the host that sent the message, and the
| identity of the host that received the message (and is
| inserting this time stamp), and the date and time the
| message was received. Relayed messages will have multiple
| time stamp lines.
Bemærk "at the beginning of the mail data", ikke "among the headers".
Ordet "header" forekommer kun 3 steder i RFC-821 - én gang for at
beskrive en forskel mellem adressesyntaksen i SMTP-konvolutten og
RFC-822-headere og to gange for at betegne indholdet af selve den
leverede email som "headers and body".
--
Henning Makholm "I Guds Faders namn, och Sonens, och den Helige
Andes! Bevara oss från djävulens verk och från Muhammeds,
den förbannades, illfundigheter! Med dig är det värre än med
någon annan, ty att lyssna till Muhammed är det värsta av allt."
| |
Peter Brodersen (03-12-2001)
| Kommentar
Fra : Peter Brodersen |
Dato : 03-12-01 21:33 |
|
On 03 Dec 2001 13:19:56 +0100, Henning Makholm <henning@makholm.net>
wrote:
>Bemærk "at the beginning of the mail data", ikke "among the headers".
>Ordet "header" forekommer kun 3 steder i RFC-821 - én gang for at
>beskrive en forskel mellem adressesyntaksen i SMTP-konvolutten og
>RFC-822-headere og to gange for at betegne indholdet af selve den
>leverede email som "headers and body".
Blot for en god ordens skyld; RFC821 og RFC822 er blevet obsolete på
baggrund af RFC2821 og RFC2822. Ordlyden er næsten den samme; "time
stamp line" benævnes nu mere generelt som en "trace record".
(fut: dk.edb.internet)
--
- Peter Brodersen
24 Days of Crashmas - julekalender:
http://jul.bums.dk/
| |
Anders Vind Ebbesen (02-12-2001)
| Kommentar
Fra : Anders Vind Ebbesen |
Dato : 02-12-01 13:00 |
|
In article <p60k0ugpg1g1on6ecaqhumi8j5svdv7d6e@sunsite.auc.dk>,
Bertel Lund Hansen claimed the following:
> Hej alle
>
> I sikkerhedsgruppen blev det nævnt at der i Tyskland er servere
> der advarer modtageren *på forhånd* om at der ligger en
> virusbefængt mail i hans postboks. Der blev så fremsat det
> postulat at en sådan tjeneste ville være ulovlig i Danmark på
> grund af brevhemmeligheden.
Uden at jeg kan tage stilling til det juridiske i sagen, så ved
jeg at Cybercity har en tjeneste[1], der scanner folks emails.
Det kræver dog at folk tilmelder sig, men om det har betydning
for juraen, ved jeg ikke.
http://www.cybercity.dk/privat/tjenester/diverse_tjenester/hacker_smacker/
--
Anders Vind Ebbesen
Consultant in envisioneering vertical applications
www.ebbesen.org | anders@ebbesen.org
Sjov og spas, øh: http://boomer.dk
| |
Bertel Lund Hansen (02-12-2001)
| Kommentar
Fra : Bertel Lund Hansen |
Dato : 02-12-01 16:05 |
|
Anders Vind Ebbesen skrev:
>Det kræver dog at folk tilmelder sig, men om det har betydning
>for juraen, ved jeg ikke.
Det er nok bare for at undgå vrede kunder uanset juraen, og jeg
forstår dem godt.
--
Bertel
http://lundhansen.dk/bertel/ FIDUSO: http://fiduso.dk/
| |
Henning Makholm (02-12-2001)
| Kommentar
Fra : Henning Makholm |
Dato : 02-12-01 17:10 |
|
Scripsit spam@boomer.dk (Anders Vind Ebbesen)
> Uden at jeg kan tage stilling til det juridiske i sagen, så ved
> jeg at Cybercity har en tjeneste[1], der scanner folks emails.
> Det kræver dog at folk tilmelder sig, men om det har betydning
> for juraen, ved jeg ikke.
Det har den betydning at en tilmeldt tjeneste ihvertfald aldrig kan
stride mod brevhemmeligheden uanset om en ikke-tilmeldt tjeneste viser
sig at gøre det eller ej. Tilmeldingen udgør en direkte bemyndigelse
til at foretage scanningen.
--
Henning Makholm "This imposes the restriction on any
procedure statement that the kind and type
of each actual parameter be compatible with the
kind and type of the corresponding formal parameter."
| |
|
|