[Gllug] RBL listed hosts
Jim Bailey
jim at freesolutions.net
Thu Jun 13 04:17:22 UTC 2002
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
More information about the GLLUG
mailing list