Re: Trying to find out cause of blacklisting

[email protected] wrote on Fri, 12 May 2006 15:34:02 -0400:

> As I understand it, applying the neccessary patch(es) to qmail to reject 
> instead of bouncing email would break at least two critical 
> functionalities, that of the .qmail-default alias, and ezmlm mailing 
> lists that we run.  At least one of these patches won't work properly 
> with vpopmail virtual domains because of permissions issues.

In that case, maybe you should consider using a different MTA.

By allowing qmail to send bounces you are indeed observing 
RFC821/RFC2821, but those RFC's were drafted in a bygone era when spam 
wasn't the problem it is today.

Nowadays, the smart thing to do is to avoid getting yourself into the 
situation in the first place whereby your MTA accepts mail and then, 
after the SMTP exchange has completed, realizes it can't deliver it.

I'm not saying that you were listed for any of the following reasons in 
particular (not being a SC deputy I don't know any more than you about 
the nature of the stuff hitting SpamCop's traps), these are just 
examples of what your MTA should be doing in today's e-mail climate.

- As far as mail sent to non-existent users is concerned there really is 
no excuse. Your MTA should know whether it'll accept the mail as soon as 
the MAIL FROM and RCPT TO data has been transmitted, and should reject 
the inbound mail out of hand before the DATA is even sent.

- The same applies to over-quota mailboxes. The size of inbound mail is 
conveyed in the ESMTP handshake but of course, there's nothing to 
prevent spamware from lying about that like it lies about everything 
else. Consent to the remote server sending its DATA but don't 2xx it 
until you're sure the message will "fit" into the user's mailbox. 5xx it 
if it won't.

- Infected mail should be accepted and then diverted to a "held" folder 
for later scrutiny, or it should be rejected straight after the DATA 
part of the SMTP transaction. Never send stupid "Your computer might be 
infected because we received a virus from your address" notifications 
because the sender address in viruses is virtually always forged.

- The same as for viruses applies to messages detected as spam.

- Messages fired off in response to inbound mail are no longer viable. 
This includes things such as out-of-office autoreplies, all challenge/ 
response systems, and mailing list management software that sends out 
"You must subscribe to the list first" messages in response to list 
traffic sent by non-members.

If the MTA and associated software you're running are not able to 
function as described above then you *will* be listed periodically on 
blocklists. It is an unescapable fact of life in a world where 90% of 
e-mails floating around the 'Net are spam and viruses carrying forged 
information.