Newsgroup: it.comp.software.mailreader
Titolo: campo bcc

Ciao,
ho una curiosità: gli indirizzi inseriti nel campo bcc, sono estraibili in
qualche modo con qualche utility ?
Grazie
Andrea

qualche modo con qualche utility ?
No, altrimenti a che servirebbe. Solo i server smtp che il messaggio ha
attraversato prima di giungere a destinazione sono a conoscenza di tutti o
di parte dei destinatari. Nel messaggio non resta traccia.
-- 
-antonio-
www.geminisoft.com


Reply-to: 
em...@ewasher.org
Bellino, neh? :-)
-- 
Luca - e-mail: p.stevens at 
operamail.com

,
Prova meglio e vedrai che i BCC NON si vedono...
-- 
Luc.

Prova meglio e vedrai che i BCC NON si vedono...
mi sembra di aver letto che a causa di errori (o qualcosa del genere)
di alcuni server si puo` verificare questa cosa, cioe` i bcc rimangono
inseriti. Spero si tratti di pochi casi sporadici 

 Reply-to: 
em...@ewasher.org
Arrivato anche a me. È un errore del server SMPT. :-(
E non è la prima volta che mi capita con loro....
-- 
     __         ____           | Eì 'Aanììgòò 'Ahoot'é
 __ / /__  ___ / __/__ __ __   |
/ // / _ \/ -_) _// _ \\ \ /   | 
http://www.macrossmm.com
\___/\___/\__/_/  \___/_\_\    | ICQ UIN: 61571298

Luc wrote:

A chi dici? :-)


 A chi dici? :-)
A te, ovviamente (non vedi il reference?).
-- 
Luc.

 Prova meglio e vedrai che i BCC NON si vedono...
Peccato che in quel messaggio (che ho ricevuto anche io)
   *** SI VEDONO ***


   *** SI VEDONO ***
Forse su "Gravity" di Luc non si vedono.
Come non si vedono in Usenet.Iol (URL su una riga):
http://usenet.iol.it/cgi-bin/ViewArticle.epl?MESSAGE_ID=
%3Cvju84ukvolvv2epfjkk34mdt9m2t84tjjv%40no%2Espam%3E&TABLES=
LAST6MESI&CATEG_PARAM=Computer%20e%20Internet&SOTTOCATEG_PARAM=
Software
invece si vedono in Google (URL su una riga):
http://groups.google.com/groups?hl=it&selm=
vju84ukvolvv2epfjkk34mdt9m2t84tjjv%40no.spam
e si vedono anche in Mailgate (URL su una riga):
http://mailgate.supereva.it/it/it.comp.software.mailreader/
msg10304.html
Saluti
Renato
r_e_...@hotmail.com
 

 Come non si vedono in Usenet.Iol
Ma che stronzata! Scusate l'espressione.
Prima di tutto non li ha tolti tutti e non se ne spiega il motivo, 
secondo... è una censura sul messaggio.... che non ha senso!


Luc wrote:

E te, non vedi il from? O pensi che 
em...@ewasher.org
 sia io?


 E te, non vedi il from? O pensi che 
em...@ewasher.org
 sia io?
Ma sei serio o faceto? 8-))) 
-- 
Luc.

 secondo... č una censura sul messaggio.... che non ha senso!
In effetti e' molto bizzarro che IOL 'lavori' il body dei messaggi news
eliminandone alcune componenti. Francemante non ne capisco il motivo.
Un saluto
-- 
Dario Centofanti
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

Luc wrote:

Vabč, non capisco. Se hai voglia di spiegarmi, reply-to poster.


 Forse su "Gravity" di Luc non si vedono.
Scusate, non capisco il senso di questa discussione (a parte le
assurdità di iol). L'errore è nell'SMTP server usato per spedire, che
include il campo Bcc nelle email che elabora, invece di cassarlo dopo
averlo utilizzato. Poi è chiaro che il mail client mostra tutto quello
che arriva (e ci mancherebbe che non lo facesse).


 eliminandone alcune componenti. Francemante non ne capisco il motivo.
Anche perchè, come abbiamo visto, non funziona neanche bene. Il motivo non 
sussiste in alcun caso. In questo, ad esempio, il messaggio ha addirittura 
perso ogni significato valido.


 volta che mi capita con loro....
Siamo sicuri che non si tratti di un errore del mailreader?
-- 
Veneziano Davide (
ve...@vene.ws
)
http://www.vene.ws
  Faq e manuali, Servizi Internet
http://mail.vene.ws
 E-mail Gratuite Pop3/Smtp/Web
ICQ# 14047537

 estraibili in qualche modo con qualche utility ?
Non esiste, in realtà, il campo Bcc. Il mailreader si limita a dare i 
relativi comandi RCPT TO al server, senza poi aggiungere gli indirizzi 
all'interno degli header
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.18. C, C++ and ASM developers
                              and beta testers are welcome!

 Siamo sicuri che non si tratti di un errore del mailreader?
E' un errore del mailreader


 Siamo sicuri che non si tratti di un errore del mailreader?
reader o sender?
Se intendi il reader la risposta è no. Perchè al reader quel campo non 
deve apparire.
Se intendi il sender la risposta è no. Perchè al sender quel campo DEVE 
apparire.
È il server nel mezzo che ha fatto quella cazzata. Perchè di cazzata si 
tratta. Senza scuse.


 all'interno degli header
