On 2006-11-13 21:34:06 +0100, Kjetil Kjernsmo wrote: > So, I have just created what might be my first qpsmtpd plugin! > > I decided to hand-maintain a list of valid addresses on my system, since > it was too complex to automate with mailman-run mailing lists on > virtual domains. And, given my double bounce spam problem, I need to be > able to identify valid recipients at RCTP TO time. > > So, not finding one that could do that, I decided to try create my own.
Didn't I suggest my aliases* plugins? I must hone my marketing skills :-). > It should be a good way to start creating qpsmtpd plugins anyway. > Problem is, I don't have a suitable test system right now, as I just > had a hardware failure... :-( Therefore, I hope you good folks could > poke at it with a critical eye and see if it is likely to do as > intended: > > Just checked it in: > http://svn.kjernsmo.net/qpsmtpd-check-rcptlist/trunk/check_rcptlist > > The only code looks like this: > > sub hook_rcpt { > my ($self, $transaction, $recipient) = @_; > foreach my $ok ($self->qp->config('validaddresses')) { > return OK if ($recipient->user eq $ok); # That's a valid address > } > return DENY; # Then it doesn't exist > } Sweet. So small and already a plugin :-). > Sane? For one thing, is a for-loop OK here, or are there more efficient > ways to do it? For small lists (a few hundred addresses) the for loop is probably the at least as fast as any other method. The biggest overhead is probably opening the file. You can reduce that to almost zero (with forkserver or Apache) if you read the the list only when it changes instead of for every recipient. See my aliases_check plugin <http://svn.perl.org/viewcvs/qpsmtpd/contrib/hjp/aliases/aliases_check?view=markup> for an example on how to use the pre_connection hook to reload the config only if needed. (I have a few thousand addresses, so this is worthwhile - I may switch to LDAP or an RDBMS at some point, but until now I find reading a simple text file only when it changes more convenient) > Then, I'm in a slight doubt as to the semantics of OK and DENY in this > context: OK does only mean that the address is OK, not that it will > pass unhindered through my other filters? OK means that that the RCPT command is completed successfully. Any later hooks will be skipped. To run the address through other filters you have to return DECLINED. Basically there are two ways to build access controls: Deny everything which isn't explicitely accepted, and Accept everything which isn't explicitely denied. I found that the latter approach works better with qpsmtpd plugins, as they usually check for a specific reason to deny the mail. So my plugins file looks like this: aliases_check # equivalent to your check-rcptlist: # Returns DENY if rcpt doesn't exist, else DECLINED redirect # Returns DENY if address has changed, else DECLINED denysoft_greylist # Returns DENYSOFT if not whitelisted, else DECLINED smtp_callback # Returns DENY if sender doesn't exist else DECLINED ... rcpt_accept # always returns OK So you see the pattern: All plugins return DENY if they see a reason to reject the mail, but decline judgement otherwise. If no plugin found a reason to reject the message, it is accepted. > And does DENY mean that "this address was incorrect, but you may try > another" Yes. > and DENY_DISCONNECT would tell the client to go away? Not quite. It tells the client "this address was incorrect, but you may try another" and then immediately closes the connection. This is not very useful if the client is a legitimate MTA: If this was the last address, it would have disconnected anyway, and if there is another address, if will reconnect after some delay. It is sometimes useful if you suspect that the client is a spammer or worm. > If this looks sane, it would be pretty trivial to implement VRFY the > same way, but is that sane to do nowadays, or will it just mean less > work for spammers? Anybody can get the same information with RCPT that they could get with VRFY. There just isn't any difference if VRFY is implemented sanely. I think that the vilification of VRFY in the 1990's was ill-conceived. However, today VRFY is useless: Almost no SMTP-Server implements it correctly, and almost no software (legitimate or otherwise) tries to use it (my smtp_callback plugin mentioned above tries to use VRFY and falls back to RCPT - last time I looked at the stats, all useful results came from RCPT). I think it could be useful to implement and use VRFY so you can distinguish between verification requests (SMTP callouts/callbacks) and actual delivery attempts, but nobody seems to do that these days. hp -- _ | Peter J. Holzer | Schlagfertigkeit ist das, was einem |_|_) | Sysadmin WSR | auf dem Nachhauseweg einfällt. | | | [EMAIL PROTECTED] | -- Lars 'Cebewee' Noschinski in dasr. __/ | http://www.hjp.at/ |
signature.asc
Description: Digital signature
