Egyik ügyfelünk anyacége leszólt, hogy “Béláim, legyetek kedvesek már használni a céges előírás szerinti formát a levelezési címlistában, köszi”.
Kérték, megcsináltuk, hátradőltem. Túlontúl hamar.
Pár nap múlva jöttek a reklamációk: néhány külsős partner nem tud levelet küldeni belsős címekre. Első reflexből visszaírtam, hogy “sorry, de tudomásom szerint az Exchange szerver nagy ívben nem foglalkozik az AD általunk módosított display name paraméterével, itt maximum véletlenek tragikus összejátszásáról lehet szó”. Pedig megtanulhattam volna az eddigi szívásokból, hogy nem jó első reflexből válaszolni, még akkor sem, ha maximálisan biztos vagyok magamban.
A módosítás lényege ugyanis az volt, hogy megvesszőztük a nevet. Azaz ami eddig “Kis Pál” volt, az mostantól “Kis, Pál” lett. Jó, persze fel lehet szisszenni, de hangsúlyozom, ez display name – azaz az a felület, melyet az AD a felhasználónak mutat. A levelezés nyilván a proxyaddresses alapján megy.
És ez bizony így is van. Egészen addig, amíg csak a szerver játszik. Egy igazi admin itt be is hunyja a szemét, mert ami a szervereken túl van, az már a gyehenna. Levelezőkliensek. Fúj.

Nos, boncoljunk levelet.
Egy közönséges email áll egyfelől borítékból és tartalomból. A borítékon van egy feladó (ezt adjuk meg a MAIL FROM smtp paranccsal) és van egy címzett (ezt adjuk meg az RCPT TO smtp paranccsal). A tartalom – mely a DATA smtp parancson belül utazik – meglehetősen összetett valami, pl. meglepő módon neki is van FROM mezője. És itt jönnek be a képbe a levelezőkliensek. A boríték kitöltésével nincs gond, azt kutyakötelességük ugyanúgy kitölteni – de a belső FROM mező már szabad préda. Ma már teljesen elterjedt forma pl. ez: “displayname” <emailaddress>.
Jó, ezt tudjuk. Mi a probléma?
Csináljunk egy kísérletet. Küldjünk magunknak egy levelet, telnettel.
telnet smtp.sajat.domain.hu 25
helo
mail from: nagymagyartarka@sajat.domain.hu
rcpt to: sajat.email@sajat.domain.hu
data
from: “nagymagyar, tarka” <sajat.email@sajat.domain.hu>
subject: apuhodmedbe
pamparampampam
.
quit
És most nézzük meg, mit csináltunk. Küldtünk magunknak egy levelet, melynek a borítékjára feladóként ráírtunk egy fantom címet (nagymagyartarka@sajat.domain.hu), címzettként pedig magunkat (sajat.email@sajat.domain.hu). A trükk ott van, hogy a belső FROM mezőbe beírtuk a saját címünket!
A levelet természetesen meg fogjuk kapni. Nyomjunk rá egy reply-t! Bizony, azt fogjuk látni a címmezőben, hogy nagymagyar, tarka <sajat.email@sajat.domain.hu>, kedvesen aláhúzva. Reménykedőbbek még mondhatják, hogy jó-jó, az Outlook odamaszkol valamit a címsorba, de küldéskor úgyis az email Return-Path mezőjét fogja használni. Ha már itt járunk, nézzük is meg. Nyissuk meg az eredeti levelet, view/options, rögtön az első sorban ott fog vigyorogni, hogy Return-Path: nagymagyartarka@sajat.domain.hu. Tehát, gondoljuk naívan, ha ezt a replyt elküldjük, akkor ez berepül a fekete lyukba – feltéve, hogy valamelyik sunyi kollégánk időközben nem hozott létre nagymagyartarka címet.
Van egy rossz hírem. Az emailt meg fogjuk kapni. A belső FROM értéke űbereli a borítékra írt címet. És ebben a FROM mezőben már szerepel a display név értéke.
Persze még mindig nem látszik, mi itt a baj. Oké, ott van a címben egy vessző. Na és? Kellően körbezártuk idézőjellel, kedves levelezőkliens, tessék nyugodtan nem figyelembe venni.
Most visszaásunk a múltba. Van egy remek oldal, ahol le van írva, milyen karakterek szerepelhetnek az emailcímben. A vesszőre spec azt írja, hogy “megbolondultál?”. Az ugyanis az RFC822 szerint elválasztó karakter. Igenám, de az RFC822-t 2001-ben érdemei elismerése mellett nyugdíjazták, bejött helyette az RFC2822, mely már megengedi a vesszőt, feltéve, hogy idézőjelek között van.
Most már közel vagyunk. Semmi másra nincs szükségünk, mint egy 2001 előtti levelezőkliensre, melynek halvány fogalma sincs az RFC2822-ről. Mit fog csinálni a szerencsétlen, ha ez kerül a címsorába, hogy “Kis, Pál” <kispal@sajat.domain.hu>? Azt fogja mondani, hogy ez két cím: “Kis az egyik, Pál” <kispal@sajat.domain.hu> a másik. Aztán nekiáll visítozni, hogy nem találja a címeket.
Aki szeret kísérletezgetni, nekiugorhat a Freemail webes felületének, remekül hozza a hibát – legalábbis a múlt héten még hozta.

Szuper, megvan a gizda. Mit lehet vele csinálni?

  1. Szólunk a multi Anyucinak, hogy ne legyen vessző a displaynévben. Oké, oké, tudom, csak a teljesség kedvéért írtam ide.
  2. Beállítjuk Exchange organizáció szinten, hogy ne küldje el a display nevet, csak az email címet. (Message format ablak, valamelyik fül.) Nekem, kockafejűnek, ez teljesen jó megoldás lett volna, de az üzlet egyből Apage Satanas-t kiáltott.
  3. Kivezetjük az ősembereket a barlangból a fényre. Magyarul, nekiállunk supportálni az ügyfél üzleti partnereit is, hogyan kell beállítaniuk azt a többezer fajta levelezőklienst, amelyekből néhány nem tudja lekezelni ezt a szituációt.
    Az élet szép.

[Update]
Azóta kisérleteztem egy kicsit és rájöttem, hogy nem ilyen egyszerű a helyzet. Könnyű lenne mindent a kliensre tolni, de mégsem ő tehet a balhéról – hanem a levelezőszerver. A kliens átadja a megfelelő smtp parancsot – nagyjából ugyanúgy – de a szerver az, mely – feltéve, hogy nem ismeri, vagy nem jól ismeri a szabványt -, belebukik a vesszőbe.
Tényleg érdekes.