Home/ Questions/Q 9145063
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T10:25:16+00:00

I have successfully written a program which sends Hebrew HTML emails coded as UTF-8

  • 0

I have successfully written a program which sends Hebrew HTML emails coded as UTF-8 along with embedded pictures and attachments.

I have noticed that whilst emails with attachments of type JPG or TXT get sent rapidly, emails with PDF attachments take a long time (a minute) to be sent. I arranged for a tmemo component to receive the AStatusText string from the SMTP component’s OnStatus event, and saw that the program was encoding both the text (correct) and the attachment (incorrect).

How can I prevent the attachment from being encoded and thus have the email sent faster?

Here is the log from the SMTP component showing the time

18:44:01 smtp: Connected.
18:44:04 smtp: Encoding text
18:44:04 smtp: Encoding attachment
18:44:04 smtp: Encoding attachment
18:45:05 smtp: Disconnecting.
18:45:05 smtp: Disconnected.
18:45:05 disconnected

The minute was necessary to encode a PDF file of size 491KB. During this time the program is unresponsive (I thought that the program was hung until I looked at the log).

Maybe I should ask a slightly different question: why does this have to be encoded?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    All attachments are ALWAYS encoded using MIME64, or else your email will not be readable by anybody but you. It isn’t your job to change how internet email works.

    The reason for your delay is probably either that the PDF is being “virus scanned” by your hosting company, or on the other hand, if you are attaching a giant PDF, and it’s taking a minute to encode it, I’m not surprised that a giant PDF file, when converted to MIME64, which is not a step you can skip, takes a long time. But your PDF is 491 KB, which is miniscule, so the delay may be on the server side, which may be scanning your PDF through. Remember that the SMTP process is a dialog of your-side-sends, then the other-side-responds. A delay before the other side responds is not something you can fix without understanding why the delay happens. The “no encoding” idea you had is not reasonable.

    However, virus/spam-scan is a reasonable hypothesis, which may be adding 30 seconds to your already-30-second normal transmit time. To test that hypothesis, rename your pdf from “test.pdf” to “test.p@d@f$”, and see if the transmit time drops from 60 seconds to about 30 seconds. You haven’t stated how fast your internet pipe is, or how large you think the MIME64 encoded EMAIL may be, but it could be 1.5x larger than your PDF, so around 600 to 800 kbytes. If you are on a very slow DSL or ISDN connection, then that would explain it too.

    • 0