On 9/23/13 3:41 PM, Mirko ML wrote: >> Il problema è che vi sono situazioni in cui greylisting causa delay ben >> superiori al tempo di requeue di un singolo tentativo. > Vedi sopra per il timeout e per quanto riguarda il DSN di alcuni > provider grossi e ben noti basterebbe che applicassero le Retry > Strategies e la Sending Strategy della stessa RFC, cosa che > semplicemente non fanno con la scusa di essere appunto grossi
Non mi risultano "grossi" che violino le RFC sulle modalità di ritrasmissione, ad essere sinceri, ed infatti non è a questo che mi riferisco sui problemi introdotti dal greylisting, bensì sull'assunto soggiacente la logica stessa dell'approccio da questo implementato: che la ritrasmissione di un messaggio debba originarsi dallo stesso IP da cui ha avuto origine in precedente tentativo di delivery. La qual cosa che non è in alcun modo deducibile da RFC (che, appunto, definiscono SMTP e non greylisting), e che in caso di sender con SMTP pool molto distribuiti può essere una assunzione assai lungi dall'essere sensata. Poi, come disse il buon Wietze, "Spam is war, RFCs do not apply", ergo ciò non è necessariamente un male di per sè. Ciò non toglie che introdurre deliberatamente ritardi su una fetta importante del traffico, ottenendo in cambio una efficienza molto limitata e facilmente superabile con dozzine di altri approcci disponibili non ricade nella mia definizione di "misura efficace". YMMV, a seconda delle dimensioni dei sistemi che gestisci. ________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
