Не совсем понятно, почему нарезается по 78 символов. По идее длина строки должна быть кратна 4-м,
т.е. 76+CRLF=78.
Но не 78+CRLF.

RFC "рекомендует" это число. А поскольку это начало, я не делал ещё многих настроек. К примеру, у
меня уже версия, которая не кодирует "тупо" тело письма в base64, а проверяет возможность сервера
принимать 8-ми битные данные. Сейчас сижу читаю RFC по команде AUTH, хочу поддержку других типов
авторизации включить.

А насчёт же имено 76+CRLF=78, вот выдержка из RFC 2822
===
and SHOULD be no more than 78 characters, excluding the CRLF
===

А насчёт же имено 76+CRLF=78, вот выдержка из RFC 2822
===
and SHOULD be no more than 78 characters, excluding the CRLF
===

А насчёт же имено 76+CRLF=78, вот выдержка из RFC 2822
===
and SHOULD be no more than 78 characters, excluding the CRLF
===

Честно сказать, странное требование, т.к. кодировка идет три байта- четыре символа. Логично было
бы брать четверками, но почему они так решили - загадка... Т.е. кодировшик принимает по три байта
- выдает четверку, а в этом случае мы ее почему-то должны разбить... Полагаю, что эта цитата
относится к произвольной ASCII строке, общая длина которой исторически 80 символов.
Конечно, декодер может просто игнорировать CRLF и просто сливать все в единую строку. Но не факт,
что это где-то не глюкнет. Например, кодер totalcommander дает все же 76 знаков.

Хорошо отрабатывает программа отсылку почты. Однако при включении класса в проект при компиляции
возникает ошибка:
Unknown TUATTACH - Undefined.
Кроме того при попытке закрыть программу выдается ошибка Несовпадение типа данных и свойство STATE
не найдено. Не хотелось бы  разбираться в чужом классе, а с разрешения его использовать в своих
приложениях. Хотелось бы помощи. Да не сказал, что не зависимо от ошибок почта ходит и  отправляет
вложенные файлы....., но очень медленно.

ProgressBar? А все остальное здорово!

все понравилось, все работает с моей машины, но когда приложение запущено с клиентской машины то
вываливается в процедуре PROCEDURE INIT при создании класса

*****
oErr=.NULL.
 TRY
  .WinSock=CREATEOBJECT("MSWinsock.Winsock")
 CATCH TO oErr
 ENDTRY
 IF !ISNULL(oErr)
  MESSAGEBOX("Ошибка создания сокета",48,.Caption)
  RETURN .F.
 ENDIF
*****
выдает "Ошибка создания сокета"

подозреваю что чегото не хватает на клиентской машине, вопрос чего?? я просто начинающий, очень
сложно разобраться заранее спасибо

очень хорошая работа, все выполняется отлично..
вопрос : поддерживается ли подписывание/шифрование отправлений?

Не ужели у кого то это работает?
У меня вылетает в файле mailer.prg на строке:
nTZ=CTOBIN(SUBSTR(cZoneInfo,1,4),"4RS")+CTOBIN(SUBSTR(cZoneInfo,169,4),"4RS")

Из-за несоответствия числа аргументов.
Встроенная функция CTOBIN может иметь только один аргумент. VFP 6.0  VFP 8.0

Установил VFP 9 и CTOBIN заработало. Но все равно не отправляет. 
Нужно чтобы через oSMTP.RemotePort=465 отправляло а не через 25.

Нашел серьезную ошибку в FUNCTION SendMessage
Из -за этого не работала отправка множества файлов в аттаче через массив.
Например при попытке отправить 4 разных файла отправлялся 4 раза первый файл.

Нужно заменить вот это:
.SendAttach(tuAttach)
на вот это:
.SendAttach(tuAttach[nI])