Sendmail + ETRN

[Dan Lukes]

Peter Rosa wrote:

>>Ale nebylo by nejjednodusi proste v cronu pravidelne spoustet nejakej
>>kratouckej skript, kterej se telnetem pripoji na ten server a udela tam

> Jasne, to som skusil ako prve:
> #!/bin/sh
> OURSITE=@domena
> MAILSERVER=mail-relay
> TELNET=/usr/bin/telnet
> PORT=25
> echo "etrn $OURSITE" | $TELNET $MAILSERVER $PORT
> exit 0
> 
> Problem je, ze to vzdy vypise "Connection closed by remote host" a dost.
> Alebo je to spravna hlaska ?

	No, tahle "hlaska" se vypisuje kdyz telnet uzavira spojeni (respektive, 
kdyz ho uzavrela protistrana). Nemelo by to ale byt to jedine, co telnet 
vypise ...

	Kazdopadne, v teto chvili si nejsem jist, zda je telnet schopen spravne 
pracovat "v davkovem" rezimu, a krome toho, telent protokol je pomerne 
sofistikovany protokol - a neni totozny s "RAW" spojenim, ktere 
potrebujete pro SMTP. Mohlo by se tedy stat, ze "protiserver" je zmateny 
z telnet-hanshakingu, pripadne je primo aktivne nastaven, aby telnet 
spojeni odmital (to je, samozrejme, pouze hypoteza).

	Kazdopadne, v portech/packages mate port/package "socket-1.1", coz je 
presne to, co provede "dalkove spojeni" aa propoji ho se svym vstupem a 
vystupem. Takze je to na podobnou aplikaci pravdepodobne "bezpecnejsi" vec.

	K tomu je potreba poznamenat take, ze server se nemusi bavit s 
klientem, ktery nedodrzuje pravidla SMTP protokolu (v tomto pripade 
schazi "HELO"), pripadne nemusi byt ochoten k "ETRN" vubec (nebo jen po 
autentizaci a pod). Jak je na tom ten konkretni server je potreba 
vyzjistit u jeho spravce, pokud se to nepodari vyresit "pokusem". Jinak 
- ja si nikdy nepamatuju, jestli u parametru ETRN ma nebo nema byt ten 
zavinac (ja tam vzdy pisu obe dve varianty, tedy dva ETRN ... ;-( ).

	Jinak ale - ac to uz neni primo "o FreeBSD", zkusim mirne a strucne 
naznacit, jak probiha dorucovani posty (a asi lze jen doporucit, abyste 
si to trochu nastudoval). Mail se dodava podle MX zaznamu (neexistuje-li 
pak podle A, ktere se povazuje za MX s prioritou 0) na nektery z MX 
stroju s nejlepsi prioritou. Nepodari-li se takovy stroj dosahnout, tak 
na stroje s priritou vyssi. Pokud uz klient sam je na "MX" seznamu, pak 
nikdy nedorucuje dopis na stroj se stejnou nebo nizsi prioritou nez ma 
sam. Pokud se nelze spojit na zadny vyhodujici server, zustava dopis ve 
fronte (maximalne po spravcem urcenou dobu), pokusy o doruceni se 
opakuji ve spravcem urcenych intervalech.

	Pokud se zprava dostala na stroj, ktery ma MX s nejnizsi prioritou v 
seznamu MX (coz nemusi byt nutne nula), pak je to zprava lokalni, ledaze 
je v tabulce "mailtertable" uvedeno,z e se ma dorucit jinam (tohle plati 
jen pro sendmail). Pokud se ma dopis dorucit nekam jinam, pak se tak 
deje ve spravcem stanovenych intervalech a po spravcem stanovenou dobu 
(pokdu se to nepovede hned).

	Jinymi slovy - pokud to vase "vnejsi" MX ma horsi prioritu nez to vase 
vnitrni, tak se i bez ETRN bude jednou za cas pokouset dorucit dopisy 
dovnitr - tim ETRN to ale lze urychlit (zajistit, ze se pokusi hned a 
nez az ve stanovenou dobu). Pokdu bdue mit vnejsi MX nejnizsi priprotu, 
ale mailertable na nem bude prislunou postu smerovat na MTA "dovnitr", 
bude to fungovat stejne.

	Rozdil mezi temito resenimi je v ohleduplnosti vuci uzivatelum 
Internetu - pokdu je vas "vnitrni" MX prevazen dostupny a vypadky jsou 
"vyjimecne", pak je vhodne reseni "vevnitr nejlepsi MX/venku horsi". 
Tohle resni neni navic "MTA" specific (a ja nevim, jestli vas vnejsi MTA 
je sendmail). Pokud by vypadky vnitrniho MTA byly castejsi nez 
vyjimecne, pak lze takovou konfiguraci vnimat jako bezohlednou a 
vhodnejsi je pouzit "mailertable" ...


						Dan