Hi I have a little GPL project/daemon called relayd, which listens on a local UNIX socket, and using some dedicated protocol (available through a client library) gathers "action/time" informations from various relayd "agents" (or clients). The daemon can be configured with 2 configuration files, user.rules and ip.rules. The daemon is interogated by its agents/clients if a new "action" its allowed for the specified entity (user or ip). relayd has a list of actions/time period lines in its configuration files. Acording to those it can answer to the agents/clients that its ok to do the "action" or that its limit was reached and it must wait. I made this daemon so one can use it from qmail-smtpd to throttle relays in a flexible way. There is a small patch over qmail-smtpd which uses librelay.so client library and throttles "rcpt to:"s based on relayd responses (without relayd I get my qmail queue's filled up rapidly). I needed to have some "outside" qmail-smtpd solution because qmail spawns a smtpd daemon for each session and I needed to have the limits imposed for all sessions. Another solutioun whould have been to use some external (cdb?) state file from all qmail-smtpds to limit this (this would be easy to do it even now if I change the librelay.so library to use a unique cdb file to impose limits instead of talking to the realyd daemon). The only reason now that I dont use (yet) gentoo's portage qmail installation is of relayd. What whould be the chances to get relayd into portage and a new USE flag for qmail (+relayd) ? If there are chances I will take care of the ebuilds and prepare relayd for public release (its already public but I need to audit it once more and check documentation and such). Thanks!
external solutions for what you want exist already! go and look at net-mail/relay-ctrl with Gentoo's Qmail. at the very least, look at how it passes the relaying-allowed information to qmail WITHOUT any patches. You should be able to write something small for your relayd that acts just like relay-ctrl-check (configured via /var/qmail/control/conf-smtpd, QMAIL_*_PRE) Write it up to use that interface, and write similar modules for courier-imap (relay-ctrl-allow) and I'd gladly even switch to using your relayd after auditing it for myself.
Hmm sorry but I have installed and inspected relay-ctrl and it does seem to do something else. Maybe I wasnt very clear in my last post so I will try to make it clearer. relayd and qmail-relayd agent patch trys to "limit" clients relays not to "control" it. relay-ctrl seems to me to be a flexible way (indeed without any patches) to do "roaming access", to allow relaying after pop3/imap and such (beeing flexible can be used for more than that). but it has (or at least I havent noticed any) no way to limit the number of mails relayed through the system in an ammount of time (relay throttling, the purpose of relayd). relayd its used after the admin configures the "relay ACLs" (using tcp.smtp or relay after POP3/IMAP) to throttle the number of relays sent from one IP in an ammount of time (relayd accepts limits like 100 messages in 200 seconds). I use relayd as a solution for huge mail servers and ISP setups to combat spam and viruses (what it happens is that when a limit is reached qmail-smtpd starts replying with "temporary SMTP errors" saying the relay limit was reached). I patched qmail-smtpd because the relay limit is done on each "rcpt to:" command (each considered a "relay action"). Now that I have seen "relay-ctrl" I realise another solutioun (without any patching) is doing something similar to rblsmtpd, having a mini-SMTP implementation (relayd enabled) which should proxy all traffic to a qmail-smtpd. I will attach the relayd patch to qmail-smtpd here so you can take a look at it. If you still consider the "rblsmtpd" way the only way to accept relayd then Ill have to start coding such a SMTP relayd enabled proxy :) .
Created attachment 30703 [details] qmail-smtpd relayd agent patch PS: I know that "/tmp/spam.log" logging isnt very secure right now, I will change it to using syslog() if necessary.
ah, I see now. I considered limiting on connection before, and not per each RCPT. The concept of your patch there is nice, but it needs work still. The patch doesn't show me how qmail-smtpd and relayd communicate, it needs to be a lot more customiziable (without recompiling, so the email address/whole msg should be customizable, and it needs to be possible to turn it off without recompiling). if you are looking at mini-SMTP stuff, then DO look at mailfront. it's intended to make life easy for those needing an SMTP frontend.
mihai: a question for you, possibly so relay-ctrl can be altered to easily do what you want (with some integration of your relayd code). are you counting how many rcpt in each mail as the 100 messages a user is allowed, or 100 seperate messages with any # of rcpt's ?
I am counting each rcpt as a single "message" (in fact as a single "relay" because thats why I made relayd, to throttle relays). I use it to throttle and thus protect my email servers to mail bomb attacks. A MTA if it has many messages to send to me there are several posibilities: - first, a good MTA will treat right the temporary error message I give in case of relay limit reached and will try later with those rcpts (acording to the SMTP RFC I can give OK to some RCPT and errors to others and MTAs should treat those nicely; I have used relayd in production for 2 years I didnt got any complains about that) - second, if you know there is some server sending you a lot of email you can give that server a special limit in the relayd configuration files (a higher limit)
Mihai: two requests for you, before this goes into the tree. 1. enable/disable at runtime instead of compiling with -DRELAY 2. for logging, use enew/eout/eflush like the rest of the qmail error messages. (You can filter it to a file later using multilog). 3. Your patch references a relay.h in the current directory, but you haven't included it at all. Could you please do so, so that I can see how you tell qmail which relayd to contact.
Thanks for your interest :) 1. I would also live there -DRELAY if that is not a problem for you; I was thinking adding a check for a enviroment variable; RELAY_LIMIT ? whould that be ok ? 2. oh, didnt knew anything about enew/eout/eflush, gonna dig into that 3. the interface (relay.h) comes with the relayd package (which also builds the actual library, librelay.so); so compiling qmail with relayd support will require first to install relayd; to answer your question, there is no way (currently) to specify where to connect; there is a #define which hardcodes the library to try to connect to /tmp/relayd.sock when relayd_open() is called; if you want that changed or have a sugestion about it please say
1. whatever name you feel is appropriate. 'USE_RELAYD' might be a good choice. 2. Your patch referenced relay.h as '#include "relay.h"' so I was wondering about it. If it's going to be on the system, reference it as '#include <relay.h>' 3. The location of the socket must be configurable at runtime. what happens in your system if the relayd server can't be contacted? graceful fallover should be found, like sending 4xx temporary errors.
Currently the (hardcoded) decision when connection to relayd fails is to not do relay checking at all (ie allow everything to pass without checking). It was probably best suited for my own needs. I can see why for an antivirus this hardcoded decision might be bad (I can see why getting virused mails might be worse then delaying all mails) but for relayd I thought not doing throttling while there are relayd problems is ok. However, if you have a sugestion on this please say. For the socket path I will modify relayd_open() call to accept a const char * as the path. Then I will change the qmail relayd patch to lookup for a RELAYD_SOCKET var and if not found use the default RELAYD_DEFAULT_SOCKET value as imported from relayd.h.
perhaps have a variable that controls if mails should be allowed or should give temporary errors? RELAYD_FAILMODE=allow/RELAYD_FAILMODE=tempfail using a RELAYD_SOCKET variable would be great for configuration.
hey Mihai. Check out qmail-spp. We're trying to get it in for qmail -r16 and it should be very easy for you to do RCPT counting within that framework.
Hello Robin. Looks very interesting, probably it will make as plugins a lot of qmail-smtpd patches. Unfortunetly I do not see how can I know when the session ends and/or when is resetted (RSET). I need to know this because there are (broken?) mail clients (actually a lot of them like Outlook Express) which try to send to all the recipients using a rcpt to for every recipient (nothing wrong here) but if they start getting rejects after some recipients (the SMTP RFC does not say anything about this case) they reject the whole sending (they close the SMTP connection before DATA) and next time when they try, they try again with all the destinations again (but this time relayd has already counted the rcpt to's that it considered successfull although to DATA was issued so no actual message was sent). This does not allow the sender that it sees the sending has failed to try to send to fewer people first until it sees the sending succeded then try the next people and so on (or try a SMTP server which enqueues deliveries and is smart enough to know which rcpt's succeded and which not). I have solved this by doing a "transaction"-like aproach for relayd and the qmail-smtpd relayd agent patch. It works like this: since the smtp session starts for every rctp to relayd counts them and checks against limit. When the limit is reached as usual it starts to reject the rcpts. If the session is closed WITHOUT a successfull "DATA" command (so without sending the message to the accepted rcpts) then all the "counted" rcpt's so far for this session are "rollbacked" (actually they are commited only when a successfull DATA command finishes). Also I need to be able to rollback also when a "RSET" is issued. So to make it short, I should be able to use qmail-spp if they provide "hooks" for the following "events": - successfull DATA command finished (not like they do now when the DATA command is issued, I need to know if it also finished well, if connection was not prematurely terminated because in such a case the message is totally discarded by qmail-smtpd so I too need to rollback the counted rcpts for this session) - RSET command issued - closing of session Besides all this I would also need for qmail-spp to uniquely identify every SMTP session (with some string ID) and communicate this to the plugins for every hook call.
I don't see it as difficult to add hooks for 'DATA successful'/RSET/session-close. I'll take a look at doing that once we have r16 in, as I have some grand plans for qmail-spp as well (I want to track in realtime the sources that are trying lots of non-existant addresses, and have a rolling firewall against them).
just a note on this, for the qmail team. this is on the list for things AFTER -r16 is released to ~arch.
was wondering if there's any progress getting relayd into qmail as it is required by an interesting set of plugins (ra-plugins) from http://cablemodem.fibertel.com.ar/lateral/stories/39.html also referenced at http://qmail-spp.sourceforge.net/plugins/details/?id=22
We won't add custom patches to mail-mta/netqmail. mail-mta/qmail is not updated anymore and will be removed as soon as possible.
(In reply to comment #17) > We won't add custom patches to mail-mta/netqmail. mail-mta/qmail is not updated > anymore and will be removed as soon as possible. Thank you for letting me know that netqmail will take over "qmail". I entered a new bug report for ra-plugins at http://bugs.gentoo.org/show_bug.cgi?id=159840 Although I tested it with "qmail" it should also work with netqmail.
