B4A Library New Net library - Android FTP, SMTP and POP3

Status
Not open for further replies.

Stuart McLachlan

Member
Licensed User
Longtime User
Bug in SMTP? BCC recipients can see all other BCCs

That's not a bug, it's a feature

It's actually a perfectly valid implementation of the standard.

RFC 5322, Para 3.6.3. Note the sentence in parentheses at the end of the quote which describes your desired implementation as just one way of handling it.

"There are three ways in which the "Bcc:" field is used. In the first case, when a message containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is removed even though all of the recipients (including those specified in the "Bcc:" field) are sent a copy of the message. In the second case, recipients specified in the "To:" and "Cc:" lines each are sent a copy of the message with the "Bcc:" line removed as above, but the recipients on the "Bcc:" line get a separate copy of the message containing a "Bcc:" line. (When there are multiple recipient addresses in the "Bcc:" field, some implementations actually send a separate copy of the message to each recipient with a "Bcc:" containing only the address of that particular recipient.)"

FWIW, this is from a Help screen in my preferred email program - Pegasus Mail:
"Suppress BCC field listings in outgoing mail BCC (Blind Carbon Copy) is a useful, but poorly-standardized feature. There are at least three ways a BCC field could be written into a message: it could be omitted altogether; it could contain only each individual recipient's address; or it could contain theaddresses of all people receiving the BCC. By default, Pegasus Mail lists all the BCC recipients in the BCC field of mail it sends: if you would prefer that no addresses were shown in the field, then check this control. When this option is turned on, theBCC field will simply contain the text "(Suppressed)", without any addresses."

That could usefully be an option in any future version of the library.
 

boten

Active Member
Licensed User
Longtime User
Still strange. When sending email to multiple BCCs using gmail (in browser, gmail.com) each BCC recipient sees only the "To: address" AND its own address (in bcc filed).
BUT, when sending from app using SMTP, each BCC recipient also sees (in addition to the above) all other BCC recipients, which defies the intention of BCC.
 

wl

Well-Known Member
Licensed User
Longtime User
I guess then this depends on how the gmail email client works in respect to the SMTP class. AFAIK the SMTP server as such will only send individual messages.
 

Stuart McLachlan

Member
Licensed User
Longtime User
>which defies the intention of BCC

Your idea of the intent of BCC is just that, your idea. GMail doing it that way doesn't mean that it is the only or "correct" implementation.

If you read the quote above from the RFC, the library's way of doing it is the second method described, your desired miplementation is the third (in parenthesized) method. Which implies, if anything, that the library implementation is more common that your desired implementation. As I also pointed out, the library's method is also the default for Pegasus Mail - a decision which was reached after a great deal of thought went into the design.
 

Stuart McLachlan

Member
Licensed User
Longtime User
I guess then this depends on how the gmail email client works in respect to the SMTP class. AFAIK the SMTP server as such will only send individual messages.

A properly designed SMTP Server will only send one copy of an email to each addressee domain, regardless of how many addresses at that domain are in the To, CC and BCC headers. Note that the SMTP component of the library is not a full SMTP server. It just provides basic Message Submission Agent and Message Transmission Agent (MSA/MTA) capabilities to your app.
 

boten

Active Member
Licensed User
Longtime User
I'm not talking about who gets a copy of the message - all addresses should receive the message itself, whether these addresses are in TO: CC: or BCC: fields.

My point is that: If you send a message to addr1, put in CC: addr2, put in BCC: addr3 and addr4 then
addr1 can see that message was also sent to addr2
addr2 can see that message was also sent to addr1
addr3 can see that message was also sent to addr1 and addr2
and so should addr4.
BUT: neither addr1, nor addr2 sees that addr3 & addr4 also received it
addr3 won't see addr4, and addr4 won't see addr3
That's how BCC originally intended to work, replicating the method when messages where typed & copied with carbon paper.

As for the implementation in the library:
The Gmail app in my phone (and I assume in any android device) treats BCC as was originally meant by BCC - BLIND carbon copy. That's the reason for BCC. I you want all recipients to see the e-mail address of all other recipients you can either send to all recipients (TO: ) or put all of then in the CC: field.

The SMTP object in the Net library has both CC and BCC fields. If BCC is there "only for decoration" - it should be so stated, But if the intention is to provide functionality similar to most e-mail programs (let Pegasus fly on its own) then addresses added to the BCC list should be hidden from all other recipients.
 

mjtaryan

Active Member
Licensed User
Longtime User
My interest at the moment is transferring large remotely stored and organized documents using FTP. Is there a full tutorial for the Net library? Thanks.
 

LaryLee

Member
Licensed User
Longtime User

I got a problem , "downloadService", red-words within StartService(DownloadService).
I know that is I need to add some modules, or lack import some libiraies.
Please help me, Thanks
 

MotoMusher

Active Member
Licensed User
Longtime User
View attachment 20519
I got a problem , "downloadService", red-words within StartService(DownloadService).
I know that is I need to add some modules, or lack import some libiraies.
Please help me, Thanks
Do you have a service that you created called "DownloadService"? If so you should do StartService("DownloadService"). The name of the service is passed as a string. If you don't have a download service, then to create one, Go to the Project menu, then "Add New Module", then choose "Service Module" and put your code in there.
 

LaryLee

Member
Licensed User
Longtime User
@LaryLee you should start a new thread for this question. It is not related to the Net library. I guess that you are referring to an old example. You should use HttpUtils2 to download instead.

Thanks, Yes Maybe I refer to an old example.
 

LaryLee

Member
Licensed User
Longtime User
I try to download a text file from a web site








My B4A partial prog is following :






But during debug , the result I got is :



Prog can't log into web server or folder path is wrong ?
Please help me, thanks
 
Last edited:

Kwame Twum

Active Member
Licensed User
Longtime User
hi everyone, I tried uploading a file from my sdcard to a server and I get the following in the logs
B4X:
/palztechgroup.com/wwwroot/00001.vcf, Success=false
javax.net.ssl.SSLProtocolException: SSL handshake aborted: ssl=0x344770: Failure in SSL library, usually a protocol error
error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol (external/openssl/ssl/s23_clnt.c:683 0xad1275cc:0x00000000)
The credentials passed to FTP.Initialise work on a FTP client
This is the sub that handles the upload:
B4X:
Sub attch_Click
    Dim dial As FileDialog
    dial.FilePath= File.Combine(File.DirRootExternal, "/")
    If dial.Show("Select a file", "Lego!", "Cancel","",Null)=-1 Then
        FTP.UseSSL = True
        FTP.PassiveMode = True
        ProgressDialogShow("Attempting to upload...")
        FTP.UploadFile(File.DirRootExternal, dial.ChosenName, True, "/palztechgroup.com/wwwroot/" & dial.ChosenName)
        FTP.Close
        ProgressDialogHide
    End If
End Sub
What can the problem be? Need help
 

Kwame Twum

Active Member
Licensed User
Longtime User
Have you tested the FTP client on the same device?
I haven't... What I meant was that the username and password used in the Initialising stage are correct ( I've tried it in FileZilla)..
 
Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…