/ Forside / Teknologi / Internet / E-Mail / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
E-Mail
#NavnPoint
o.v.n. 20481
miritdk 16341
Klaudi 15149
refi 14168
dk 5555
tedd 5322
webnoob 5265
BjarneD 5014
emesen 4154
10  bentjuul 3460
Æøå
Fra : Niels P Sønderskov


Dato : 22-08-09 23:20

Jeg ved at dk-domæner med æøå fungerer på nettet og ikke frembyder
problemer for danske brugere med dansk tastatur, men hvordan forholder det
sig for tiden med mail?

Kan man uden videre sende og modtage mails på et æøå-domæne?

--
Niels

 
 
Per Rønne (23-08-2009)
Kommentar
Fra : Per Rønne


Dato : 23-08-09 04:32

Niels P Sønderskov <npsonder@gmail.com> wrote:

> Jeg ved at dk-domæner med æøå fungerer på nettet og ikke frembyder
> problemer for danske brugere med dansk tastatur, men hvordan forholder det
> sig for tiden med mail?
>
> Kan man uden videre sende og modtage mails på et æøå-domæne?

Vistnok ikke hvis USA er indblandet ...
--
Per Erik Rønne
http://www.RQNNE.dk
Errare humanum est, sed in errore perseverare turpe est

Niels P Sønderskov (23-08-2009)
Kommentar
Fra : Niels P Sønderskov


Dato : 23-08-09 11:20

Per Rønne per@RQNNE.invalid skrev 23.08.2009 05:31:41 i
<1j4vzbm.88b0ak15ei66N%per@RQNNE.invalid> bl.a.:

>Niels P Sønderskov <npsonder@gmail.com> wrote:
>
>>Jeg ved at dk-domæner med æøå fungerer på nettet og ikke frembyder
>>problemer for danske brugere med dansk tastatur, men hvordan forholder det
>>sig for tiden med mail?
>>
>>Kan man uden videre sende og modtage mails på et æøå-domæne?
>
>Vistnok ikke hvis USA er indblandet ...

Hvis jeg vælger et æøå-domæne bliver det til ren lokal brug, og det vil i
og for sig være ok bare html fungerer. Ekstra gevinst hvis almindeligt
forekomne mail-klienter kan håndtere det.

Har lavet en test à la Adam, for at se hvad der sker.

--
Niels

Bertel Lund Hansen (23-08-2009)
Kommentar
Fra : Bertel Lund Hansen


Dato : 23-08-09 07:05

Niels P Sønderskov skrev:

> Jeg ved at dk-domæner med æøå fungerer på nettet og ikke frembyder
> problemer for danske brugere med dansk tastatur,

Det er en sandhed med modifikationer.

> men hvordan forholder det sig for tiden med mail?
> Kan man uden videre sende og modtage mails på et æøå-domæne?

Nej.

Det ville undre mig om det nogensinde bliver muligt, men rent
teoretisk kan man godt i et mailprogram implementere det samme
fusk som man laver i browserne.

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

Adam Sjøgren (23-08-2009)
Kommentar
Fra : Adam Sjøgren


Dato : 23-08-09 08:59

On Sun, 23 Aug 2009 08:05:19 +0200, Bertel wrote:

>> men hvordan forholder det sig for tiden med mail?
>> Kan man uden videre sende og modtage mails på et æøå-domæne?

> Nej.

> Det ville undre mig om det nogensinde bliver muligt, men rent
> teoretisk kan man godt i et mailprogram implementere det samme
> fusk som man laver i browserne.

Det er nu også en sandhed med modifikationer at det er rent teoretisk.

Hvis man har GNU libidn installeret virker IDNA f.eks. fint i Gnus.

Her er et eksempel på headerne den resulterende email, da jeg tastede
"test@frækkefrølår.example.com" ind i To: feltet:

From: asjo@koldfront.dk (Adam =?iso-8859-1?Q?Sj=F8gren?=)
To: test@xn--frkkefrlr-d3ae5t.example.com
Subject: Test af =?iso-8859-1?Q?=E6=F8=E5?= i To:
Date: Sun, 23 Aug 2009 09:52:11 +0200
User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.5-b29 (linux)

(Envelope-adressen blev naturligvis også IDNA-kodet, så transport-laget
- MTA'erne - aldrig ser de danske tegn, ganske som når webbrowsere
bruger IDNA).

De to variable der styrer dette er hhv. for visning og afsending:

,----[ C-h v gnus-use-idna RET ]
| `gnus-use-idna' is a variable declared in Lisp.
| -- loaded from "gnus-art"
|
| Value: "/usr/bin/idn"
|
| Documentation:
| Whether IDNA decoding of headers is used when viewing messages.
| This requires GNU Libidn, and by default only enabled if it is found.
`----

