Azzurra IRC Network Forum

Una proposta

Daniela · 11/04/2004 16:45 · #1
Ciao ragazzi siete fantastici, vi auguro buona pasqua e approfitto per chiedervi cosa ne pensate di dare a noi utenti la possibilità di poter recapitare i memo che inviamo agli altri utenti tramite email cioè al loro indirizzo email?
Avevo un amico che volevo rintracciare ma non avendo la sua email ho provato a inviare un memo sperando lo leggesse e invece ho visto che non si è piu collegato :( da qui mi è venuta questa idea.
Cosa ne pensate?
Un bacione e andate avanti cosi, siete forti!
Daniela
debiAn · 11/04/2004 20:53 · #2
Daniela credo che sia un ottima idea, provero' a portare avanti l'idea con chi si occupa dei nostri servizi IRC.

Ciao e buone feste anche a te.

--
debiAn
Dracoo · 11/04/2004 23:07 · #3
Cool! Avevo già visto una cosa del genere su gli Auspice... penso comqune, che sarà possibile evitare ciò con un SET creato appositamente, no?
Sperem ^^
Buttando lì la domanda... più o meno in che periodo è prevista il prossimo update dei services? (sempre che ci sia una previsione :P)

Buona Pasqua&Pasquetta
trekfan1 · 12/04/2004 10:44 · #4
Sperando di non essere OT, si potrebbe fare la stessa cosa anche con la Password del nick?

Mi spiego: su Dalnet esiste il comando /ns sendpass utile a chi si è dimenticato la password del nick, cioè verrebbe inviata la password del nick a chi se la è dimenticata nella casella di posta elettronica specificata nella registrazione. :)
Tecnicodaniele · 12/04/2004 12:17 · #5
Nickserv è un servizio , solitamente per usarlo (tranne per i comandi acc , info e register) bisogna avere il nick registrato e quindi identificato , quindi per usare un comando come quello che hai indicato (sendpass) se l'utente in questione ha scordato la password non può di conseguenza identificarsi , questo si potrebbe risolvere facendo in modo che , come per i comandi acc ecc sia possibile usarlo senza essere identificati ma , questo non avrebbe senso in quanto chiunque potrebbe usarlo e , far arrivare alle persone tanti sendpass inutili e non richiesti :) .

Mentre come viene gestito ora , basta richiedere la password su #irchelp e verrà rispedita all'utente in questione solo dopo alcuni controlli di sicurezza.
Dracoo · 12/04/2004 14:47 · #6
Si potrebbero fare degli accorgimenti per evitare abusi.
Il comando potrebbe essere più o meno
/ns sendpass email
Così uno se sa l'email di registrazione gli viene inviata la pass, altrimenti no! (e magari dopo 3 email sbagliate, scatta il kill, come per IDENTIFY).

Per i chan, si potrebbe attivare il comando senza bisogno di email, accessibile solo al founder (identificato al nick ^^)
Tecnicodaniele · 12/04/2004 15:32 · #7
Bhe è una cosa piuttosto giusta quella che hai detto ma , rimane il fatto che è una cosa che comunque ha i suoi lati negativi.
Esempio se qualcuno conoscesse l'email perchè magari quella persona è sua amica , potrebbe mandare sendpass a tutto spiano solo per gioco , oppure qualcun altro , potrebbe spacciarsi per helper e dire: dammi la tua email che ti rispedisco la password , e altri abusi di questo tipo :).
Io rimango dell'idea che, come stanno ora le cose (farsi mandare le password dagli helper) sia la cosa più sicura di tutte , evitando rischi ed abusi inutili (poi non spetta a me deciderlo , è solo una mia opinione)
trekfan1 · 12/04/2004 16:58 · #8
Bè se mi ricordo bene, su dalnet c'era anche l'opzione per disattivare la possibilità di mandare l'email con la pass, cmq ecco l'output del comando /ns help sendpass:

[17:56] -NickServ- ***** NickServ Help *****
[17:56] -NickServ- Command - SENDPASS
[17:56] -NickServ- Usage - SENDPASS <nickname> <email address>
[17:56] -NickServ-
[17:56] -NickServ- The SENDPASS command will allow a user to request that
[17:56] -NickServ- his or her nickname password be sent to the email address
[17:56] -NickServ- on file for that nickname.
[17:56] -NickServ-
[17:56] -NickServ- The email address you specify must match the email address
[17:56] -NickServ- on file for the nickname.
[17:56] -NickServ-
[17:56] -NickServ- This command should not be relied on as an alternative to
[17:56] -NickServ- managing your own passwords, but only as a "backup" in case
[17:56] -NickServ- of extreme situations. Please remember that you are still
[17:56] -NickServ- responsible for remembering your password(s) and keeping them
[17:56] -NickServ- private. Do not share your password(s) with anyone.
[17:56] -NickServ-
[17:56] -NickServ- Example:
[17:56] -NickServ- /msg NickServ@services.dal.net SENDPASS Gamma someuser@someisp.com
[17:56] -NickServ- ***** End of Help *****

