On Mon, 31 Mar 2003 10:04 pm, Peter Gordon wrote: > I have a number of issues with qpsmtpd as it stands at the > moment. Maybe you could comment on my problems. > > 1. Plugins should be easy to debug from a test harness. > Is there a way to do this? You can run the perl debugger, but once > you start debugging the eval'ed code, perl just says that it won't > show you the code. (I am using perl 5.008). So I am looking for a > way to see what is happening in the plugins.
I just put in lots of $self->log(...) entries. > 2. Some email users will want to receive all email. So a white list > would be needed for RCPT. The problem is that this comes after mail > has been rejected by the mail hook. White lists are also needed for > senders. You just need to modify any mail hook plugins so that the rejection occurs at the rcpt hook stage. I think most of the plugins do this already. For example, 'check_badmailfrom' certainly does, and so does 'dnsbl'. Have a quick check through any plugin you are using and see where the DENY occurs, and modify if necessary. Implementing a 'white list' plugin (pretty much as you describe) is on my todo list. You are welcome to beat me to it. You just need to have the 'whtelist' plugin before any 'ordinary' plugins, and it will need to return OK at least the rcpt hook (assuming that all other plugins only return DENY at the rcpt hook stage, which is generally good practice anyway). > 3. Why does check_relay have to be last? Since once a plugin returns OK for a given hook type, no further plugins of that hook type are run. If check_relay was run first (for example) then since it only DENY's relay attempts, and returns OK for everything else, qpsmtpd would allow (almost) all mail through. > 4. When I have tried using qpsmtpd in the past, users get error messages, > and it is not at all obvious which plugin rejected the email. Not quite sure what you are after here. Do you want the bounce message that qpsmtpd gives to be more explicit (ie, the sender gets more info from the bounce) or do you want a better logging facility. If you want the former, you could patch either the plugins, or qpsmtpd proper. If the latter, there is a 'deny' hook, which can be used for logging purposes. See http://www.openminddev.net/twiki/bin/view/Main/QpsmtpdPlugins for an example application. I am currently in the process of writing a plugin that will do full address expansion (ie, parse .qmail files, deal with users/assign etc) so that all addresses are expanded to at least the user level. It is turning out to be a bit harder than I expected, but once done it will allow full user-level logging of all messages both received and rejected. > 5. When a mail cannot be delivered it sometimes takes the (legitimate) > sender 5 days to receive the rejection. In business this is very hard > to justify. Is it possible to ensure that the user receives the > rejection immediately? See below, on the difference between DENYSOFT and DENY. If a plugin returns DENY, qpsmtpd should be returning a 'permanent' error code (generally 55x) and the senders mailserver should send a bounce message immediately. However, if a plugin returns DENYSOFT, qpsmptd returns a 'temporary' error code. In this case, the senders mailserver will usually keep trying to send the message for a defined amount of time, before finially giving up and then sending a bounce message to the sender. The problem is that the amount of time the mailserver keeps trying for (in the case of a DENYSOFT) is configured at the senders end, and can be several days. To change this setting in qmail for example, you do # echo "<seconds>" > /var/qmail/control/queuelifetime where <seconds> is the number of seconds you want qmail to keep trying to deliver a message before it gives up and sends a bounce message. I'm not sure if you need to restart qmail to get it to act on the changed config. By default, qmail has a queuelifetime of 7 days, which in my view is *way* too long. Particuarly in business, if the message cannot be delivered within a few hours, the sender probably needs to know. The only plugin that I can see that returns DENYSOFT is the 'require_resolvable_fromhost' plugin. The problem here is that you don't know whether you are getting a failed query because there is no MX or A record for that domain, or is there just a DNS error somewhere. However, since if there is no MX or A record for the domain, no-one can send mail to it anyway (including a bounce message) I think a DENYSOFT is appropriate, although some kind of caching mechanism that returns a DENY after 'n' hours of failed lookups for a particular domain would help reduce the number of connection attempts. > > 6. What is the difference between DENYSOFT and DENY? Type type of error code returned by qpsmtpd. DENY gives a 'permanent' error code (generally 55x) whereas DENYSOFT gives a 'temporary' error code (generally 45x from memory). If the senders mail-server does not promptly give a bounce upon a 55x error code, then there is a problem with it, not qpsmtpd. I hope this helps. Rasjid.
