[Discussioni] Apache contro Sender ID

[Roberto Galoppini]

Marco d'Itri wrote:

>On Sep 09, Simo Sorce <simo a softwarelibero.it> wrote:
>
>  
>
>>>>Quanto è facile aggirare questo meccanismo?
>>>>        
>>>>
>>>Non è aggirabile.
>>>      
>>>
>>Scusa, ma come distingui una mail inviata dall'utente da quella inviata
>>dalla sua macchina zombizzata?
>>    
>>
>Non la distingui, ma non si può parlare di "aggirare il meccanismo"
>perché l'origine del messaggio è effettivamente verificata.
>Questo dovrebbe fare riflettere sul fatto che il concetto di
>autenticazione non implica un sacco di altre cose che spesso gli sono
>associate in modo più o meno truffaldino.
>
Concordo. Aggiungo che il livello di confidenza del meccanismo descritto 
nel RFC in questione è, come si evince dalla stessa introduzione(*), 
basato sull'affidabilità del mittente e, a me, il sender-id ricorda 
tanto l'evil-bit di belloviana memoria (ma almeno lui ci ha deliziato 
con i vari commenti <http://www.research.att.com/~smb/3514.html>, di cui 
l'ultimo apparentemente proveniente da personale della stessa azienda 
che detiene il brevetto in questione!(**):)!

Rob Galop

(*) "Note that the results of this algorithm are only as truthful as the 
headers contained in the message; if a message contains fraudulent or 
incorrect headers, this algorithm will yield an incorrect result"

(**)"//Good Afternoon,//// What or who determines the "evilness" or 
"goodness" of the packet? If a security admin or OS can determine or 
flag bits as good, what keeps the hacker from spoofing this process by 
setting the bit to "good"? Does the bit change based on behavior? Or 
maybe a database with signatures of "bad" bits?//"