Ed ecco il comando per bloccarlo:

[17:58] -NickServ- ***** NickServ Help *****
[17:58] -NickServ- Command - SET MAILBLOCK
[17:58] -NickServ- Usage - SET MAILBLOCK ON|OFF
[17:58] -NickServ-
[17:58] -NickServ- Turning this feature on will prevent anyone from using the
[17:58] -NickServ- SENDPASS command on your nickname. The SENDPASS command
[17:58] -NickServ- allows you to send your nickname password to your email
[17:58] -NickServ- address on file.
[17:58] -NickServ-
[17:58] -NickServ- CAUTION: If you enable the MAILBLOCK feature, you will no
[17:58] -NickServ- longer be able to request your password be sent via email
[17:58] -NickServ- and you will be entirely responsible for keeping track of
[17:58] -NickServ- it on your own.
[17:58] -NickServ-
[17:58] -NickServ- Example:
[17:58] -NickServ- /msg NickServ@services.dal.net SET MAILBLOCK ON
[17:58] -NickServ- ***** End of Help *****
PiNe · 12/04/2004 23:06 · #9
Salve a tutti,
ritengo una cosa veramente utile avere la possibilità di ricevere memo via posta elettronica, anche se, d'altro canto, una persona che si collega ad Internet, effettuerà entrambe le azioni (controllo delle e-mail ed controllo di eventuali memo).
Ovviamente non penso che il consumo di risorse sia elevato (l'e-mail spedita peserà pochi KB). Secondo me sarebbe molto efficace rendere disponibile un'opzione simile.
D'altro canto, concordo pienamente con il parere di Tecnicodaniele sulla questione del comando sendpass. Risulterebbe una cosa inutile ai fini della sicurezza e potrebbe, eventualmente, essere fastidioso ricevere invii di password non richiesti.
trekfan1 · 13/04/2004 07:30 · #10
Se hai letto a modo il post basterebbe creare il comando per bloccare l'invio e cmq si potrebbe anche limitare l'invio della pass solo una volta al giorno per evitare questa cosa, certo resterebbe sempre il rischio abuso, ma almeno resterebbe limitato
Steve · 13/04/2004 07:59 · #11
Intorno all'argomento "email generate dai servizi" vedo che si e' generata un po' di confusione. Probabilmente bastava aprire un nuovo topic invece di rispondere su un argomento similare.

Il discorso delle e-mail per un memo era gia' attivo con i vecchi servizi, venne disabilitato probabilmente perche' a quell'epoca non c'erano garanzie che gli indirizzi e-mail associati ai nick fossero effettivamente validi. Adesso quel pericolo non c'e' piu', grazie al sistema di autenticazione che e' stato implementato, e dunque credo si possa tornare a parlarne.
Io personalmente sarei per inviare una notifica di ricezione del memo, piuttosto che il memo intero... questo per chiedere all'utente di venire su IRC anche solo due minuti e leggersi il memo, se non altro perche' eventuali risposte andrebbero date per l'appunto tramite MemoServ. Saro' paranoico, ma il mittente di una e-mail puo' essere falsificato (contenuto compreso) e quindi preferirei affidarmi ai servizi di IRC.

Per la questione del sendpass, io sono convinto che la situazione attuale su Azzurra sia ottimale: chi ha bisogno di questo servizio va su #IRCHelp o scrive a lostpass(at)azzurra.org , e dopo i dovuti controlli la richiesta viene soddisfatta.
Evidentemente su altre reti non c'e' la possibilita' o la volonta' di effettuare questo tipo di assistenza agli utenti e di conseguenza la scelta di abilitare il sendpass sarebbe una necessita' piu' che un'effettiva scelta comportamentale. E' ovvio che in quel caso bisogna necessariamente implementare numerosi controlli sugli indirizzi e-mail, sugli accessi ai canali, sul numero delle richieste, ecc. (ovvero automatizzare il controllo manuale da parte di un Helper, per farla breve), altrimenti si farebbe piu' male che bene al network interessato ed ai suoi utenti.
E' una questione di "carico umano" (basato sugli Helper e sulla loro volontaria disponibilita') e "carico macchina" (regolato dai servizi e dal loro carico sui server), prima ancora che di opportunita' o ragionevolezza del procedimento.