,----[ C-h v message-use-idna RET ]
| `message-use-idna' is a variable declared in Lisp.
| -- loaded from "message"
|
| Value: t
|
| Documentation:
| Whether to encode non-ASCII in domain names into ASCII according to IDNA.
| GNU Libidn, and in particular the elisp package "idna.el" and
| the external program "idn", must be installed for this
| functionality to work.
`----


Mvh.

Adam

--
"The unavoidable price of reliability is simplicity" Adam Sjøgren
asjo@koldfront.dk

Klaus Jørgensen (23-08-2009)
Kommentar
Fra : Klaus Jørgensen


Dato : 23-08-09 09:52

Adam Sjøgren submitted this idea :
> Her er et eksempel på headerne den resulterende email, da jeg tastede
> "test@frækkefrølår.example.com" ind i To: feltet:
>
> From: asjo@koldfront.dk (Adam =?iso-8859-1?Q?Sj=F8gren?=)
> To: test@xn--frkkefrlr-d3ae5t.example.com
> Subject: Test af =?iso-8859-1?Q?=E6=F8=E5?= i To:
> Date: Sun, 23 Aug 2009 09:52:11 +0200
> User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.5-b29 (linux)

Én ting er jo hvad klienten gør - eller ikke gør. Jeg tror snarere at
der kan opstå problemer på alle de forskellige mailservere og
SMTP-gateways der findes på markedet.

--
/klaus



Bertel Lund Hansen (23-08-2009)
Kommentar
Fra : Bertel Lund Hansen


Dato : 23-08-09 10:04

Klaus Jørgensen skrev:

> Én ting er jo hvad klienten gør - eller ikke gør. Jeg tror snarere at
> der kan opstå problemer på alle de forskellige mailservere og
> SMTP-gateways der findes på markedet.

Jeg forstår ikke hvad du mener. Æøå virker overhovedet ikke på
protokolniveau - hverken ved mail- eller websideadresser.

Browsere modtager æøå fra brugeren og omsætter det til ascii-tegn
som ingen server kløjes i. Nu har Adam Sjøgren beskrevet at et
lignende stunt kan implementeres i Gnus når der sendes mails.

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

Adam Sjøgren (23-08-2009)
Kommentar
Fra : Adam Sjøgren


Dato : 23-08-09 10:00

On Sun, 23 Aug 2009 10:51:31 +0200, Klaus wrote:

> Adam Sjøgren submitted this idea :

>> To: test@xn--frkkefrlr-d3ae5t.example.com
[...]

> Én ting er jo hvad klienten gør - eller ikke gør. Jeg tror snarere at
> der kan opstå problemer på alle de forskellige mailservere og
> SMTP-gateways der findes på markedet.

Så har du vist misset hvordan IDNA/punycode virker?

Pointen med det system er netop at serverne kan være ligeglade (om det
så er den bedste strategi eller ej er nok stadig uklart).

Det er derfor det "kun" var webbrowserne der skulle lære noget nyt, for
at www-IDN-domæner kom til at virke.

Ditto for email.


Mvh.

Adam

--
"The unavoidable price of reliability is simplicity" Adam Sjøgren
asjo@koldfront.dk

Klaus Jørgensen (23-08-2009)
Kommentar
Fra : Klaus Jørgensen


Dato : 23-08-09 11:36

Adam Sjøgren formulated on søndag :
> On Sun, 23 Aug 2009 10:51:31 +0200, Klaus wrote:
>
>> Adam Sjøgren submitted this idea :
>
>>> To: test@xn--frkkefrlr-d3ae5t.example.com
> [...]
>
>> Én ting er jo hvad klienten gør - eller ikke gør. Jeg tror snarere at
>> der kan opstå problemer på alle de forskellige mailservere og
>> SMTP-gateways der findes på markedet.
>
> Så har du vist misset hvordan IDNA/punycode virker?
>
> Pointen med det system er netop at serverne kan være ligeglade (om det
> så er den bedste strategi eller ej er nok stadig uklart).
>
> Det er derfor det "kun" var webbrowserne der skulle lære noget nyt, for
> at www-IDN-domæner kom til at virke.
>
> Ditto for email.

Jeg er udemærket klar over at æøå bliver konverteret til punycode på
klientsiden, men hvis en mailserver skal håndtere flere domæner, er man
jo nødt til at definere både domænenavn og brugernavn i serverens
adresseliste. Dette skulle så gøres i punycode - medmindre serverens
administrationsmodul kan håndtere IDN.

En SMTP-gateway der distribuerer indkomne mails til forskellige
mailservere baseret på domænet, skal jo så også gøre det på grundlag af
punycode. Her skal administratoren igen selv konveretere det under
opsætningen - medmindre administrationsmodulet konverterer det
indtastede unicode til punycode.

Jeg er ingenlunde ekspert i mailservere, men jeg har bare grublet lidt
over de forskellige led i mailtransporten og det arbejde der måtte være
med opsætningen, så det kan jo være at problemet i praksis er
væsentligt mindre (og måske ikke eksisterende som du så mener).



