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?
MainMaAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

cwwkieCommented:
looks like the send function has a size limitation. You can do a test this way:

send(skMain, cBuffer, 2048, 0);
send(skMain, cBuffer+2048, (int)strlen(cBuffer)-2048, 0);

Now the received attachment should be larger.
rstaveleyCommented:
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));
MainMaAuthor Commented:
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 ...".
Announcing the Winners!

The results are in for the 15th Annual Expert Awards! Congratulations to the winners, and thank you to everyone who participated in the nominations. We are so grateful for the valuable contributions experts make on a daily basis. Click to read more about this year’s recipients!

grg99Commented:
Always always always check the result code from any function call.  

And check the returned message from the server too.

cwwkieCommented:
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.
MainMaAuthor Commented:
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_KKKkkkjjwq"
...
--KkK170891tpbkKk__FV_KKKkkkjjwq
Content-Type: image/jpeg;
      name="image.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename= "image.jpg"

/9j/4AA...
...
...K1E/9kA
--KkK170891tpbkKk__FV_KKKkkkjjwq--
.

If, at the end, I write:

--KkK170891tpbkKk__FV_KKKkkkjjwq--
abc
.

in the received mail I see

...
--KkK170891tpbkKk__FV_KKKkkkjjwq--
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...
rstaveleyCommented:
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?
cwwkieCommented:
> If, at the end, I write:

> --KkK170891tpbkKk__FV_KKKkkkjjwq--
> abc
> .

> in the received mail I see

> ...
> --KkK170891tpbkKk__FV_KKKkkkjjwq--
> 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.
MainMaAuthor Commented:
> 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.
cwwkieCommented:
>> 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.

It is just an extra way of error checking. Before sending the dot, you should not receive any response from the server. You cannot test this now.

And you don't include the EHLO/MAIL/RCPT/DATA and QUIT in the message either I hope?

> 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.

But you said you sent the same with telnet, and it had the same problem. So the problem is the smtp server, the pop3 server you use to recieve the message or the message itself. You only know that the original question is resolved, as the code you are using is correct:

> send(skMain, cBuffer, (int)strlen(cBuffer), 0);

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
MainMaAuthor Commented:
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...
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
C++

From novice to tech pro — start learning today.