Rob Becker:
[ Charset ISO-8859-1 unsupported, converting... ]
> I have a postfix relay that's currently having some issues with some
> spam content that we are receiving. Every hour or so we are receiving
> 300 - 600 messages with in a few seconds. A lot of the email messages
> have malformed TO addresses which is causing the recipient to fail (we
> are assuming) processing. This failure on the recipient side is
> keeping the postfix connection open for the max of 10 minutes, which
> then gets closed by postfix. At that time all of the messages that
> were attempted to be sent are deferred and attempted later.
> Example:
What piece of technology is the receiving end, what is deciding
that a recipient is bad, what does the SENDING Postfix log when
this recipient is bad, and why is the receiving end dropping the
TCP connection without properly finishing the SMTP protocol first?
> Sep 9 14:00:34 cudubcorrel502 postfix/qmgr[3109]: 09B3331223:
> to=<EMAIL>, relay=none, delay=1, status=deferred (delivery temporarily
> suspended: conversation with 10.35.76.48[10.35.76.48] timed out while
> sending end of data -- message may be sent more than once)
> Sep 9 14:00:34 cudubcorrel502 postfix/qmgr[3109]: 1752E31224:
> to=<EMAIL>, relay=none, delay=0, status=deferred (delivery temporarily
> suspended: conversation with 10.35.76.48[10.35.76.48] timed out while
> sending end of data -- message may be sent more than once)
>
> Would it be a good idea to limit the initial_destination_concurrency
> and default_destination_concurrency_limit in hopes of sending the
> emails in smaller chunks?
Why is the receiving end dropping the TCP connection without
properly finishing the SMTP dialog?
> We have been able to narrow down the spam messages to about 10
> MAIL-FROM accounts which we could easily block, but for some reason we
> are unable to block them. I have placed the emails in the
> common_spam_sendersdomain which seems to be over looked. Why is that?
>
> Example:
>
> common_spam_sendersdomain:
> [EMAIL PROTECTED] REJECT
> [EMAIL PROTECTED] REJECT
>
> #
> # SMTP RESTRICTIONS
> #
> disable_vrfy_command = yes
> smtpd_helo_required = yes
> smtpd_recipient_restrictions =
> warn_if_reject, reject_non_fqdn_sender,
> reject_non_fqdn_recipient,
> reject_unknown_recipient_domain,
> permit_mynetworks,
> reject_unauth_destination,
> check_sender_access hash:/etc/postfix/common_spam_senderdomains,
> reject_unknown_sender_domain,
> check_recipient_access hash:/etc/postfix/roleaccount_exceptions,
> warn_if_reject, reject_invalid_hostname,
> warn_if_reject, reject_non_fqdn_hostname,
> warn_if_reject, check_helo_access hash:/etc/postfix/helo_access,
> check_client_access hash:/etc/postfix/client_access,
> permit
>
> smtpd_data_restrictions =
> reject_unauth_pipelining,
> permit
>
> I have also grabbed a few of the messages that are (I think causing
> the issues). If I do a 'strings' on the email I see the following:
>
> [EMAIL PROTECTED]
> client_name=n6-19.adsl.co.ruA
> client_address=82.142.185.19A.message_origin=n6-19.adsl.co.ru[82.142.185.19]A
> helo_name=n6-19.adsl.co.ruA
> protocol_name=SMTPO
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> .........
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]"[EMAIL PROTECTED]"[EMAIL PROTECTED]
>
>
> I'm assuming the above line is causing the issue on the destination
> server as it can't process the email address correctly. Can postfix
> block all incorrect formed addresses?
The above address is correctly formatted. The fact that it apparently
confuses some down-stream software notwithstanding.
If you don't like an address see the first example in "man regexp_table".
Wietse
