You are viewing a plain text version of this content. The canonical link for it is here.

Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2005/05/31 17:14:00 UTC

Short term, but immediate, solution to spam volume.

Do to the incredibly high volume generated by Microsoft Windows spambots, I
feel that we need to allow somewhat more aggressive measures in the near
term, as in *NOW*.

I propose an interm measure to add support for a DNSRBL in the SMTP handler,
which will set a flag such that RCPT TO will fail except for postmaster
(RFC2821) and abuse (RFC2142).  Once a single message to has been accepted
for that connection, we might even terminate the connection.

This would not be a permanent measure, and would be replaced when we add
more flexible fast-fail, but it would provide relief today from the
spambots.

Thoughts?

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Short term, but immediate, solution to spam volume.

Posted by Hontvari Jozsef <ho...@solware.com>.

I forgot to mention: It doesn't check for abuse@, only postmaster@ and 
the email address used in the error message is hard coded.

Hontvari Jozsef wrote:

> Maybe it helps, I have attached the source which we use for about a 
> year.  I cannot create a standard patch because my last workspace is 
> based on the now non-existent cvs repository.
>
> The code must be inserted before these lines into the SMTPHandler.java 
> file:
>            if (authRequired) {
>                // Make sure the mail is being sent locally if not
>                // authenticated else reject.
>
>
> Noel J. Bergman wrote:
>
>> Do to the incredibly high volume generated by Microsoft Windows 
>> spambots, I
>> feel that we need to allow somewhat more aggressive measures in the near
>> term, as in *NOW*.
>>
>> I propose an interm measure to add support for a DNSRBL in the SMTP 
>> handler,
>> which will set a flag such that RCPT TO will fail except for postmaster
>> (RFC2821) and abuse (RFC2142).  Once a single message to has been 
>> accepted
>> for that connection, we might even terminate the connection.
>>
>> This would not be a permanent measure, and would be replaced when we add
>> more flexible fast-fail, but it would provide relief today from the
>> spambots.
>>
>> Thoughts?
>>
>>     --- Noel
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>>  
>>
>------------------------------------------------------------------------
>
>            // black list check HJ
>            // don't check if the user is authenticated or if he is sending to 
>            // postmaster
>            if (getUser() == null 
>                    && !recipientAddress.getUser()
>                            .equalsIgnoreCase("postmaster")) { 
>                String host = remoteIP;
>                //Have to reverse the octets first
>                StringBuffer sb = new StringBuffer();
>                StringTokenizer st = new StringTokenizer(host, " .", false);
>                while (st.hasMoreTokens()) {
>                    sb.insert(0, st.nextToken() + ".");
>                }
>                String reversedOctets = sb.toString();
>                
>                String blackListMessage = null;
>                try {
>                    //Try to look it up
>                    InetAddress.getByName(
>                            reversedOctets + "combined.njabl.org");
>
>                    //If we got here, that's bad... it means the host
>                    //  was found in the blacklist
>                    //blackListMessage = "Dynamic/Residential IP range listed by NJABL dynablock - http://njabl.org/dynablock.html";
>                    blackListMessage = "combined.njabl.org BLACKLIST";
>                } catch (UnknownHostException uhe) {
>                    //This is good... it's not on the list
>                }
>                if (blackListMessage != null) {
>                    responseString = "550 Rejected: contact postmaster@COMPANY.com for details";
>                    writeLoggedFlushedResponse(responseString);
>                    getLogger().error("Message rejected - " + blackListMessage);
>                    return;
>                }
>                try {
>                    //Try to look it up
>                    InetAddress.getByName(
>                            reversedOctets + "sbl-xbl.spamhaus.org");
>
>                    //If we got here, that's bad... it means the host
>                    //  was found in the blacklist
>                    blackListMessage = "Spamhaus BLACKLIST";
>                } catch (UnknownHostException uhe) {
>                    //This is good... it's not on the list
>                }
>                if (blackListMessage != null) {
>                    responseString = "550 Rejected: contact postmaster@COMPANY.com for details";
>                    writeLoggedFlushedResponse(responseString);
>                    getLogger().error("Message rejected - " + blackListMessage);
>                    return;
>                }
>            }
>
>  
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>For additional commands, e-mail: server-dev-help@james.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Short term, but immediate, solution to spam volume.

Posted by Jeff Turner <je...@apache.org>.

On Fri, Jun 03, 2005 at 09:55:08PM +0200, Stefano Bagnara wrote:
> > > I have no rights to close jira issues, you can mark as resolved the
> > > following:
> > 
> > > http://issues.apache.org/jira/browse/JAMES-380
> > > http://issues.apache.org/jira/browse/JAMES-379
> > > http://issues.apache.org/jira/browse/JAMES-377
> > > http://issues.apache.org/jira/browse/JAMES-375
> > > http://issues.apache.org/jira/browse/JAMES-374
> > > http://issues.apache.org/jira/browse/JAMES-369
> > 
> > You SHOULD be able to close the ones you open, unless we have 
> > the permissions wrong.  But there seems to be something wrong 
> > with the new JIRA update.  I cannot properly resolve or close 
> > issues, either.  I get form errors and the issues end up in 
> > inconsistent states.

I added myself to the james-developers group and successfully closed the
first issue.  There were problems with edits/updates (particularly
versions) on Friday, but I think the reindex fixed them. Please let me
know if the problems persist.

> I've got no links to close an issue.
> It seems I've no rights on JIRA, and no differences on issues reported by
> me.

In the permission scheme, only 'james-developers' group members could
resolve issues.  I added 'reporter', so you should now be able to resolve
your issues.  Noel, please change back if this was not the intention:

http://issues.apache.org/jira/secure/project/EditPermissions!default.jspa?schemeId=10180


--Jeff

> 
> Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org