akelsey

Слушайте, ну вы сами себе напридумывали костылей. Теперь ждёте что кто-то их разрешит. Вариант написать свой майл.ру со своей ситемой прав вам наверное не подойдет. Других вариантов задачу решить именно так как вы написали - нет. Как сервис должен догадаться что все эти 30 пользователей имеющих один и тот же логин и пароль ломящихся в один почтовый ящик - это разные люди?
Телепатически?
Если мыслить категориями MS Exchange например:
Почтовый ящик - индивидуальная вещь, принадлежащая отдельному пользователю.
Есть общий почтовый ящик - этот ящик уже может использоваться несколькими людьми и там могут быть настроены права, на чтение, на отправку, на удаление, полный доступ - на уровне папок/AD/mailbox.
Есть лист рассылок - когда нет никакого почтового ящика - просто информация падает всем кто входит в этот список.
Вообщем-то и всё. (за это берут очень не кислые деньги). Возможно есть еще более продвинутые сервисы эл. почты для групповой работы (более гибкие чем Exchange), но я их не знаю. Да и сомневаюсь что они есть.

Что если просто купить новый диск и добавить пространства на почтовый сервер? И не придумывать болты с левой резьбой?

Только увеличите нагрузку на свой сервер и кол-во исходящего трафика. Спамеру до лампочки NDR от вашего почтовика.

Настройка - Редактор и просмотр сообщений - HTML Viewer - Загружать встроенные изображения с внешних сайтов - Выбрать требуемую политику (Что нибудь вроде - загружать все).
Отсюда:

Вы можете настроить также загрузку встроенных изображений с внешних сайтов, выбрав одну из опций – никогда, всегда или отклонять неизвестные. Чтобы задать более точные настройки, нажмите кнопку Настроить – будет открыто окно Управления загрузки изображений.

Первая же ссылка в google по запросу mount webdav centos 7 - наведет вас на нужный ресурс...

Концепция миграции немного неверная, правильно было бы создать на эксчендже ту же самую зону (можно думаю сделать это и на данном этапе), т.е.
* создаем Accepted Domain - company.com - тип Internal Relay
* создаем SMTP connector для company.com - смарт-хосты - указывают на гугл
* меняем MX записи на Exchange IP
с этого момента логика будет следующая - почта приходит на эксчендж - если ящика vasya@company.com нет - то всё улетает на Gmail.com, если есть - почта остается уже только на эксчендж.
по imap - почта синкается в локальный pst на объёмный сторадж на сервере - после полной синхронизации почтового ящика, в ночь создается майлбокс пользователя на Exchange, пароль на Gmail меняется, что бы он не мог туда заходить.

Единственный вопрос отправка почты на company.com - когда пользователь всё еще сидит на гугл, а другой переехал на Exchange - но тут нужно маны гугла читать по настройке планов миграции (или чужой опыт).

PS
После миграции последнего юзера - тип домена меняется на Authoritative - smtp connector - удаляется.

Как я понял на Exchange в качестве смарт-хоста указан постфикс.
Первое что нужно сделать это проверить телнетом с сервера Exchange доступ на 25ый порт Postfix. Если он недоступен, то Expiration закономерен, Exchange пытается отправить письма на несуществующий хост.

Google довольно требователен к почтовым серверам, в последнее время требует не только SPF, корректный hostname, TLS, но и DKIM. Вот так сразу без диагностики вашего письма - причину понять невозможно. Нужно смотреть служебные заголовки письма и анализировать, искать возможные причины подобного поведения.

Почтовый сервер обязателен.

powershell + smtprelay + taskscheduler:

$emails = import-csv c:\temp\emailaddresses.csv
foreach ($email in $emails)
{
send-mailmessage -from $email.from -to $email.to -attachments ...
}
...

Это серверная задача, вам нужно провести редизайн, завести свой почтовый сервер, включить журналирование.
Можно сделать проще, закрыть 25ый порт внутри вашей сети на все кроме вашего SMTP-relay, который и будет журналировать всё. Правда можно заиметь проблему с SPF доверием...

Т.е. сайт должен отправлять почту от имени кучи заказчиков клиенту?
Вообщем то возможно, если владельцы доменов почтовых согласятся прописать IP адрес вашего сервера в SPF, ну т.е. сделают вас доверенным адресом для рассылки от имени их домена.
Это при условии что я правильно понял вопрос. (Наличие или отсутствие файла - несущественно)

Когда ни один коммерческий - не устраивает, нужно делать свой.
Можно делать своё, с нуля, а можно взять например Zimbra (под Linux) или MailEnable(под Windows).

Картинки обычно запрещены для скачивания с внешних ресурсов в корпоративных Outlook.
Лучше делать embed, и заминять их в письме на cid:picturename.jpg
Но тут нужен разумный компромисс, если картинки огромные, лучше так не делать конечно...

From отсюда:

Mail sent from unverified domains or domains without valid SPF and DKIM records will be rejected with the reject_reason, unsigned.

Это говорит о том что сообщение с сервера откуда вы пытаетесь отправить от имени gmail.com - не может быть отправленно, т.к. в SPF для домена гугл вероятно нет вашего айпишника.