MainMa
asked on
SMTP protocol
I encount the problem with my program, which sends an email with an attachement:
My program loads the beginning (before the attached file) and the end (after...) of the message, and generates base64 file. It sends the output via SMTP protocol, and saves generated data. We have:
send(skMain, cBuffer, (int)strlen(cBuffer), 0);
...
fwrite(cBuffer, (int)strlen(cBuffer), 1, file);
When I open the file, saved with fwrite, with Outlook Express, all is ok, and the attachement is perfect. But when I receive the mail, only a part of my attachement is there.
The size of this received attachement is always the same: 2,303 bytes. Why?
My program loads the beginning (before the attached file) and the end (after...) of the message, and generates base64 file. It sends the output via SMTP protocol, and saves generated data. We have:
send(skMain, cBuffer, (int)strlen(cBuffer), 0);
...
fwrite(cBuffer, (int)strlen(cBuffer), 1, file);
When I open the file, saved with fwrite, with Outlook Express, all is ok, and the attachement is perfect. But when I receive the mail, only a part of my attachement is there.
The size of this received attachement is always the same: 2,303 bytes. Why?
Read off how many bytes are sent. "send" sends as many bytes as it can before returning. You need to send the rest thereafter.
int sent_bytes = 0;
do {
int bytes = send(skMain, cBuffer+sent_bytes, (int)strlen(cBuffer)-sent_ bytes, 0)
if (bytes < 0) {/* Handle error */}
else sent_bytes += bytes;
} while (sent_bytes < strlen(cBuffer));
int sent_bytes = 0;
do {
int bytes = send(skMain, cBuffer+sent_bytes, (int)strlen(cBuffer)-sent_
if (bytes < 0) {/* Handle error */}
else sent_bytes += bytes;
} while (sent_bytes < strlen(cBuffer));
ASKER
If I write:
int iBytes = send(skMain, cBuffer, (int)strlen(cBuffer), 0);
printf("\nbytes sent: %i\n", iBytes);
iBytes has the same value of strlen(cBuffer). This value is higher than 2303 bytes, received by Outlook Express.
I also wrote another code to send the buffer:
char cSmallBuffer[1025];
for (unsigned int j = 0; j < strlen(cBuffer) / 1024 + 1; j++)
{
ZeroMemory(cSmallBuffer, 1025);
for (int i = 0; i < 1024; i++)
{
if (cBuffer[i] == 0) break;
cSmallBuffer[i] = cBuffer[j * 1024 + i];
}
send(skMain, cSmallBuffer, (int)strlen(cSmallBuffer), 0);
printf("%s", cSmallBuffer);
Sleep(50);
}
And it has the same effect.
For additional information, SMTP server answers "250 Ok: queued as ...".
int iBytes = send(skMain, cBuffer, (int)strlen(cBuffer), 0);
printf("\nbytes sent: %i\n", iBytes);
iBytes has the same value of strlen(cBuffer). This value is higher than 2303 bytes, received by Outlook Express.
I also wrote another code to send the buffer:
char cSmallBuffer[1025];
for (unsigned int j = 0; j < strlen(cBuffer) / 1024 + 1; j++)
{
ZeroMemory(cSmallBuffer, 1025);
for (int i = 0; i < 1024; i++)
{
if (cBuffer[i] == 0) break;
cSmallBuffer[i] = cBuffer[j * 1024 + i];
}
send(skMain, cSmallBuffer, (int)strlen(cSmallBuffer),
printf("%s", cSmallBuffer);
Sleep(50);
}
And it has the same effect.
For additional information, SMTP server answers "250 Ok: queued as ...".
Always always always check the result code from any function call.
And check the returned message from the server too.
And check the returned message from the server too.
cBuffer does not contain a dot (.) on a single line?
You can try to send the same message manually using a telnet session. Just to see whether it's not your mailserver which has a problem. Just open the file in notepad, copy and paste into telnet after the data command.
You can try to send the same message manually using a telnet session. Just to see whether it's not your mailserver which has a problem. Just open the file in notepad, copy and paste into telnet after the data command.
ASKER
cBuffer finishes with "\r\n.\r\n".
I tried to send the mail through Telnet session, it gives the same effect. The attachement is cut at the same location.
What is strange, that the mail I send is like this:
From: ...
To: ...
Subject: Test
Mime-Version: 1.0;
Content-Type: multipart/mixed;
boundary= "KkK170891tpbkKk__FV_KKKkk kjjwq"
...
--KkK170891tpbkKk__FV_KKKk kkjjwq
Content-Type: image/jpeg;
name="image.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename= "image.jpg"
/9j/4AA...
...
...K1E/9kA
--KkK170891tpbkKk__FV_KKKk kkjjwq--
.
If, at the end, I write:
--KkK170891tpbkKk__FV_KKKk kkjjwq--
abc
.
in the received mail I see
...
--KkK170891tpbkKk__FV_KKKk kkjjwq--
abc
So it must be the server, which cuts the end of the attached file. But why?
I will try to test my program with a different mailserver, and then I will tell you if it was ok...
I tried to send the mail through Telnet session, it gives the same effect. The attachement is cut at the same location.
What is strange, that the mail I send is like this:
From: ...
To: ...
Subject: Test
Mime-Version: 1.0;
Content-Type: multipart/mixed;
boundary= "KkK170891tpbkKk__FV_KKKkk
...
--KkK170891tpbkKk__FV_KKKk
Content-Type: image/jpeg;
name="image.jpg"
Content-Transfer-Encoding:
Content-Disposition: attachment;
filename= "image.jpg"
/9j/4AA...
...
...K1E/9kA
--KkK170891tpbkKk__FV_KKKk
.
If, at the end, I write:
--KkK170891tpbkKk__FV_KKKk
abc
.
in the received mail I see
...
--KkK170891tpbkKk__FV_KKKk
abc
So it must be the server, which cuts the end of the attached file. But why?
I will try to test my program with a different mailserver, and then I will tell you if it was ok...
Perhaps the server has porn filtering? [Only kidding!]
Have you tried decoding the attachment which you are sending just in case you've got your encoding wrong?
Have you tried decoding the attachment which you are sending just in case you've got your encoding wrong?
> If, at the end, I write:
>
> --KkK170891tpbkKk__FV_KKKk kkjjwq--
> abc
> .
>
> in the received mail I see
>
> ...
> --KkK170891tpbkKk__FV_KKKk kkjjwq--
> abc
>
> So it must be the server, which cuts the end of the attached file. But why?
But the end of the mail is the same. That would mean you miss something in the middle? It would be important to know what exactly is missing.
btw, I think cBuffer should not finish with "\r\n.\r\n". this last dot is part of the smtp protocol, not part of the mail message.
>
> --KkK170891tpbkKk__FV_KKKk
> abc
> .
>
> in the received mail I see
>
> ...
> --KkK170891tpbkKk__FV_KKKk
> abc
>
> So it must be the server, which cuts the end of the attached file. But why?
But the end of the mail is the same. That would mean you miss something in the middle? It would be important to know what exactly is missing.
btw, I think cBuffer should not finish with "\r\n.\r\n". this last dot is part of the smtp protocol, not part of the mail message.
ASKER
> Have you tried decoding the attachment which you are sending just in case you've
> got your encoding wrong?
Attachement is in base64, and, like I said before, the message is send to the SMTP server AND saved to the hard disk. The saved message is perfectly intact.
> this last dot is part of the smtp protocol, not part of the mail message.
Right. But cBuffer is the string, sent to SMTP server through SMTP protocol, so, in my program, IT IS the part of SMTP protocol, and not the mail message.
I tried to send the mail with a different SMTP server. The result is the same. So it is not the problem with the server.
> got your encoding wrong?
Attachement is in base64, and, like I said before, the message is send to the SMTP server AND saved to the hard disk. The saved message is perfectly intact.
> this last dot is part of the smtp protocol, not part of the mail message.
Right. But cBuffer is the string, sent to SMTP server through SMTP protocol, so, in my program, IT IS the part of SMTP protocol, and not the mail message.
I tried to send the mail with a different SMTP server. The result is the same. So it is not the problem with the server.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I have the solution!
In fact, attachement file was sent without "\r\n". And it seems that the server accepts only the lines with the length not too big. So when the server received my attachement file, it stored only the beginning.
While cwwkie posted lots of comments, and because nobody could guess the answer, I decided to accept his last comment...
In fact, attachement file was sent without "\r\n". And it seems that the server accepts only the lines with the length not too big. So when the server received my attachement file, it stored only the beginning.
While cwwkie posted lots of comments, and because nobody could guess the answer, I decided to accept his last comment...
send(skMain, cBuffer, 2048, 0);
send(skMain, cBuffer+2048, (int)strlen(cBuffer)-2048,
Now the received attachment should be larger.