--
/klaus



Adam Sjøgren (23-08-2009)
Kommentar
Fra : Adam Sjøgren


Dato : 23-08-09 11:37

On Sun, 23 Aug 2009 11:04:14 +0200, Bertel wrote:

> Browsere modtager æøå fra brugeren og omsætter det til ascii-tegn
> som ingen server kløjes i. Nu har Adam Sjøgren beskrevet at et
> lignende stunt kan implementeres i Gnus når der sendes mails.

Mutt har i øvrigt haft IDNA-support siden 2003:

* http://www.mutt.org/doc/devel/UPDATING

Der er først kommet en færdig RFC (der dækker mere end bare
domænenavnsdelen) for et lille år siden, så derfor har
Thunderbird-folket diskuteret det (on-and-off) i 7 år uden at blive
færdige endnu:

* https://bugzilla.mozilla.org/show_bug.cgi?id=127399

Der findes 3. parts plugins til Outlook og Outlook Express:

* http://www.idnnow.com/whatis.jsp

Det kan være det er et 'stunt', ikke desto mindre er det også i et par
RFC'er:

* http://www.faqs.org/rfcs/rfc3490.html
* http://www.faqs.org/rfcs/rfc5336.html

rfc2047-kodning af header-linier er heller ikke kønt, men efterhånden
understøtter alle email-klienter det.


Mvh.

Adam

--
"The unavoidable price of reliability is simplicity" Adam Sjøgren
asjo@koldfront.dk

Adam Sjøgren (23-08-2009)
Kommentar
Fra : Adam Sjøgren


Dato : 23-08-09 11:41

On Sun, 23 Aug 2009 12:36:23 +0200, Klaus wrote:

> klientsiden, men hvis en mailserver skal håndtere flere domæner, er
> man jo nødt til at definere både domænenavn og brugernavn i serverens
> adresseliste. Dette skulle så gøres i punycode - medmindre serverens
> administrationsmodul kan håndtere IDN.

Præcis.

Man behøver altså overhovedet ikke at ændre server-software'n, hvis man
ikke gider. Til gengæld skal administratoren så jonglere med punycode.

Præcis som det er med DNS og webservere.

> En SMTP-gateway der distribuerer indkomne mails til forskellige
> mailservere baseret på domænet, skal jo så også gøre det på grundlag
> af punycode. Her skal administratoren igen selv konveretere det under
> opsætningen - medmindre administrationsmodulet konverterer det
> indtastede unicode til punycode.

Lige præcis.

Ideen er åbenbart at det må være nemmere at ændre klienter end servere.

> Jeg er ingenlunde ekspert i mailservere, men jeg har bare grublet lidt
> over de forskellige led i mailtransporten og det arbejde der måtte
> være med opsætningen, så det kan jo være at problemet i praksis er
> væsentligt mindre (og måske ikke eksisterende som du så mener).

Jeg kan ikke se at problemet er anderledes end for webservere?


Mvh.

Adam

--
"The unavoidable price of reliability is simplicity" Adam Sjøgren
asjo@koldfront.dk

Klaus Jørgensen (23-08-2009)
Kommentar
Fra : Klaus Jørgensen


Dato : 23-08-09 13:26

Adam Sjøgren formulated the question :
> Man behøver altså overhovedet ikke at ændre server-software'n, hvis man
> ikke gider. Til gengæld skal administratoren så jonglere med punycode.

Man behøver heller ikke at ændre klient-softwaren hvis man ikke gider -
til gengæld skal brugeren så jonglere med punycode.

Hvis man som bruger eller administrator et eller andet sted i
brugen/opsætningen manuelt skal konvertere til/fra punycode, vil jeg
mene at det pågældende led ikke er IDN-kompatibelt.

--
/klaus



Adam Sjøgren (23-08-2009)
Kommentar
Fra : Adam Sjøgren


Dato : 23-08-09 13:34

On Sun, 23 Aug 2009 14:26:02 +0200, Klaus wrote:

> Hvis man som bruger eller administrator et eller andet sted i
> brugen/opsætningen manuelt skal konvertere til/fra punycode, vil jeg
> mene at det pågældende led ikke er IDN-kompatibelt.

Hvis du ønsker at bruge den definition af 'kompatibel', så fint nok for
mig.

Det lyder som om vi er enige om to brugere med email-klienter der kan
IDNA ingen problemer får ud af at en eller flere MTA'er imellem dem
efter din definition ikke er 'IDN-kompatible', hvilket er pointen med
den strategi der er valgt.


Mvh.

Adam

--
"The unavoidable price of reliability is simplicity" Adam Sjøgren
asjo@koldfront.dk

Søg
Reklame
Statistik
Spørgsmål : 177579
Tips : 31968
Nyheder : 719565
Indlæg : 6409073
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste