QMail, RBL, and rejection notices.
Richard
listed in an RBL does not get delivered. The problem is that the sending
mail server keeps trying for over a week with no notification to the sender
that the mail has failed. While this may be a good thing when it is true
spam, the occasional legit email message gets hung in limbo.
I haven't found a good article or example of a working rblsmtpd server that
replies with rejection messages. Can someone point me to one?
I've been through life with Qmail and it was a good help, but I think
something else is going wrong. Have I just missed a configuration step??
-Richard
Bob Maple
> listed in an RBL does not get delivered. The problem is that the sending
> mail server keeps trying for over a week with no notification to the
sender
> that the mail has failed. While this may be a good thing when it is true
> spam, the occasional legit email message gets hung in limbo.
Try giving the "-r" flag to rblsmtpd from wherever you run it -- This will
cause the rblsmtpd to return 553 error codes (a permenant failure) instead
of the default 451 code (a temporary failure).
> I haven't found a good article or example of a working rblsmtpd server
that
> replies with rejection messages. Can someone point me to one?
rblsmtpd doesn't send rejection messages; It simply refuses to accept
messages from a host that turns up in whatever RBL databases you're using.
It's up to the remote mailer to decide whether or not to re-queue the
message and try again, or fail it completely and return a bounce to the
sender. The -r flag should make sane mailers do this.
--
| Bob Maple | bobm_at_burner_dot_com | [http] burner.com
|
| When love is gone, there's always justice. And when justice is gone,
| there's always force. And when force is gone, there's always Mom.
| Hi, Mom! -Laurie Anderson
Richard
"Bob Maple" <bob...@nospamburner.com> wrote in message
news:3cf78d33$1...@omega.dimensional.com...
> > I believe I have the rblsmtpd server partly working. Mail send from
hosts
> > listed in an RBL does not get delivered. The problem is that the
sending
> > mail server keeps trying for over a week with no notification to the
> sender
> > that the mail has failed. While this may be a good thing when it is
true
> > spam, the occasional legit email message gets hung in limbo.
>
> Try giving the "-r" flag to rblsmtpd from wherever you run it -- This will
> cause the rblsmtpd to return 553 error codes (a permenant failure) instead
> of the default 451 code (a temporary failure).
>
> > I haven't found a good article or example of a working rblsmtpd server
> that
> > replies with rejection messages. Can someone point me to one?
>
> rblsmtpd doesn't send rejection messages; It simply refuses to accept
> messages from a host that turns up in whatever RBL databases you're using.
> It's up to the remote mailer to decide whether or not to re-queue the
> message and try again, or fail it completely and return a bounce to the
> sender. The -r flag should make sane mailers do this.
>
>
rejection letter sent. Qmail just keeps trying to deliver the
messages...until some point at which I change the configuration and allow
the message through. I got a seven day old message one time. It seems to
me that it IS rblsmtpd's responsibility to tell the sending mail server to
give up!
hmm.. what about the -b option?
AK
You need to use the -b option which makes rblsmtpd generate a permanent
error 5xx versus the temporary error of 4xx when the connection is from
an rbled source.
rblsmtpd -b -r ......
AK
Bob Maple
> rejection letter sent. Qmail just keeps trying to deliver the
> messages...until some point at which I change the configuration and allow
> the message through. I got a seven day old message one time. It seems to
> me that it IS rblsmtpd's responsibility to tell the sending mail server to
> give up!
Wait a minute, maybe I misunderstand your problem.. these are *outgoing*
messages? I thought you said in your original post that you were getting
incoming messages which were being rejected by your rblsmtpd, but that the
remote servers just kept trying to deliver the messages to you over and
over.
If these are outgoing messages being rejected by remote servers because YOU
are on an RBL list and they are filtering mail based on it, well, you are at
the mercy of the remote server. If they are rejecting the messages in a non
permenant way then your Qmail will keep trying to deliver until the message
is too old (based on control/queuelifetime) at which point it would be
bounced to the sender.
> hmm.. what about the -b option?
I'm sorry, I'm retarded - I typed -r but meant -b (like you knew what I
meant :) Sorry about that.
Richard
> > But I *AM* using the -r flag....on BOTH qmail servers. Only I can't get
a
> > rejection letter sent. Qmail just keeps trying to deliver the
> > messages...until some point at which I change the configuration and
allow
> > the message through. I got a seven day old message one time. It seems
to
> > me that it IS rblsmtpd's responsibility to tell the sending mail server
to
> > give up!
>
> Wait a minute, maybe I misunderstand your problem.. these are *outgoing*
> messages? I thought you said in your original post that you were getting
> incoming messages which were being rejected by your rblsmtpd, but that the
> remote servers just kept trying to deliver the messages to you over and
> over.
Both servers were running Qmail. I incorrectly assumed that it was the
DESTINATION server that was responsible for delivering a failure message. I
now understand that it is the sending server that provides the delivery
failure message. The key here was to use the -b option on the rblsmtpd
command line.
I am now using the mail-deflector RBL ( www.maildeflector.com ) which gives
the end user the ability to add or override the main database RBL entries
using a personal database. I still don't understand how the failure error
message is created. Once I got everything configured properly and added my
server into one of my customer's private mail-deflector RBL databases I was
able to retrieve a MAILER-DAEMON response that said
[response]
1.22.333.44 does not like recipient.
Remote host said: 553 Mail refused. See
http://www.maildeflector.net/whywasirefused.php
Giving up on 1.22.333.44
[/response]
I suppose that the RBL list I used is generating the 553 error messages. I
certainly never configure a 553 error message to point to the
www.maildeflector.net/whywasirefused.php web page. I'm stumped. Maybe
it's the RBL that is supposed to generate the failure messages.
>
> If these are outgoing messages being rejected by remote servers because
YOU
> are on an RBL list and they are filtering mail based on it, well, you are
at
> the mercy of the remote server. If they are rejecting the messages in a
non
> permenant way then your Qmail will keep trying to deliver until the
message
> is too old (based on control/queuelifetime) at which point it would be
> bounced to the sender.
>
> > hmm.. what about the -b option?
>
> I'm sorry, I'm retarded - I typed -r but meant -b (like you knew what I
> meant :) Sorry about that.
>
Well something must have worked right because I went off and used the -b
options. Maybe I'm just as retarded for having the same mindset as you.
Either that or we both had lystdexia that day.
-Richard
Lystdexia *IS* the proper spelling for those who are experiencing it....
Andrew St. Jean
an example of what the rblsmtpd command line looks like if I'm passing smtp
requests to qmail-smtpd after they are filtered through the rbl? I currently am
using tcpserver to wrap qmail-smtpd. Here is what my startup script looks like
now:
tcpserver -v -p -x /etc/tcprules.d/tcp.smtp.cdb -u 401 -g 401 0 smtp
/var/qmail/bin/qmail-smtpd 2>&1 | /var/qmail/bin/splogger smtpd 3 &
TIA
Andrew
Richard
"Andrew St. Jean" <news...@arda.homeunix.net> wrote in message
news:3CFD8CF1...@arda.homeunix.net...
> I'm not currently using rblsmtpd but I would like to. Would someone please
post
> an example of what the rblsmtpd command line looks like if I'm passing
smtp
> requests to qmail-smtpd after they are filtered through the rbl? I
currently am
> using tcpserver to wrap qmail-smtpd. Here is what my startup script looks
like
> now:
>
> tcpserver -v -p -x /etc/tcprules.d/tcp.smtp.cdb -u 401 -g 401 0 smtp
> /var/qmail/bin/qmail-smtpd 2>&1 | /var/qmail/bin/splogger smtpd 3 &
>
> TIA
>
> Andrew
>
>
Ok...here is an excerpt from my /service/qmail-smtpd/run file. You will of
course have to take out the back slashes and fit this onto one line, but I
tried to make it readable.
[example]
#ordb and spamcop filter
#exec /usr/local/bin/softlimit -m 2000000 /usr/local/bin/tcpserver \
-v -R -l 0 -x /etc/mail/tcp.smtp.cdb -c "$MAXSMTPD" -u \
"$QMAILDUID" -g "$NOFILESGID" 0 smtp \
/usr/local/bin/rblsmtpd -b -r bl.spamcop.net -r relays.ordb.org \
/var/qmail/bin/qmail-smtpd 2>&1
#mail deflector filter
exec /usr/local/bin/softlimit -m 2000000 /usr/local/bin/tcpserver \
-v -R -l 0 -x /etc/mail/tcp.smtp.cdb -c "$MAXSMTPD" -u \
"$QMAILDUID" -g "$NOFILESGID" 0 smtp \
/usr/local/bin/rblsmtpd -b -r any.{yourspamdeflectorid}.spam-deflector.com
\
/var/qmail/bin/qmail-smtpd 2>&1
#no filters
[snip and end example - you have that one]
AK
I am unfamiliar with the RBL list that you are referencing, but the 553
mail Refuced. error is generated by rblsmtpd during the short smtp
session with the listed server.
The rest is the reflection of the TXT entry in DNS for the reversed ip
on the host.
let say the IP of the connecting server is 127.0.0.2 (test case on most
RBL lists.)
You use relays.ordb.org as the rblsmtpd checker.
nslookup -q=TXT 2.0.0.127.relays.oordb.org
will provide you with the "Listed by ORDB - for testing purposes only"
Do in the shell
export TCPREMOTEIP=127.0.0.2
rblsmtpd -b -r relays.ordb.org qmail-smtpd
you will see
rblsmtpd.local
helo me
2xx
mail from: me
2xx
rcpt to me:
553 Mail Refused: Listed by ORDB - for testing purposes only
AK
Bob Maple
post
> an example of what the rblsmtpd command line looks like if I'm passing
smtp
> requests to qmail-smtpd after they are filtered through the rbl? I
currently am
> using tcpserver to wrap qmail-smtpd. Here is what my startup script looks
like
> now:
>
> tcpserver -v -p -x /etc/tcprules.d/tcp.smtp.cdb -u 401 -g 401 0 smtp
> /var/qmail/bin/qmail-smtpd 2>&1 | /var/qmail/bin/splogger smtpd 3 &
Just run the rblsmtpd prior to qmail-smtpd:
tcpserver -v -p -x /etc/tcprules.d/tcp.smtp.cdb -u 401 -g 401 0 smtp \
/usr/local/bin/rblsmtpd -b -r relays.ordb.org \
/var/qmail/bin/qmail-smtpd 2>&1 | /var/qmail/bin/splogger smtpd 3 &
You can specify multiple RBLs to check, just add more "-r servername"
arguments next to each other.
Bob Maple
my
> server into one of my customer's private mail-deflector RBL databases I
was
> able to retrieve a MAILER-DAEMON response that said
>
> [response]
> 1.22.333.44 does not like recipient.
> Remote host said: 553 Mail refused. See
> http://www.maildeflector.net/whywasirefused.php
> Giving up on 1.22.333.44
> [/response]
>
> I suppose that the RBL list I used is generating the 553 error messages.
I
> certainly never configure a 553 error message to point to the
> www.maildeflector.net/whywasirefused.php web page. I'm stumped. Maybe
> it's the RBL that is supposed to generate the failure messages.
The rblsmtpd is getting that text message from the TXT record of the host
listed in the RBL. It is different for different RBLs, to help a user who
receives a rejected message figure out why their message was rejected,
usually by referring them to the website of the RBL where they can look up
their host and see why it is being blocked.
Here's what happens when your server gets a piece of mail:
1. The remote server tries to connect to port 25 on your mail server
2. tcpserver gathers some information about the remote computer like it's IP
and hostname if it can (and depending on how you have tcpserver configged)
and sets some enviornment variables.
3. tcpserver answers the connection and runs the rblsmtpd
4. The rblsmtpd takes the IP of the remote computer, reverses the octets of
the IP, and tacks on the domain of the RBL you are using. For instance, if
you run "rblsmtpd -r death.to.spam", and an incoming mail connection is from
the IP 1.2.3.4, rblsmtpd does a DNS lookup for "4.3.2.1.death.to.spam". If
the host is listed in death.to.spam's RBL, it will have an A record with an
arbitrary address (usually something in 127.0.0.*), and usually also has a
TXT record with a text description about the RBL entry.
5. rblsmtpd finds the A record for the host, and sets an internal flag that
any messages the host tries to send will be rejected.
6. The remote mail server carries on it's SMTP conversation, specifying an
envelope sender, which rblsmtpd allows. It then specifies envelope
receivers, which rblsmtpd rejects either with the 553 error code if you're
using -b (permenant error, 'mailbox not allowed') or a 451 if you're not
(temporary error, 'local processing error') and tacks on the text it got (if
any) from the TXT record after the numeric response code.
7. The sending server returns a message back to the original sender, saying
that the remote server refused the message (or re-queues the message to try
to deliver it to you again later if you're not using -b) and giving the
response that your server gave to try and help them out.
There's some other little things that happen in between but thats the
general gist of it.
Richard
> >... Once I got everything configured properly and added my
If I understand you correctly then rblsmtpd will STILL generate a 553 error
whether or not the RBL supports TXT records, . Of course without the TXT
records, there is no "see such and such web page for why you were refused."
Now, Is there anyway that *I* can modify / add to / or override the 553
error message?
>You can specify multiple RBLs to check, just add more "-r servername"
>arguments next to each other.
Yeah, I've done that. I've configured ORDB and SPAMCOP together. That
seems like a pretty good combination. But then what about the -b option?
Do I need to put a -b option in front of each '-r death.to.spam' option?
And thanks for the help, by the way.
-Richard
AK
you need only use the -b option once provided you have
rblsmtpd -b -r something -r somthingelse -r moresomethingelse as opposed
to
rblsmtpd -b -r something rblsmtpd -b -r somethingelse rblsmtpd -b -r
moresomethingelse.
If the RBL list only has A records, and if you want rblsmtpd to work
with that list, you would need to apply the ucspi patch
http://www.qmail.org/ucspi-rss.diff listed on the qmail.org's site..
AK
Bob Maple
error
> whether or not the RBL supports TXT records, . Of course without the TXT
> records, there is no "see such and such web page for why you were
refused."
Yup.
> Now, Is there anyway that *I* can modify / add to / or override the 553
> error message?
Yes and no.
1. If you set the environment variable RBLSMTPD (in the rblsmtpd's scope --
commonly from your /etc/tcp.smtp or whatever rules database you use to feed
to tcpserver, or equivilant) to a string other than an empty string, that is
the response that will be given. You can also do this to add hosts not on
the RBLs you use but that you do want to block. For instance, in my
tcp.smtp rules I have an entry:
=.goodcleanporn.com:allow,RBLSMTPD="We do not accept mail from spamming
pieces of shit."
which would block mail from "goodcleanporn.com" domains regardless if they
are in any RBL I use (and in fact, because that environment variable is set,
rblsmtpd won't even bother doing a DNS lookup if a connection comes in from
a host that matches the rule) and will give the response I set.
2. For the power user: You can run your own DNS server with an RBL zone,
and add whatever records to it you want. And/or some RBLs have public
databases whereby you can get a copy of the entire zone and load it into
your own server and make modifications as necessary.
3. Modify the source code to rblsmtpd to return a string if your choice.
This would of course be a static string, unless you wanted to go wild and
code something more complicated. You can do whatever you want :)
> Yeah, I've done that. I've configured ORDB and SPAMCOP together. That
> seems like a pretty good combination. But then what about the -b option?
> Do I need to put a -b option in front of each '-r death.to.spam' option?
No, -b is sort of a global option, you only need to specify it once.
> And thanks for the help, by the way.
No problem.