Интересно? могу добавить свой рабочий конф 
Да, интересно.
И, если можно, не просто рабочий конфиг, но и с объяснениями, где что на что влияет.
Шоб под себя можно было адаптировать.
Можно...
address_verify_sender = postsys@example.ru
address_verify_map = btree:/var/spool/postfix/verified_senders
smtpd_client_restrictions =
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
check_recipient_access hash:/etc/postfix/maps/white_list
check_recipient_access hash:/etc/postfix/maps/black_zone
check_helo_access hash:/etc/postfix/maps/you_no_me
reject_non_fqdn_hostname
reject_invalid_hostname
reject_non_fqdn_sender
reject_unknown_sender_domain
reject_unknown_recipient_domain
reject_non_fqdn_recipient
reject_rbl_client dul.ru
reject_rbl_client zen.spamhaus.org
reject_rhsbl_sender dsn.rfc-ignorant.org
reject_unverified_sender
permit
smtpd_data_restrictions =
reject_multi_recipient_bounce
Начнем с самого интересного.
address_verify_sender = postsys@example.ru
address_verify_map = btree:/var/spool/postfix/verified_senders
Здесь указываются настройки для проверки отправителя, т.е. наш сервер отправляет запрос серверу, от которого идет сообщение, и проверяет наличие у него пользователя от кого адресовано сообщение. Соответственно проверка осуществляется от реально существующего пользователя вашего домена ( address_verify_sender = postsys@example.ru). Несуществующих пользователей postfix собирает в БД verified_senders. Сначала создается пустой файл, где нибудь в каталоге /var (БД сильно будет расти), затем командой
postmap btree:/var/spool/postfix/verified_senders
создается карта, или БД.
UPDДля этого конечно нужно, что бы файл verified_senders был доступен для чтения и исполняемым.
И еще, после директивы smtpd_recipient_restrictions = (и остальных) перед параметрами не забываем пробелы, это обязательное условие. Иначе все параметры были бы перечислены в строчку.
smtpd_recipient_restrictions проверяет почту на этапе RCPT TO: SMTP соединения, поэтому эти рестрикшены применяются к этапам HELO и MAIL FROM: но не применяются к последующим этапам – DATA и т.д. В принципе, для нас это нормально.
permit_mynetworks
reject_unauth_destination
Трогать не надо, здесь все нормально, не дает почтовому серверу превратиться в открытый релай.
reject_unknown_sender_domain
reject_unknown_recipient_domain
Проверяют существование домена соответственно для отправителя и получателя, и если он не существует – делает REJECT.
Рестрикшены с non_fqdn требуют указания полностью определенного доменного имени на соответствующих этапах SMTP соединения, много спам рассылок прокалывается на этом.
В check_recipient_access перечислены получатели, для которых почта должна быть принята (white_list), или соответственно отвергнута (black_zone). Содержимое этих файлов следующее:
white_list:
domain.ru OK
user@domain.ru OK
black_zone :
domain.ru REJECT
user@domain.ru REJECT
Все карты создаются командой postmap
reject_rbl_client использует черные ДНС для фильтрации спама, у меня настроено, соответственно три штуки. Больше всего отсекается спама именно этими рестрикшенами, а именно zen.spamhaus.org .
И последним в группе smtpd_recipient_restrictions идет reject_unverified_sender о котором говорилось ранее, а именно проверка адреса отправителя на достижимость.
Порядок имеет значение. Фильтры применяются именно в том порядке, в котором стоят, поэтому самые «тяжелые» для сервера фильтры убраны вниз.
reject_multi_recipient_bounce – вырезает множественную рассылку от отправителя с пустым именем. Применяется на этапе DATA, когда все адресаты будут известны.
Конфигурация не очень сложная, в сети есть и посложнее, но лично меня, и мою организацию устраивает. Напомню, что еще юзаю амавис с клам-ди и спамассассином.