Záhadná Iva na Ignum.cz

13.1.2008 01:34 | Přečteno: 1551× | obecně

Hostuji u Ignumu doménu klienta, nemusíme být konkretní, dejme tomu třeba abcdef.cz, u níž jsem musel tento týden řešit zajímavý problém.

Ignum nabízí celkem standardní službu - přes webové rozhraní si nastavit přeposílání emailu na jiné emailové adresy, což můj klient také využíval. Potud nic zvláštního a vše fungovalo jak má, ovšem jen do té chvíle, než jsem do přesměrování přidal další adresu, a to ivana.hubackova@abcdef.cz.

Poté začalo kromě přeposlaného emailu na všechny cílové adresy chodit i další email z chybovou hláškou: Local delivery error: iva. Pokud jsem email ivana.hubackova@abcdef.cz z přesměrován vyjmul, chyba chodit přestala. Hned mě tedy napadlo, že v emailu ivana.hubackova@abcdef.cz je někde další přesměrování, které je chybně nastaveno jen na účet iva, jenže ejhle, nic takového tam nebylo a když jsem už bezradný zkusil celý účet zrušit a vytvořit znovu a ani to nepomohlo, napsal jsem odevzdaně na helpdesk@ignum.cz a nestačil se smát nad došlou odpovědí (čtěte ze zdola):

Dobry den,

bohuzel dalsi takto dlouha adresa se jiz do tohoto jednoducheho preposilani zprava nastavit neda.
(system ji jiz zkrati na iva.....) a doruceni neprobehne. Jako reseni pri preposilani na vice nez
cca 5 (zalezi i na delce emailu) adresatu je jiz uziti aliasu ci adresni skupiny, ktere jsou pro tyto
ucely vytvorene. Alias je mozne nastavovat pod Vasim root uctem. Skupinu Vam muze aktivovat nas helpdesk.

-- 
S pozdravem,
Jiri Obr, junior specialista technicke podpory
_____________________________________________ 
IGNUM s.r.o. jeste lepsi hosting www.ignum.cz Thamova 18, Praha 8, 18600, 
helpdesk@ignum.cz T: 8001IGNUM, 603111111, 604111111, 296332211

> Dobry den,
> potreboval bych pomoct vyresit tuto zahadu.
>
> Vytvoril jsem emailovy ucet trac@abcdef.cz, ktery prichozi emaily dale preposila na nekolik
> adres v @abcdef.cz, to je bez problemu.
>
> Pokud vsak do preposilani pridam jeste nove vytvoreny email ivana.hubackova@abcdef.cz, zprava 
> se preposle i na nej, ale zaroven vsem ostatnim adresatum prijde chybovy email, ktery 
> preposilam v priloze.
>
> Muzete zkusit vystopovat, kde je problem?  Pokud poslu email primo na email
> ivana.hubackova@abcdef.cz, tak zadna chyba neprijde.

       

Komentáře

[Luk]

Co je na té odpovědi divného? Nepochopil jsem to

[Max]

Že mají opravdu pěkná omezení ? :D
Zdar Max

[Luk]

Nevím nic o tom, jak je to řešeno. Ale pokud je to uděláno primitivně (protože se nepočítalo s tím, že to někdo bude používat k rozesílání na x adres), pak na tom opravdu nevidím nic divného.

[xkucf03]

Vypadá to, že místo aby měli každou adresu v databázové tabulce v jedné řádce a připojené cizím klíčem k zdrojové adrese, tak mají všechno v jedné tabulce a cílové adresy namaštěné pěkně v jednom sloupečku oddělené nějakým znakem (mezera, středík...). To mi teda divné přijde. No asi někdo z nich chyběl ve škole, když se probíraly databáze (nebo tam pro jistotu vůbec nechodil).

[Michal Kašpar]

No ono až z té školy odejdete, tak možná zjistíte, že je spousta dobrých důvodů to s tou normalizací dat v reálné databázi nepřehánět.

[xkucf03]

Mají někde v dokumentaci, že suma délek e-mailových adres + oddělovací znaky musí být kratší než nějaké číslo (rozměr sloupečku)? Předpokládám, že ne, protože jinak by se jim zákazníci vysmáli. V tom případě se ale systém nechová podle očekávání a je špatný bez ohledu na normalizaci.

[Josef Kufner]

A jaké jsou ty důvody?

[happy barney]

je licencia na počet tabuliek dobrý dôvod?

[dada]

Na starych unixech (a z duvodu kompatibility nekdy i dnes) je omezen pocet znaku v aliasu na 256 znaku. Ty dalsi se rezou. Obvykle reseni tohoto omezeni spociva v definovani dalsich aliasu podle prikladu:

neco: neco1, neco2
neco1: adresa1, adresa2
neco2: adresa3,adresa4

[Zdeněk Štěpánek]

pokud tam mas nastavene neco ve smyslu:

firma@firma.cz -> adam@firma.cz, eva@firma.cz, pepa@firma.cz, jozin@firma.cz....

tak to je standardne jeden radek v databazi. pokud ma druhej sloupec nevhodny datovy typ, tak je logicky ze narazis na omezeni.

Ja mel v databazi stejnej problem, pak jsme zmenil datovy typ, data z asi 10 subaliasu sesypal do jednoho radku a je to.

Zdenek