[Gllug] RBL listed hosts

[Jim Bailey]

On Wed, Jun 12, 2002 at 05:37:57PM +0100, Mark Lowes wrote:
> On Wed, 2002-06-12 at 17:13, Rev Simon Rumble wrote:
> > On Wed 12 Jun, Xander D Harkness made the following spurious claims:
> > > Do the large companies with RBL listed hosts ever get round to fixing 
> > > them?  This is something that I have not been aware of; however I am 
> > > sure with a few more servers on reject rather than warn they might be 
> > > convinced :-)
> > The whole idea of these lists is to provide encouragement for dodgy
> > hosts to clean up their act.  The GOOD lists make every effort (yes,
> > even snail mail and <gasp> the phone) to contact someone who can fix
> > the problem before listing them.  Then they list them so their users
> > scream that mail is being lost.
> 
> Though the only list I know of which does that is the MAPS RBL,
> certainly the likes of bl.spamcop and ordb don't warn before listing.
> 
> [...]
> > The biggest problem is that the bounce messages people receive at most
> > have a line saying "Rejected due to message content."  While the idea
> > of actually allowing delivery of the email might seem a bad idea,
> > accepting the message and then constructing a helpful error message
> > would make these blacklists a LOT more effective.
>
> Though one of the problems there is you let the spam into the server and
> generally spam is unbouncable because the address is either bogus or a
> hijacked domain (and therefore bouncing back to the domain owner is just
> continuing the abuse).  Many server admins would prefer to reject at
> smtp time to lower the load on their boxes and keep the queues clean.
>
Please forgive me if I am in my usual way totally ignorant of the real
situation but it maybe or should be possible to to construct a helpful
message, while simply filtering mail based purely on its header
information.

RFC2821 seem to offer a way of sending clearer messages to users without
accepting suspect mail.

4.2 SMTP Replies

   Replies to SMTP commands serve to ensure the synchronization of
   requests and actions in the process of mail transfer and to guarantee
   that the SMTP client always knows the state of the SMTP server.
   Every command MUST generate exactly one reply.

   The details of the command-reply sequence are described in section
   4.3.

   An SMTP reply consists of a three digit number (transmitted as three
   numeric characters) followed by some text unless specified otherwise
   in this document.  The number is for use by automata to determine
   what state to enter next; the text is for the human user.  The three
   digits contain enough encoded information that the SMTP client need
   not examine the text and may either discard it or pass it on to the
   user, as appropriate.  Exceptions are as noted elsewhere in this
   document.  In particular, the 220, 221, 251, 421, and 551 reply codes
   are associated with message text that must be parsed and interpreted
   by machines.  In the general case, the text may be receiver dependent
   and context dependent, so there are likely to be varying texts for
   each reply code.  A discussion of the theory of reply codes is given
   in section 4.2.1.  Formally, a reply is defined to be the sequence: a
   three-digit code, <SP>, one line of text, and <CRLF>, or a multiline
   reply (as defined in section 4.2.1).  Since, in violation of this
   specification, the text is sometimes not sent, clients which do not
   receive it SHOULD be prepared to process the code alone (with or
   without a trailing space character).  Only the EHLO, EXPN, and HELP
   commands are expected to result in multiline replies in normal
   circumstances, however, multiline replies are allowed for any
   command.

   I am not sure how you change these texts whether there is a option in
   the config files or whether you need to do something with source code,
   (beyond my abilities).

   I am trying to figure it out though as I am using some hacks off the
   Postfix users list to perform UCE filtering on mails with hotmail and
   yahoo addresses and the stock 451 response it gives doesn't make an
   lot of sense in the context they are being used in.

   I hope I am not too far wrong with this stuff.

   Peace Jim

   "Sure it is going to kill a lot of people, but they may be dying of
   something else anyway."
   --Othal Brand, member of Texas Pesticide Review Board on chlordane

   

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug