Newsgroup: it.comp.reti.ip-admin
Titolo: Accodamento? Push? Come chiama questo servizio il vs provider?

Il mio provider filtra con antivirus ed antispam la posta destinatata
al mio dominio e la inoltra, pulita, al mio mailserver interno (che
lato firewall apre la porta 25 solo verso il mio provider). Se il mio
server interno è offline per manutenzione, il mio provider tiene in
pancia la mia posta per x ore o giorni; quando il mio server torna
online il mio provider mi invia automaticamente la posta (in modalità
push, non etrn, cioè senza che sia il mio server a farsi vivo).
Come chiama il vostro provider questo servizio? Relay posta? Redirect?
Accodamento?
E quanto ve lo fa pagare?
Grazie

 Relay posta? Redirect? Accodamento?
� un banale servizio MX nulla di pi�; per quanto
riguarda il costo, non so che dirti, io uso i miei
mailservers

 Accodamento?
Io (che sto dalla parte del provider che filtra e consegna) lo chiamo
semplicemente filtraggio sugli MX.
D'altra parte, essendo SMTP un protocollo store-and-forward, se tu sei
down e non posso fare il forward, mi fermo allo store. :-)
Poi si tratta solo di "tunare" quanto a lungo pu� durare questa fase: se
i numeri sono grossi, queste mail non possono restare in groppa ai
sistemi che operano il filtraggio, per cui c'� un pool di spooling
dedicato a tenere in panza le mail che non � possibile consegnare
immediatamente.
Per completezza del quadro:
http://www.spin.it/?TYPE=2&ID=90
In linea di massima, quindi, non � che il cliente paga di pi� perch�
mantengo le mail in coda anche quando il suo mailserver � down: fa parte
del servizio, anche sul piano strettamente tecnico...
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 E quanto ve lo fa pagare?
Se non ricordo male 3$ al mese per casella.
-- 
Vide

> Se non ricordo male 3$ al mese per casella.
Hm... costa meno Google, e non ha limitazioni
sulle caselle di posta :)

 mailservers
Quindi lato configurazione dns tu hai i tuoi mailservers come record
mx? Ne hai più di uno per bilanciare il traffico e/o per evitare che
il fermo macchina di uno di loro sospenda il servizio di posta?
Curiosità: sono mailserver su macchine virtuali installate su un solo
server fisico? O hai bilanciato anche i server fisici?
Grazie

 In linea di massima, quindi, non è che il cliente paga di più perchè mantengo le mail in coda anche quando il suo mailserver è down: fa parte del servizio, anche sul piano strettamente tecnico...
Però scusa fa differenza se internamente ho mille caselle piuttosto
che dieci. La posta che trattieni quando il mailserver è down
(probabilmente) rischia di essere tanta.

 server fisico? O hai bilanciato anche i server fisici?
Qui sono due macchine virtuali su un RAID condiviso fra due server 
fisici (VM host).
Ciao
Luca

 sulle caselle di posta :)
Mmmh Google Apps for Business la edizione a pagamento è più caro di 
MessageLabs (l'antispam che usiamo qui), te lo dico perchè abbiamo/avevamo 
in progetto di migrare a GApps però per il momento non abbiamo continuato. E 
con GApps sì che paghi la tua bella quota per ogni utente che attivi (ok, 
puoi creare alias sulle stesse caselle ma son casi rari).
-- 
Vide

 (probabilmente) rischia di essere tanta.
Nulla di pi� facile, ma � un aspetto che si gestisce facilmente con la
giusta progettazione.


down e non posso fare il forward, mi fermo allo store. :-)
E come eviti il backscatter causato dagli utenti inesistenti?
-- 
ciao, |
Marco | The Internet is full. Go away.  -- Joel Furr

 E come eviti il backscatter causato dagli utenti inesistenti?
