On Monday 13 November 2006 23:39, Peter J. Holzer wrote: > Didn't I suggest my aliases* plugins? I must hone my marketing skills > > :-).
Uh, no, you just said that I should reject it with no such user, but not how. So yes, you really need a marketing course! *shrug* ;-) And I hate reinventing stuff, but then, it is mostly done now... But then, I feel a whitelisting plugin that works on a list of SHA1-hashed email addresses (from FOAF files) coming on, that hasn't been done, has it? > > Sweet. So small and already a plugin :-). Hehe, nice! > > 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. OK! > 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. Ah, yes! OK, so I might do that in v2, then, if needed... [snip useful example] > > 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. Ah, right. OK, that clears it up! [snip another very useful explanation] > 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. Yup, got it. > > 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. Right! Well, one of the reasons that I dumped Exim and came over here is that I'd like to write a bigger spamtrap plugin, which would go like this: RCPT TO: [EMAIL PROTECTED] which means DECLINED, of course RCPT TO: [EMAIL PROTECTED] OMG, what did I just say? Stuff the From and IP in the database, then quickly DENY_DISCONNECT, and if the spammer connects again, he will be disconnected after a database lookup, but of course a short expiry time of the data in the database. If, OTOH, the spam is _only_ sent to the spamtrap, then pipe it to sa-learn or similar. > > 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. Right, so it doesn't really matter, but then, I could implement it if I want to debug something myself or something... Cheers, Kjetil -- Kjetil Kjernsmo Programmer / Astrophysicist / Ski-orienteer / Orienteer / Mountaineer [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC
