mutt e sendmail

[samiel]

C'è qualcuno qui che invia le mail con mutt e sendmail?
Le mail inviate quando il pc non è connesso a Internet,
quanto ci mettono a voi a partire da mutt?

Thanx
M.

[masalapianta]

C'è qualcuno qui che invia le mail con mutt e sendmail?
Le mail inviate quando il pc non è connesso a Internet,
quanto ci mettono a voi a partire da mutt?

Thanx
M.

non uso nessuno dei due, comunque dipende da come e' configurato sendmail, in particolare da che tempo di retry e' stato impostato per le mail in deferred; btw puoi forzarlo a fare il flushing della coda manualmente con sendmail -q

[samiel]

Forse non mi sono spiegato, o forse non ho capito bene
la tua risposta. Ma io non mi riferivo al tempo che impiega
sendmail per inviare. Quando termino una mail con Mutt
e la spedisco in un momento in cui sono senza connessione,
mutta la invia a /var/spool/clientsqueue. Lasciamo stare
come poi sendmail la spedisce da qui. Da quando premo
y[es] in Mutt a quando la mail raggiunge /var/spool/clientsqueue
passa circa un minuto. Non è troppo?
Spero di essermei spiegato... Grazie

M.

[linus.bash]

Ciao,

uso sendmail via apache e pine da shell...di solito se commetto errori nel destinatario o nelle configurazioni l'e-mail ritorna indietro da sendmail a pine dopo 4ore.

Penso che nel tuo caso sia lo stesso.

Ciao.

PS: per 4ore (voglio dire) l'invio è valido...se non ti connetti in rete il tempo finisce ed anche l'invio...quindi hai 4ore di tempo.

Poi non so dove cambiare il timeout.

[samiel]

No, il mio problema è un altro. Ripeto: scrivo una mail
con Mutt, il quale mi chiede se voglio posporla o inviarla
subito. Rispondo con y[es] che voglio inviarla subito.
Però non sono connesso. La mail finisce nella coda
di invio, che è /var/spool/clientsqueue e non viene spedita,
ma trattenuta in attesa che sia attivata la connessione
a Internet. A me interessa solo il passaggio che porta
la mail da Mutt a /var/spool/clientsqueue. Qui non vengono
rilevati errori, perché il messaggio staziona lì e non può
ovviamente essere mandato indietro; le 4 ore non c'entrano.
Io mi chiedo semplicemente: perché Mutt impiega ben
un minuto per inviare la mail a /var/spool/clientsqueue?
Certo, deve leggere il record MX della mail,
ma ci impiega così tanto tempo?

M.

[masalapianta]

Forse non mi sono spiegato, o forse non ho capito bene
la tua risposta. Ma io non mi riferivo al tempo che impiega
sendmail per inviare. Quando termino una mail con Mutt
e la spedisco in un momento in cui sono senza connessione,
mutta la invia a /var/spool/clientsqueue. Lasciamo stare
come poi sendmail la spedisce da qui. Da quando premo
y[es] in Mutt a quando la mail raggiunge /var/spool/clientsqueue
passa circa un minuto. Non è troppo?
Spero di essermei spiegato... Grazie

M.

/var/spool/clientsqueue? sicuro non sia invece /var/spool/clientmqueue (la coda in cui vengono depositato le mail inviate da locale col comando sendmail)? btw se e' /var/spool/clientmqueue il colpevole e' probabilmente mutt (in quanto il comando sendmail quando invocato per inviare una mail da locale, scrive la mail nella coda in maniera sincrona e non si mette a bufferizzare e poi a fare flush ogni tot); vedi nella documentazione di mutt se c'e' un parametro di configurazione che permetta di scrivere nella coda in maniera sincrona le mail in uscita (probabilmente, anche se mi sembra una cappellata, mutt per ottimizzare gli invii quando si mandano molte mail contemporaneamente, bufferizza tot mail e poi ogni tanto fa il flushe e le scrive nella coda tutte insieme)

[masalapianta]

Certo, deve leggere il record MX della mail,
ma ci impiega così tanto tempo?
M.

non conosco mutt ma mi sembrerebbe ben strano se si mettesse a fare questi controlli, in quanto si appoggia ad un mta locale per l'invio delle mail, quindi dovrebbe delegare i controlli di questo tipo al mta stesso

[samiel]

Allora ho scoperto che in effetti Mutt non controlla
il record MX della mail. Sì, la dir è /var/spool/clientmqueue
(refuso...). Esiste un parametro da passare a Mutt
per evitare il ritardo, che consente l'invio istantaneo:
set sendmail_wait=-1. Dici che Sendmail si comporta
correttamente? Non è che cerca di fare un lookup
e fallisce?

Grazie
M.

[masalapianta]

Allora ho scoperto che in effetti Mutt non controlla
il record MX della mail. Sì, la dir è /var/spool/clientmqueue
(refuso...). Esiste un parametro da passare a Mutt
per evitare il ritardo, che consente l'invio istantaneo:
set sendmail_wait=-1. Dici che Sendmail si comporta
correttamente? Non è che cerca di fare un lookup
e fallisce?

Grazie
M.

ma e' questo il comportamento corretto, nel senso che l'mta se non c'e' connessione (quindi non puo ne chiedere ad un dns non locale l'mx record di un dominio, ne tantomeno contattare un altro mta per il delivery o il relaying) e' normale che metta la mail in deferred; dopodiche', a seconda della configurazione del mta, ogni tot prova a fare il flush delle mail in coda deferred e dopo tot tentativi o tot tempo cancella le mail che non e' riuscito a inviare (ovviamente e' possibile agire sul tempo di retry e sul tempo di permanenza in coda prima della cancellazione, modificandoli a seconda delle necessita')

[samiel]

ovviamente e' possibile agire sul tempo di retry e sul tempo di permanenza in coda prima della cancellazione, modificandoli a seconda delle necessita'

OK, allora all's well that ends well.
Le modifiche sul tempo di retry e su quello di cancellazione
sono parametri da mettere in submit.cf, suppongo.
Devo vedere qualche guida su sendmail per capire
che scrivere...

Grazie
M.

[samiel]

Mi manca un passaggio... perché la mai inviata da Mutt
alla cosa (/var/spoon/clientmqueue) ci mette un minuto
per arrivare? Ok, con set sendmail_wait=-1 il processo
viene collocato in background, ma non è strano che
per mettere la mail in deferred (nota bene, non per cercare
poi di inviarla o per cancellarla) ci impieghi tutto sto tempo?

M.

[masalapianta]

Mi manca un passaggio... perché la mai inviata da Mutt
alla cosa (/var/spoon/clientmqueue) ci mette un minuto
per arrivare? Ok, con set sendmail_wait=-1 il processo
viene collocato in background, ma non è strano che
per mettere la mail in deferred (nota bene, non per cercare
poi di inviarla o per cancellarla) ci impieghi tutto sto tempo?

M.

/var/spool/clientmqueue non e' la coda deferred ma la coda dove vengono depositate le mail inviate da locale tramite il comando sendmail (poi quando sendmail prova a inviarla e non ci riesce la sposta nella coda deferred; btw non uso mutt quindi non ho idea di come si comporti e cosa faccia, btw alla peggio con uno strace ti rendi conto di cosa stia facendo in ogni momento (oppure basta dare un'occhiata ai sorgenti)

[samiel]

Ricevuto! comunque in effetti il mio problema si è spostato
da Mutt a Sendmail. Un tale sulla mailing list di Mutt
sosteneva che le mail "inviate" da Mutt a Sendmail
ci mettono un tempo molto, troppo lungo, perché
Sendmail cerca di spedirle prima di mettere in cliemtmquque.
Lui ipotizza quanto segue:

I would definitely run a local caching nameserver in that
case because there are much more powerful configurations possible than
just rewriting /etc/resolv.conf. If you are running Debian or Ubuntu
look at the resolvconf package for good functionality there.
As to what I said above that means that there should be two different
MTA (mail transfer agent) configurations. They should be switched
between depending on whether the network is online or not. When the
network is online then recipient email addresses should be validated
immediately. When the network is offline then mail should just be
queued and if the recipient does not exist when mail delivery is
attempted after the network comes online then a bounce message back to
you should be generated to let you know that your message won't be
delivered. You can then attempt to resend it using a corrected
address if desired.

Ma usare due differenti configurazioni di Sendmail (una quando
sono online e una quando sono offline) mi pare un po' perverso.
Tu che ne dici?

Grazie!
M.

[masalapianta]

Ma usare due differenti configurazioni di Sendmail (una quando
sono online e una quando sono offline) mi pare un po' perverso.
Tu che ne dici?

Grazie!
M.

se mi passi la battuta, dico che in generale e' perverso usare sendmail; mta come postfix o exim son piu' semplici da configurare, meno pesanti, piu' sicuri, piu' performanti (ma quest'ultima cosa nel tuo caso e' irrilevante visto che, usando l'mta solo per fare il delivery della tua posta in uscita, la differenza non e' apprezzabile)

http://ataualpa.altervista.org/muttnirvana/risorse.html

[samiel]

Infatti in debian ho exim4, non sendmail.
Ma poiché Pat insiste nel mettere solo sendmail,
volevo capire un po' meglio come funziona...

M.