Con postfix si puï¿œ usare address_verify_* che funziona egregiamente in
questo caso. Se il destinatario non ï¿œ giï¿œ in cache e la verifica va in
timeout (AKA l'host di destinazione ï¿œ down), postfix rifiuta con un 450.
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 timeout (AKA l'host di destinazione ï¿œ down), postfix rifiuta con un 450.
Esatto, dove tocca (ovvero dove non ho la possibilitï¿œ di avere una lista
di destinatari esistenti).


 timeout (AKA l'host di destinazione ï¿œ down), postfix rifiuta con un 450.
O quello (VRFY/EXPN) oppure, ammesso che il sistema frontend e
quello backend lo supportino, si puï¿œ anche usare LDAP; in tal caso o
si apre LDAP sul backend per permettere queries dal front-end oppure
si usa un LDAP sul lato frontend che replichi i dati del backend; in questo
secondo caso si puï¿œ ANCORA fare reject su recipients inesistenti; ad
ogni modo, se non c'ï¿œ verifica, il 4xx ï¿œ l'unico approccio accettabile

timeout (AKA l'host di destinazione ï¿œ down), postfix rifiuta con un 450.
Lo so, lo faccio. Ma mi pare che neghi lo scopo discusso in questo
thread.
(A parte che sono convinto che un MX secondario sia una cosa inutile nel
2010.)


 quello backend lo supportino, si puï¿œ anche usare LDAP
O sql, o file di testo, o quel che ti pare.
MA si parla di sistemi remoti che parlino *SMTP*...


 2010.)
100% agree. Ma se hai clienti che hanno un mailserver in casa
(tipicamente su un PC come gli altri sotto la scrivania di qualcuno)
dietro una ADSL, o metti in piedi qualcosa tipo quello sopra descritto e
cerchi di gestirlo minimizzando gli effetti collaterali dove possibile,
o li fai passare per maildrop + fetch pop3 e balordaggini simili...


 MA si parla di sistemi remoti che parlino *SMTP*...
Uhm SQL � un altro discorso, io parlavo proprio di verifica "realtime"
del recipient usando una connessione "dedicata" verso il backend
e, nel caso in cui questo sia offline rifiutare appunto il messaggio con
un tempfail; per quanto riguarda il discorso sistemi remoti, come ho
detto, una soluzione potrebbe essere quella di avere un OpenLDAP
locale che venga sincronizzato regolarmente con il backend (lato
cliente) in modo da permettere la verifica diretta dei recipients
senza aggiungere traffico; in quest'ultimo caso anche se il backend
fosse offline potresti COMUNQUE verificare i recipients

 senza aggiungere traffico;
Sicuro.
Cosa di cui sarebbe in grado, nell'ipotesi ottimistica, il 2% della
clientela (ma *molto* ottimistica).
Smettere di parlare di massimi sistemi per sentito dire e concentrarsi
su scenari realistici basati sull'esperienza diretta aiuterebbe a
rendere utili i thread, per�...


 rendere utili i thread, per�...
Sto usando VRFY/EXPN insieme con LDAP da alcuni ANNI senza
alcun tipo di problema... vedi tu

 alcun tipo di problema... vedi tu
Su migliaia di domini in parallelo, appoggiati su centinaia di
mailserver diversi, che eseguono qualcosa che non sai nemmeno che cosa
sia e a cui non hai accesso?
Mi compiaccio per la qualit� della macumba, ma continuo a favorire
metodi pi� trasparenti per i miei utenti ed altrettanto funzionanti.
Preferisco vivere, di norma...


> Su migliaia di domini in parallelo, appoggiati su centinaia di
Nel mio caso sono di meno... diciamo nell'ordine delle centinaia,
anche se sparsi in giro per il globo terraqueo e... no, non ho avuto,
da qualche tempo a questa parte (anni) problemi particolari tranne
in alcuni, sporadici, casi specifici per i quali sono stati necessari
alcuni "aggiustamenti" ma, in generale non ho avuto problemi; che
debbo dirti, sar� fortunato... o probabilmente il tipo di realt� che mi
trovo a gestire sono diverse da quelle che gestisci tu; non lo so
Tutto "l'ambarad�n" � molto diretto e considerando che di norma
chi sta "dall'altra parte" ha uno straccio di "admin" o nei casi
peggiori
richiede assistenza diretta alla configurazione, i problemi si risolvono
abbastanza facilmente