On 08/01/14 18:46, Tullio Andreatta ML wrote: >> Concordo su tutto il resto, ma alcune verifiche sull'helo sono previste >> dalla RFC5321. In particolare nel §4.1.1.1. si afferma che l'helo deve >> essere il nome fqdn del client smtp (se disponibile) ovvero un IP >> literal. Il controllo che tale fqdn sia risolvibile è quindi lecito, >> dato che in caso contrario si tratta di una errata configurazione del >> sender. > > Solo perche' RFC5321 dice "dovrebbe essere" (SHOULD) non significa che > sia lecito rifiutare i messaggi se non e' risolvibile o se non corrisponde.
Ancorché concordi sul punto specifico, trovo anche che sia tu che Flavio stiate cogliendo il punto solo di striscio (nella mia personale idea, sia chiaro). "Junk Mail is war. RFCs do not apply." (cit) Chi decide di pretendere un comportamento di un certo tipo da sistemi mittenti non lo fa perchè le RFC *pretendono* quel comportamento, ma perchè quello è il comportamento normalmente atteso (secondo chi implementa il ruleset; che poi questo corrisponda alla norma dei mittenti è poi da verificare) *e* ritiene di poter fare a meno delle mail di chi non vi si attiene. Se poi la quantità di FP generati da ciò sia eccessiva (nella mia opinione -nel caso di cui parliamo- lo è per chiunque, ma è appunto una opinione) e/o se tale misura sia utile a tenere fuori una quantità significativa di spam (anche questo a mio parere contestabile nel casus in questione, almeno in rapporto al rate di FP causati) sta a lui stabilirlo. Il fatto che il comportamento sia o meno definito da RFC è quindi quasi incidentale... C'è un bot, lì fuori, che invia spam usando sessioni SMTP in cui utilizza come HELO "dsldevice.lan" (cutwail, credo), e lo fa da anni. E piuttosto normale, quindi, per un ruleset lato ricevente, segare a vista sessioni che si presentino con tale HELO. If it looks like a duck, and quacks like a duck... Non è che questo HELO sia "meno RFC-compliant" del tuo "smtp.network10-1-67.local", sia chiaro, ma se qualcuno decide di impostare quella stringa come HELO del proprio mailserver poi difficilmente può lamentarsi se le sue mail non vengono accettate di default, nè può pretendere che lo siano in virtù del mero fatto che "quell'HELO non è vietato da RFC". Perchè, appunto, non è quello il senso della restrizione applicata. (E' mia opinione di vecchia data che nell'ambito della configurazione di filtri SMTP ci sia un proliferare di prassi basate sul "mio cugino mi ha detto che" più che all'effettiva efficacia in termini di rapporto FP/VP; così come una mancanza di percezione del fatto che qualsiasi misura applicata che non abbia un tasso di FP pari a *zero* richiede poi che le eccezioni *vengano gestite*. Il che è la reale causa di gran parte dei problemi cui ci si riferisce qui; ma è altro discorso...) > Ad esempio, il mail server sul quale adesso sto lavorando ha come FQDN > smtp.network10-1-67.local e IP literal 10.1.67.25 e - a seconda del > fatto che la linea impegnata sia quella principale o quella di backup - > puo' uscire con due indirizzi IP pubblici differenti, uno dei quali e' > in comune con un'altra 40ina di mail server, i quali hanno nomi tutti > diversi (e che, quando la linea primaria e' attiva, escono solitamente > con IP pubblici tutti diversi). Che cosa devo scrivere come argomento di > HELO? Quello che vuoi, purchè stia su un dominio che controlli direttamente (evita in particolare roba fantasiosa come "hostX-Y-static.Z-W.business.telecomitalia.it") e risolva... ^_^ Di certo, se usi ".local" come TLD, così non può essere... Se vuoi far di più, associa un record SPF all'hostname usato come HELO (e, ovviamente, al dominio mittente liddove possibile). Il fatto che la risoluzione dell'HELO ritorni lo stesso IP usato per il singolo invio è un "di più" gradito, ma non necessario: è pur vero che ci sono taluni che lo pretendono, ma si tratta di nuovo di eccessi di zelo (sempre IMHO) ancor più limitati per diffusione. ________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