[per chiarezza: intendi errore del mail_client_, quando spedisce]
===
Ho dei dubbi perché non sono un tecnico:
Da 
http://www.imc.org/rfc2821
	 APPENDICES
B. Generating SMTP Commands from RFC 822 Headers
   Some systems use RFC 822 headers (only) in a mail submission
   protocol, or otherwise generate SMTP commands from RFC 822 headers
   when such a message is handed to an MTA from a UA. 
																			 ^^^^^^^^^^^^^
[Il dubbio è: per UA, User Agent, si intende proprio "l'omino" che vuole
spedire oppure il suo mail client? Mentre il Mail Transport Agent è solo
il server o è anche il client?]
 
	 ...
   It is recommended that the UA provide its initial ("submission
   client") MTA with an envelope separate from the message itself.
   However, if the envelope is not supplied, SMTP commands SHOULD be
   generated as follows:
   1. Each recipient address from a TO, CC, or BCC header field SHOULD
      be copied to a RCPT command (generating multiple message copies if
      that is required for queuing or delivery).  This includes any
      addresses listed in a RFC 822 "group".  Any BCC fields SHOULD then
      be removed from the headers.  Once this process is completed, the
      remaining headers SHOULD be checked to verify that at least one
      To:, Cc:, or Bcc: header remains.  If none do, then a bcc: header
      with no additional information SHOULD be inserted as specified in
      [32].
Dato il dubbio di cui sopra non capisco se il processo del punto 1 qui
sopra deve essere effettuato dal client stesso, o può e deve anche
essere effettuato dal server. 
===
Invece, questo secondo caso che m'è toccato tempo fa mi sembra chiaro:
	Received: from 
mex.italtel.it
 (
mex.italtel.it
 [138.132.117.4]) by
 
server1.comune.jesi.ancona.it
 (8.9.3/8.9.3) with ESMTP id LAA08217 
	for <xxx@xxx>; Wed, 12 Jul 2000 11:38:33 +0100
	...
	Received: from 
italtel.net
 by 
ic8ss07.settimo.italtel.it
 
	(SMI-8.6/SMI-SVR4) id LAA26447; Wed, 12 Jul 2000 11:11:45 +0200
	...
	From: xxx <xxx@xxx>
	X-Mailer: Mozilla 4.7 [en] (WinNT; I)
	...
	Apparently-To: <xxx@xxx>
	Apparently-To: <xxx@xxx>
	Apparently-To: <xxx@xxx>
	Apparently-To: <xxx@xxx>
	Apparently-To: <xxx@xxx>
	Apparently-To: <xxx@xxx>
	Apparently-To: <xxx@xxx>
	Apparently-To: <xxx@xxx>
	Apparently-To: <xxx@xxx>
	Apparently-To: <xxx@xxx>
	Apparently-To: <xxx@xxx>
In quest'altro caso è stato sicuramente il server che ha preso tutti gli
indirizzi del Bcc e li ha messi dove non dovrebbero stare, violando
quest'altro punto:
7.2 "Blind" Copies
   Addresses that do not appear in the message headers may appear in the
   RCPT commands to an SMTP server for a number of reasons. 
	 ...
	 Especially when more than one RCPT
   command is present, and in order to avoid defeating some of the
   purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy
																						 ^^^^^^^^^^^	
   the full set of RCPT command arguments into the headers, either as
   part of trace headers or as informational or private-extension
   headers.  Since this rule is often violated in practice, and cannot
   be enforced, sending SMTP systems that are aware of "bcc" use MAY
   find it helpful to send each blind copy as a separate message
   transaction containing only a single RCPT command.


 essere effettuato dal server.
A me sembra di capire che debba essere effettuata dal client, quindi dal
UA, perň non č detto che l'operazione venga fatta anche da server, non
saprei.


 tratta. Senza scuse.
No aspetta, mi sono perso. Come ha giustamente detto Juliet::Juliet non
puň essere stato il server SMTP ma piů probabilmente il mailreader
utilizzato per inviare. Infatti l'RCPT TO vale tanto per il campo To: che
Cc: e Bcc:, indistintamente. Non credo che l'SMTP ha paragonato l'header
from con gli rcpt to e ha inserito un header aggiuntivo, sarebbe stata
una pazzia. Sempre se ho capito bene il problema.


 utilizzato per inviare.
Ti sbagli. Il server da cui è passato il messaggio, invece che eliminare i 
vari indirizzi nel momento in cui sono stati consegnati, li ha lasciati 
nel messaggio stesso. Il "mailsender" non può comportarsi in modo 
differente. Quel campo lo deve mettere.


 differente. Quel campo lo deve mettere.
Calypso ha l'opzione per il BCC 'sicuro'. In pratica manda i messaggi 
singoli ad ogni utente... 
-- 
Luc.

 singoli ad ogni utente... 
Permettimi di dirlo, ma non è una masturbazione mentale? Ed uno spreco di 
banda?


di banda?
Ad entrambe la risposta è si, soprattutto se si parla di sicurezza.
Però è una funzione che può tornare utile.
Ciao.
P.S. Carina l'X-Face! :-)
-- 
Antonio  @=D.

 P.S. Carina l'X-Face! :-)
Grazie. (-:
