I'm using Delphi 2006 to create and send an email message with an attachment in a personal-use-only application. I send the message with an instance of TIdSMTP, and then also put a copy into a specific IMAP folder with an instance of TIdIMAP4. This all works very nicely with the version of Indy 10 that was distributed with BDS2006, with one exception: the time is always incorrect in the email header.
I decided to fix that if I could, and after searching for a solution it seemed most reasonable to get the latest Indy 10 snapshot and use that.
That puts the correct time into the email header, but there's a new problem. The boundary string is now different in the header of the message that is added to the IMAP folder than what comes in the body of the email! (Please note that the message that was sent via SMTP is correct.)
This is the relevant header information from the older version of Indy 10:
Content-Type: multipart/mixed; boundary="XNlC6OyS4QSiHY2U=_jsXyps6TR34pFNsh"
MIME-Version: 1.0
Date: Tue, 22 Nov 2011 09:11:58 +0000
A test of the BDS2006-bundled version of Indy
--XNlC6OyS4QSiHY2U=_jsXyps6TR34pFNsh
Content-Type: application/octet-stream;
name="20111122.xls"
And this is the same header information from Indy 10.5.8 (snapshot 10_4702 which I installed yesterday):
Content-Type: multipart/mixed; boundary="CDbEncbFvL7RZdOJ3DOIRoRBs=_nBsbZms"
MIME-Version: 1.0
Date: Tue, 22 Nov 2011 07:33:46 -0600
investigating more deeply, why does the boundary indicator change?
--h=_WzGWJei29fng7SqdPpDh1nkJxJZhiGc
Content-Type: application/octet-stream;
name="20111122.xls"
The time stamp is fixed, but now the boundary string is incorrect. The result is that there appears to be nothing at all in the message that gets added to my IMAP folder.
Here is the relevant code that creates the email message and attachment, sends it, and puts a copy into the IMAP folder:
FTheMsg.Date := Now; // FTheMsg is a component dropped onto the form
FTheMsg.Recipients.EMailAddresses := edMailTo.Text;
FTheMsg.ClearBody;
FTheMsg.Subject := 'Glucose Readings ' + FormatDateTime('mm/dd/yy', FStartDate) + ' - ' +
FormatDateTime('mm/dd/yy', FEndDate);
FTheMsg.Body.Assign(FMemo.Lines);
// create the attachment
TIdAttachmentFile.Create(FTheMsg.MessageParts, fileName);
// send the mail!
FSmtp.Host := FSMTPHost; // values set up elsewhere, FSmtp is a component on the form
FImap.Host := FIMAPHost; // FImap is also a component on the form
FSmtp.Connect;
try
FSmtp.Send(FTheMsg);
FImap.Connect;
try
if (not FImap.AppendMsg('Sent Items', FTheMsg, FTheMsg.LastGeneratedHeaders, [mfSeen])) then
StatusBar1.Panels[4].Text := 'Failed append msg';
finally
FImap.Disconnect;
end;
finally
FSmtp.Disconnect;
end;
As I said, the email that gets sent is fine and displays properly. But the one that is added to my IMAP folder (in FImap.AppendMsg() above) is incorrect. I've attempted to trace through the code to see where it might be going wrong, but frankly, I'm not familiar enough with Indy and the various email protocols/RFCs to be able to determine what's going wrong. About all I can tell is that the older version saves the message to a temporary file before appending it to the folder, while the newer version saves it to a memory stream instead. Obviously, something is different about that, but I'm currently too ignorant to determine what.
Is there a simple way to correct the timestamp problem in the old version? If so, that would be fine for my use, as everything else appears to be correct. If not, what else do I need to do to fix the problem exhibited here with the incorrect boundary string?
(As this is an application strictly for my own use, I can live with the incorrect date if I have to, but not with the "empty-appearing" copy in my 'Sent Items' folder.)
If more information is needed, I'll gladly supply whatever I can.
[Edit: I did incorporate something of a kludge in MY code, using the older version of Indy. I simply set the date/time of the message to UTC/GMT time before sending it, and that, at least, allows the message to contain the correct time at the receiver's end. I don't particularly care for that fix, but it does the trick.]
Don't use the TIdMessage.Body property to hold your text when an attachment is present. Put the text into a TIdText object instead. Even better, use the TIdMessageBuilder... classes, such as TIdMessageBuilderPlain, to prepare the TIdMessage body for you.
Try this:
FTheMsg.Clear;
FTheMsg.Date := Now; // FTheMsg is a component dropped onto the form
FTheMsg.Recipients.EMailAddresses := edMailTo.Text;
FTheMsg.Subject := 'Glucose Readings ' + FormatDateTime('mm/dd/yy', FStartDate) + ' - ' + FormatDateTime('mm/dd/yy', FEndDate);
FTheMsg.ContentType := 'multipart/mixed';
TIdText.Create(FTheMsg.MessageParts, FMemo.Lines).ContentType := 'text/plain';
TIdAttachmentFile.Create(FTheMsg.MessageParts, fileName);
FSmtp.Connect;
try
FSmtp.Send(FTheMsg);
FImap.Connect;
try
if (not FImap.AppendMsg('Sent Items', FTheMsg, nil, [mfSeen])) then
StatusBar1.Panels[4].Text := 'Failed append msg';
finally
FImap.Disconnect;
end;
finally
FSmtp.Disconnect;
end;
Or:
FTheMsg.Clear;
FTheMsg.Date := Now; // FTheMsg is a component dropped onto the form
FTheMsg.Recipients.EMailAddresses := edMailTo.Text;
FTheMsg.Subject := 'Glucose Readings ' + FormatDateTime('mm/dd/yy', FStartDate) + ' - ' + FormatDateTime('mm/dd/yy', FEndDate);
with TIdMessageBuilderPlain.Create do
try
PlainText.Assign(FMemo.Lines);
Attachments.Add(fileName);
FillMessage(FTheMsg);
finally
Free;
end;
FSmtp.Connect;
try
FSmtp.Send(FTheMsg);
FImap.Connect;
try
if (not FImap.AppendMsg('Sent Items', FTheMsg, nil, [mfSeen])) then
StatusBar1.Panels[4].Text := 'Failed append msg';
finally
FImap.Disconnect;
end;
finally
FSmtp.Disconnect;
end;
Now, with that said, it is likely that it will still not work correctly either way. TIdIMAP4.AppendMsg() calls TIdMessage.SaveToStream() internally, which regenerates the email content fresh (and thus alters the boundary used in the body). Whether you pass in the pre-existing TIdMessage.LastGeneratedHeaders or let TIdIMAP4.AppendMsg() grab the current TIdMessage.Headers, they will be out of sync with the new boundary that TIdMessage.SaveToStream() generates.
To make sure both SMTP and IMAP4 are in sync, they need to receive the same data. Try calling TIdMessage.SaveToStream() manually first with the TIdMessage.NoEncode property set to False, then set the TIdMessage.NoDecode property to True and call TIdMessage.LoadFromStream() to reload the saved data as-is into the TIdMessage.Headers and TIdMessage.Body properties, then call TIdSMTP.Send() and TIdIMAP4.AppendMsg() with the TIdMessage.NoEncode property set to True so the TIdMessage.Headers and TIdMessage.Body are sent as-is.
I know, this goes against what the TIdIMAP4.AppendMsg() comments/docs say to do. AppendMsg() does not currently take MIME into account at all, so it does not ensure the MIME boundary in the header and body match each other. I will try to check in a fix for that. For Indy 11, Indy's entire MIME handling system is going to be redesigned, so I'll make sure it is possible to preserve boundaries, and/or to specify custom boundaries, so AppendMsg() can match the body boundary to the header boundary better.
IMAP4 is a very tricky protocol to work with in general.
Related
Using Indy 10.1.5 (the version shipped with D2007), I'm composing and sending an email message as part of an automated internal process.
The email is sent fine, but when the recipient receives the message the time appears incorrectly in the email client, causing the message to incorrectly sort in the inbox. This has caused the recipient to overlook the message (because it wasn't in the inbox in the proper sequence and scrolled off the bottom), causing minor processing delays.
Both the sender and recipient in the US Eastern time zone (UTC -0400). The message header is correctly showing the message date, but without including a time zone:
Date: Mon, 3 Aug 2015 11:12:21 +0000
When the email is received and viewed in Outlook, the message is being shown with the UTC offset:
Mon 08/03/2015 7:12 AM
The code that creates the message is pretty simple (copied/pasted and then anonymized and simplified). It creates a relatively short message body (providing info about the file attached), creates the attachment, and sends the message. (try..except and try..finally removed for brevity - they exist in the actual code.)
Msg := TIdMessage.Create;
// Also tried using False and setting Date property manually
Msg.UseNowForDate := True;
for i := 0 to NumAddr do // Number of recipients
begin
Msg.Recipients.Add;
Msg.Recipients[Msg.Recipients.Count - 1] := RecipAddr[i];
end;
Msg.FromList.Add;
Msg.FromList[0].Name := Sender Name;
Msg.FromList[0].Address := SenderAddress;
Msg.Subject := 'Some text';
Msg.Body.Add('A few lines of text providing summary info.');
TIdAttachmentFile.Create(Msg.MessageParts, FileToAttach);
Mail := TIdSMTP.Create;
Mail.Host := PrimaryMailServer;
Mail.Connect;
Mail.Send(Msg);
Mail.Disconnect;
I've read through the Indy documentation and examined all of the properties I can find for both TIdSMTP and TIdMessage, and can't find anything else that would correct this time zone mismatch.
Can anyone see what it is I'm missing here?
10.1.5 is an outdated version of Indy 10. The current version is 10.6.2.
There were some UTC related bugs in earlier versions of Indy 10. In this case, there was a bug in Indy's OffsetFromUTC() function, which retrieves the local machine's UTC offset and is used when calculating the timestamp for outgoing emails. You should upgrade to a modern version of Indy 10, so you have the latest fixes, features, architectural changes, etc.
If you cannot upgrade, you will have to set the TIdMessage.UseNowForDate property to false and provide your own timezone-adjusted TDateTime value in the TIdMessage.Date property to account for Indy's faulty offset, so a proper timestamp value is sent.
I have a problem with function TIdIMAP4.ListSubscribedMailBoxes(AMailBoxList: TStrings): Boolean; with this implementation :
function TIdIMAP4.ListSubscribedMailBoxes(AMailBoxList: TStrings): Boolean;
begin
{CC2: This is one of the few cases where the server can return only "OK completed"
meaning that the user has no subscribed mailboxes.}
Result := False;
CheckConnectionState([csAuthenticated, csSelected]);
SendCmd(NewCmdCounter, IMAP4Commands[cmdLSub] + ' "" *',
[IMAP4Commands[cmdList], IMAP4Commands[cmdLSub]]); {Do not Localize}
if LastCmdResult.Code = IMAP_OK then begin
// ds - fixed bug # 506026
ParseLSubResult(AMailBoxList, LastCmdResult.Text);
Result := True;
end;
end;
When I debug I see that the LastCmdResult.Text stringlist is empty, but the LastCmdResult.FormattedReply stringlist has all folders on my email server (Inbox, Sent, Trash, ...). When I tried to use LastCmdResult.FormattedReply count or text, it had immediately lost its data and gave LastCmdResult.FormattedReply.Count=0 and LastCmdResult.FormattedReply.Text=''. So I'd like to know if there is a way to enter the data inside LastCmdResult.FormattedReply and get my email server folders or there is another way to solve my problem ?
I have a problem with function TIdIMAP4.ListSubscribedMailBoxes(AMailBoxList: TStrings): Boolean; with this implementation :
Works fine for me when I try it using the latest SVN version of Indy.
When I debug I see that the LastCmdResult.Text stringlist is empty, but the LastCmdResult.FormattedReply stringlist has all folders on my email server (Inbox, Sent, Trash, ...).
When I run it, the opposite happens. LastCmdResult.Text contains the expected text, and LastCmdResult.FFormattedReply is empty (notice I mention the FFormattedReply data member directly, see below).
When I tried to use LastCmdResult.FormattedReply count or text, it had immediately lost its data and gave LastCmdResult.FormattedReply.Count=0 and LastCmdResult.FormattedReply.Text=''.
That is by design. The FormattedReply property is intended to be used by a client to parse a server reply so it can populate TIdReply's property values, and to be used by a server to generate a new reply using TIdReply's property values. So, you cannot read from the FormattedReply property on the client side.
So I'd like to know if there is a way to enter the data inside LastCmdResult.FormattedReply and get my email server folders or there is another way to solve my problem ?
The whole purpose of ListSubscribedMailBoxes() is to return the folder names in the AMailBoxList parameter. If that is not working for you, then either
you are using a older/buggy version of Indy.
your server is sending the data in a format that TIdIMAP4 is not able to parse.
Without knowing which version of Indy you are actually using, or what the server's reply data actually looks like, there is no way to diagnose your issue one way or the other.
I'm trying to pull multipart emails in MIME format from an IMAP server using Indy 10.5.5 in Delphi 2010. These are the lines of code that I'm having trouble with are below, where I instatiate the curMessage object, retrieve a message into it, and then call CountParts:
var
curMessage: TIdMessage;
IMAP4: TIdIMAP4;
msgIndex: Integer;
begin
...
curMessage := TIdMessage.Create(nil);
IMAP4.Retrieve(msgIndex, curMessage);
curMessage.MessageParts.CountParts;
//code that checks counts
//and
end;
I then have some code that checks the various count properties of curMessage.MessageParts (i.e. TextPartCount). However, the CountPart procedure isn't returning anything, because the Count property referenced in the procedure block is 0, even though I've verified that the message is retrieved and placed into the curMessage.
One thing I've noticed, and haven't gotten to the bottom of yet, is that IsMsgSinglePartMime is coming back as true, even though all the messages on the server have Content-Type: multipart/mixed;.
Any help would be really appreciated.
What am I missing here? I can provide more code if needed,
Without seeing the actual email data, it is difficult to say for sure exactly why the data is not where you expect it to be. But if the TIdMessage.IsMsgSinglePartMime is getting set to True then that means that either:
TIdMessage.Encoding is meMIME but TIdMessage.MIMEBoundary.Count is 0, meaning there was no MIME boundary value detected in the top-level Content-Type header. If the Content-Type is a 'multipart/...' type, a boundary is required. If it is present, it is likely malformed in a way that prevented Indy from parsing it.
TIdMessage.Encoding is mePlainText but TIdMessage.ContentTransferEncoding is either 'base64' or 'quoted-printable'.
In either case, if there is body content present then it would end up in the TIdMessage.Body property if it is textual data, otherwise it would end up in the TIdMessage.MessageParts as an attachment instead. Since TIdMessage.MessageParts.Count is 0 in your case, the data is either in TIdMessage.Body, or is got discarded.
You may want to consider upgrading to a newer Indy version. The version shipped with D2010 is pretty old, and there have been fixes/changes made to TIdIMAP4 and TIdMessage (and its internal parsers) in recent years.
I have some files uploaded at a filehoster which I want to download programmatically, using Delphi. They don't require any captchas or the like, normally you simply press a button and you get the file. Let's take this as an example.
Now I thought I could simply take the URL the Download Now - Button is pointing at, use an TIdHTTP.Get request and save it with a MemoryStream / Filestream / whatever. Copying the link address leads to this site, which, when entered into my browser pops up the download prompt.
var
MemStream: TMemoryStream;
code: string; // added for solution
number: integer; // added for solution
begin
with TIdHTTP.Create(nil) do
try
HandleRedirects := true;
System.Delete(code,1,AnsiPos('var n =',code)+7); // added
number := StrToInt(AnsiLeftStr(code,AnsiPos(' ',code)-1)) + 1; // added
MemStream := TMemoryStream.Create;
try
// Get('http://www56.zippyshare.com/d/5862319/604061/bgAvgTable.png', MemStream);
Get(TIdURI.URLEncode('http://www56.zippyshare.com/d/5862319/' + IntToStr(number)
+ '/bgAvgTable.png'), MemStream); // added for solution
MemStream.SaveToFile('test.png');
finally
MemStream.Free;
end;
finally
Free;
end;
end;
However, using a checking tool I found that it contains a 302 redirect to the original site, thus when performing the GET-request I have to set HandleRedirects to avoid error messages and I get the HTML code of the original site rather than the file I had suspected.
So, I am kind of confused about how
1) I somehow get the file from my browser though the URL only contains a 302 redirect to the previous page and
2) I can achieve the same from within my code. Any chance someone of you might educate me a little there ? ;)
EDIT
Thanks to your input I could find the issue, turns out that the address I have to use gets generated using a random number, which is to be found in the original source. So posting a request to get the number first does the trick. I have edited the code accordingly.
File hosting sites make different tricks to ensure you was not hotlinking and show you advertisement and perhaps counter. There can be
simple analysis of HTTP Referrer field in the request
setting and checking session-unique cookies
having HTTP Forms with hidden one-time values, and Download button would be not the link but the form's Submit action.
generating one-time hashed URL, and encoding different parameters like your IP and your browser name into it
maybe more
Tools like USDownloader and JDownloader makes a lot of attempts to circumvent it.
While zippyshare seems to be more liberal, it still cannot afford hotlinking and should implement at least some measures of self-defense.
When analysing traffic - start with absolutely fresh browser loading zippyshare page for the 1st time in its life and check it all.
As i re-load the page few times i see that the number "604061" is different and link keep changing time and again after each reload. You probably have to load the page, parse the link, set the HTTP referer and only then download the file.
You do not show the HTTP traffic logs so it is hard to tell for sure.
The server may be checking for some trace to avoid the file to be downloaded programmatically.
It may be anything the hostmaster wants to check, from a wide range of possibilities, but the most typical check is the referrer.
When you navigate in a web browser from one page to another using an link, the browser adds the first page as a referrer to the second page in the request header.
Indy have support for you to add a referrer:
IdHTTP1.Request.Referer := 'http://www.any.other.page';
If the check fails, the server script just redirects the input to the donwload page. This is done to show advertising or to filfull other goals of the file hosting service.
I'm wanting to create a CloudFlare client in the Firemonkey framework. For those who don't know, CloudFlare serves as a CDN of sorts for anyone with a website. They have an API available, and as with many web API's, they are using JSON with a token-based system. It requires both the account email address and the account token to access the API. It runs on HTTPS, and as you can imagine, attempting to access the API via HTTP/non-SSL simply produces null results.
The application i wish to create would serve as an all-in-one management tool, intending to eliminate the need for me to use a web browser to manage my CloudFlare settings. I'm having the most basic of issues; SSL POST. See, i can submit an API request via a web browser and get a list of results (e.g. https://www.cloudflare.com/api_json.html?a=stats&z=DOMAIN&u=EMAIL&tkn=TOKEN - Personal details removed for obvious reasons), but i'm unsure how i would go about getting these same results (or any results from the API for that matter) in Firemonkey.
I've got Overbyte ICS with SSL installed, as well as the basic bundled Indy components, but i'm struggling to get started with this. I need to post a list of parameters to https://www.cloudflare.com/api_json.html via HTTPS/SSL, but i've very little idea on where to start. I've seen a few various example around SO, mostly using ICS, but i've been unable to find any specific to posting with multiple parameters, how i should format it, etc.
One example i tried was using ICS TSSLHttpCli, writing my parameters as a single string (i.e. a=stats&z=DOMAIN&u=EMAIL&tkn=TOKEN), writing that to the SendStream of TSSLHttpCli, seeking to 0,0, setting the URL (i.e. https://www.cloudflare.com/api_json.html?), and then calling the Post method. However, this gives me Connection aborted on request. This is the code i've tried (though i've replaced personal details with generic values);
var
Data : AnsiString;
RcvStrm, SndStrm : TMemoryStream;
begin
SndStrm := TMemoryStream.Create;
RcvStrm := TMemoryStream.Create;
Data := '?a=stats&z=MYDOMAIN&u=MYEMAIL&tkn=MYTOKEN';
SslHttpCli.SendStream := SndStrm;
SslHttpCli.SendStream.Write(Data[1],Length(Data));
SslHttpCli.SendStream.Seek(0,0);
Memo1.Lines.LoadFromStream(SndStrm);
ShowMessage('Waiting!');
SslHttpCli.RcvdStream := RcvStrm;
SslHttpCli.URL := 'https://www.cloudflare.com/api_json.html';
SslHttpCli.Post;
Memo1.Lines.Clear;
Memo1.Lines.LoadFromStream(RcvStrm);
Memo1.Lines.Add('.....');
RcvStrm.Free;
SndStrm.Free;
ShowMessage('Complete!');
end;
The ShowMessage procedures are simply there to provide a visual break so i can see what data is in the stream at each time. When Memo1.Lines.LoadFromStream(SndStrm); is called, i get a single question mark the contents of the Data in the memo as expected.
When i call Memo1.Lines.LoadFromStream(RcvStrm);, i expect it to add the return result from the API, and then the 5 dots underneath it. However, this does not happen, and it's apparent that the message i'm receiving is related to the issue. I'm assuming i've not set up the data correctly, but i'm simply unsure exactly how i should format it prior to attempting to post it. I've even commented out everything below Memo1.Lines.LoadFromStream(RcvStrm); to the end to see whether the Clear procedure is called on the memo, but the contents of the memo remain the same as they were when i called LoadFromStream(SndStrm). The final ShowMessage is also not called.
I initially tried using String instead of AnsiString, but this simply output the first character of Data rather than the whole string.
There could be numerous reasons why it's not working (all details for API access are correct, so it's an issue with the code), but i need someone with more experience and knowledge to point me in the right direction.
My network coding knowledge is limited, and i've only dealt with basic SQL and FTP in Delphi so far. I've still got to work with the parsed JSON once i do get past this step, but for now, can anyone assist me in this endeavor so i can get started?
I noticed you seemed to solve this with a GET request, but I noticed two immediate problems with your POST request:
as Runner Suggested, drop the '?' in your data. The '?' is only used when appending parameters to the URL in a GET request.
You never set the content type of the HTTP Request (should be application/x-www-form-urlencoded). You can do this with the following code:
SSLHttpCli.ContentTypePost := 'application/x-www-form-urlencoded';
Just a helpful thought. I checked https://www.cloudflare.com/docs/client-api.html and they mention that POST requests are accepted. It's possible the server rejects requests that have any other content type.
Just some food for thought if you ever need to contact another API via POST requests and want to use the Overbyte Components.
Hope the info is useful!
Try this;
SndStrm := TMemoryStream.Create;
RcvStrm := TMemoryStream.Create;
Data := 'a=stats&z=MYDOMAIN&u=MYEMAIL&tkn=MYTOKEN';
SndStrm.Write(Data[1], Length(Data));
SndStrm.Seek(0, 0);
SslHttpCli.SendStream := SndStrm;