Re: check_badrcptto, to prevent backscatter
Isn't back scatter exactly the intent of the spammer? Send the spam to invalid addresses with a forged return which is where the reject goes. But you could be right: back scatter may be so specific that these two scripts would be the only ones ever to go into the folder. Addresses or addressees or even rcptto. -- Sent from my Android. Robert Spier rsp...@pobox.com wrote: One solution would be to add a new directory named 'backscatter' and put both scripts in there with the same prefix (check_goodrcptto) and with a distinguishing suffix (_postfix _qmail). That would be clear to people that are interested in the subject. Yes. Except backscatter isn't quite the right kind of descriptive name. Maybe recipients? addresses? -R
Re: check_badrcptto, to prevent backscatter
On 3/12/2011 3:19 AM, Todd wrote: Isn't back scatter exactly the intent of the spammer? Send the spam to invalid addresses with a forged return which is where the reject goes. The reality is that spammers use forged sender addresses so their own accounts don't get nuked. Relying on backscatter to get their message through to _somebody_ is rather pointless, because they've also spammed that address directly, and that most mailer bounces aren't very conducive to getting their message through, and most MTAs won't bounce in the first place. [This may not be obvious _enough_ to those who love qmail ;-)] It's a side-effect of forging, not a deliberate goal in itself. But you could be right: back scatter may be so specific that these two scripts would be the only ones ever to go into the folder. Addresses or addressees or even rcptto. It's a much bigger issue than just backscatter. This is the proper place to do anything you'd want to at rcpt-to time. Checking for existence, obviously. But also aliasing, tagged addresses, checking for permissible relaying, etc. The idea is to have a single plugin that knows _how_ to do those things, with plugins that it in turn uses to find out the information it needs.
Re: check_badrcptto, to prevent backscatter
On Friday 11 March 2011 03:41:03 Chris Lewis wrote: I think we'd be better served by coming up with, for example, a qpsmtpd way of doing this sort of thing. For example: for basic RCPT TO functionality, have a basic RCPT time plugin that can handle aliasing, allowable domain relays, lists of valid addresses, tagged addresses etc. Base the plugin around being able to read a qpsmtpd format file specifying all that stuff. Something like check_rcpts qmail:[qmail specific config specifier] postfix:[postifx config] and the check_rcpts plugin looks for check_rcpts_[system] and calls it (or putting those options into the check_rcpts file itself) Sort of a plugins for plugins idiom... so if you do have a system whereby some users are delivered to qmail and others to postfix then you use both, but most people will just use one or another. Could do the same for delivery systems I expect Then, have a series of different front-ends for that plugin that can translate configuration files from other mail platforms into whatever idiom the RCPT TO plugin understands. I don't think you could feasibly make all such sub-plugins just be config file readers as they may have to stay involved. With qmail I can set up aliases so that wildcard matching rules will then consult further files based on the name match - with a file system I could probably walk the entire folders at startup and read all such possible entries, but other systems might not allow such enumeration. You can even make the front-ends plugins of a sort to the hook_rcpt plugin. Including being able to slip out of the config file paradigm into, say, custom LDAP/DBMS interfacing for parts of it. I think you're saying the same here... sometimes the sub-plugin will want to defer some of its logic to a later stage. I think much is to be gained by putting all this MTA functionality (how you actually _apply_ an alias, handle tagged addresses, etc etc etc) into _one_ plugin, rather than having to replicate ALL of it into different plugins written by different people with different skill/bug levels that in the end only differ as to config file format. If someone comes up with such a system, I'd be more than happy to convert what I've written, but I don't think I've got enough domain knowledge to design it to cover all the options people might want (routing/ordering of checks, interactions of decline/deny semantics between sub-plugins), and I'd hate to leave glaring gaps thru poor choice of design(er). Cheers -- Tim
Re: check_badrcptto, to prevent backscatter
On 3/10/2011 11:27 PM, Robert Spier wrote: Tim Meadowcroft wrote: On Thursday 10 March 2011 18:06:04 Robert Spier wrote: Ask Bjørn Hansen wrote: On Mar 10, 2011, at 6:49, Matt Sergeant wrote: Should we have plugins/qmail and plugins/postfix dirs? I like that idea. I'm not sure I do. The existing directories don't really line up that way, and I don't think we're going to have a huge number of postfix/qmail split plugins. So I see this more as a suffix. I wouldn't mind moving these into some sort of directory (maybe rcpt?) but moving plugins is hard, because everyone needs to update their config/plugins file. Are you just talking about the plugins config file understanding names as paths rather than as simply filenames (and presumably config files mirroring the same structure) - I would see this as a good thing (I can put my specific plugins into local/ or similar, and symlinks can be used if I want to be fancy) ? I presume you could leave all existing plugins in the root but suggest migrating them over time... No. The plugins config already understands directories just fine. And recent versions of qpsmtpd support a config file to set the plugin roots: qpsmtpd]$ cat config/plugin_dirs /home/smtp/qpsmtpd/plugins.site /home/smtp/qpsmtpd/plugins I was disagreeing with the proposed taxonomy of having a qmail and postfix directory, as it doesn't really fit with what we have right now: plugins]$ find . -type d . ./async ./async/queue ./virus ./queue ./logging ./auth ./ident -R One solution would be to add a new directory named 'backscatter' and put both scripts in there with the same prefix (check_goodrcptto) and with a distinguishing suffix (_postfix _qmail). That would be clear to people that are interested in the subject. Todd
Re: check_badrcptto, to prevent backscatter
One solution would be to add a new directory named 'backscatter' and put both scripts in there with the same prefix (check_goodrcptto) and with a distinguishing suffix (_postfix _qmail). That would be clear to people that are interested in the subject. Yes. Except backscatter isn't quite the right kind of descriptive name. Maybe recipients? addresses? -R
Re: check_badrcptto, to prevent backscatter
On Mar 10, 2011, at 19:41, Chris Lewis wrote: I think we'd be better served by coming up with, for example, a qpsmtpd way of doing this sort of thing. For example: for basic RCPT TO functionality, have a basic RCPT time plugin that can handle aliasing, allowable domain relays, lists of valid addresses, tagged addresses etc. Base the plugin around being able to read a qpsmtpd format file specifying all that stuff. [...] Aha, you are right! In the 'STATUS' file there's actually a TODO item for doing this. - Add user configuration plugin infrastructure - Add plugin API for checking if a local email address is valid The idea here was to allow one or more plugins to lookup user information (in LDAP, aliases.db, users.cdb, PAM, ...) and then a standard API for accessing the information. A not found user should by default just have the recipient be rejected. Of course I added this to the TODO in 2004 or something like that ... - ask
Re: check_badrcptto, to prevent backscatter
Should we have plugins/qmail and plugins/postfix dirs? Todd Brunhoff wrote: Tim's view seems appropriate. His script is centered on qmail, and mine is centered on postfix (or more specifically, on /etc/aliases). Both scripts are probably best in their current form with appropriate disclosures. Let me know if there is any prep work you would like me to do to my script. Todd On 3/9/2011 7:23 AM, Tim Meadowcroft wrote: On Sunday 06 March 2011 06:42:50 Robert Spier wrote: Todd Brunhoff wrote: Your scripts look like they have a good deal of qmail sophistication. Some years ago I ran qmail 1.0.3, after each major system crash, I would revisit whether to use qmail, and eventually decided to switch to qpsmtp+postfix because both seem to have better support. And in fact, the reason I included /etc/alias was to replace the very useful alias mechanism in qmail. I really didn't need much, so that was sufficient for me. So it seems that among these collections of scripts there are backscatter solutions for qmail sites and qpsmtp sites. Perhaps one of the developers can fold these into a contrib folder? A lot of plugins are linked from the wiki, http://wiki.qpsmtpd.org. check_goodrcptto looks like something that might be worth having in core. Tim and Todd, are you interested in reconciling the differences between your versions? (Maybe some sort of configuration interface?) Mine is very qmail specific - I sort of feel generalising it would make it worse. Either you use qmail, in which case you might like it as it stands, (possibly in addition to other recipient checks) or you don't use qmail, in which case you can ignore it completely. I've posted the source (with disclaimers - I'm still on qpsmtpd v0.28) at http://schmerg.com/checkgoodrcptto-a-qpsmtpd-plugin-for-checking and will see about adding it to the wiki when I can set up an account there. Cheers -- Tim
Re: check_badrcptto, to prevent backscatter
Works 4 me. -- Sent from my Android. Matt Sergeant m...@sergeant.org wrote: Should we have plugins/qmail and plugins/postfix dirs? Todd Brunhoff wrote: Tim's view seems appropriate. His script is centered on qmail, and mine is centered on postfix (or more specifically, on /etc/aliases). Both scripts are probably best in their current form with appropriate disclosures. Let me know if there is any prep work you would like me to do to my script. Todd On 3/9/2011 7:23 AM, Tim Meadowcroft wrote: On Sunday 06 March 2011 06:42:50 Robert Spier wrote: Todd Brunhoff wrote: Your scripts look like they have a good deal of qmail sophistication. Some years ago I ran qmail 1.0.3, after each major system crash, I would revisit whether to use qmail, and eventually decided to switch to qpsmtp+postfix because both seem to have better support. And in fact, the reason I included /etc/alias was to replace the very useful alias mechanism in qmail. I really didn't need much, so that was sufficient for me. So it seems that among these collections of scripts there are backscatter solutions for qmail sites and qpsmtp sites. Perhaps one of the developers can fold these into a contrib folder? A lot of plugins are linked from the wiki, http://wiki.qpsmtpd.org. check_goodrcptto looks like something that might be worth having in core. Tim and Todd, are you interested in reconciling the differences between your versions? (Maybe some sort of configuration interface?) Mine is very qmail specific - I sort of feel generalising it would make it worse. Either you use qmail, in which case you might like it as it stands, (possibly in addition to other recipient checks) or you don't use qmail, in which case you can ignore it completely. I've posted the source (with disclaimers - I'm still on qpsmtpd v0.28) at http://schmerg.com/checkgoodrcptto-a-qpsmtpd-plugin-for-checking and will see about adding it to the wiki when I can set up an account there. Cheers -- Tim
Re: check_badrcptto, to prevent backscatter
On Mar 10, 2011, at 6:49, Matt Sergeant wrote: Should we have plugins/qmail and plugins/postfix dirs? I like that idea. - ask
Re: check_badrcptto, to prevent backscatter
Ask Bjørn Hansen wrote: On Mar 10, 2011, at 6:49, Matt Sergeant wrote: Should we have plugins/qmail and plugins/postfix dirs? I like that idea. I'm not sure I do. The existing directories don't really line up that way, and I don't think we're going to have a huge number of postfix/qmail split plugins. So I see this more as a suffix. I wouldn't mind moving these into some sort of directory (maybe rcpt?) but moving plugins is hard, because everyone needs to update their config/plugins file. -R
Re: check_badrcptto, to prevent backscatter
On Thursday 10 March 2011 18:06:04 Robert Spier wrote: Ask Bjørn Hansen wrote: On Mar 10, 2011, at 6:49, Matt Sergeant wrote: Should we have plugins/qmail and plugins/postfix dirs? I like that idea. I'm not sure I do. The existing directories don't really line up that way, and I don't think we're going to have a huge number of postfix/qmail split plugins. So I see this more as a suffix. I wouldn't mind moving these into some sort of directory (maybe rcpt?) but moving plugins is hard, because everyone needs to update their config/plugins file. Are you just talking about the plugins config file understanding names as paths rather than as simply filenames (and presumably config files mirroring the same structure) - I would see this as a good thing (I can put my specific plugins into local/ or similar, and symlinks can be used if I want to be fancy) ? I presume you could leave all existing plugins in the root but suggest migrating them over time... Or does this as a change go deeper than that (I've always disliked that the config file of plugins is itself mixed in the same folder with all the plugin configs, but figured I was just being picky) ? I'm a long way out of date with current developments, sorry, you shouldn't have all made the early versions so .. erm... functional and complete :) -- T
Re: check_badrcptto, to prevent backscatter
On 3/10/2011 12:43 PM, Ask Bjørn Hansen wrote: On Mar 10, 2011, at 6:49, Matt Sergeant wrote: Should we have plugins/qmail and plugins/postfix dirs? I like that idea. I think we'd be better served by coming up with, for example, a qpsmtpd way of doing this sort of thing. For example: for basic RCPT TO functionality, have a basic RCPT time plugin that can handle aliasing, allowable domain relays, lists of valid addresses, tagged addresses etc. Base the plugin around being able to read a qpsmtpd format file specifying all that stuff. Then, have a series of different front-ends for that plugin that can translate configuration files from other mail platforms into whatever idiom the RCPT TO plugin understands. You can even make the front-ends plugins of a sort to the hook_rcpt plugin. Including being able to slip out of the config file paradigm into, say, custom LDAP/DBMS interfacing for parts of it. I think much is to be gained by putting all this MTA functionality (how you actually _apply_ an alias, handle tagged addresses, etc etc etc) into _one_ plugin, rather than having to replicate ALL of it into different plugins written by different people with different skill/bug levels that in the end only differ as to config file format.
Re: check_badrcptto, to prevent backscatter
Tim Meadowcroft wrote: On Thursday 10 March 2011 18:06:04 Robert Spier wrote: Ask Bjørn Hansen wrote: On Mar 10, 2011, at 6:49, Matt Sergeant wrote: Should we have plugins/qmail and plugins/postfix dirs? I like that idea. I'm not sure I do. The existing directories don't really line up that way, and I don't think we're going to have a huge number of postfix/qmail split plugins. So I see this more as a suffix. I wouldn't mind moving these into some sort of directory (maybe rcpt?) but moving plugins is hard, because everyone needs to update their config/plugins file. Are you just talking about the plugins config file understanding names as paths rather than as simply filenames (and presumably config files mirroring the same structure) - I would see this as a good thing (I can put my specific plugins into local/ or similar, and symlinks can be used if I want to be fancy) ? I presume you could leave all existing plugins in the root but suggest migrating them over time... No. The plugins config already understands directories just fine. And recent versions of qpsmtpd support a config file to set the plugin roots: qpsmtpd]$ cat config/plugin_dirs /home/smtp/qpsmtpd/plugins.site /home/smtp/qpsmtpd/plugins I was disagreeing with the proposed taxonomy of having a qmail and postfix directory, as it doesn't really fit with what we have right now: plugins]$ find . -type d . ./async ./async/queue ./virus ./queue ./logging ./auth ./ident -R
Re: check_badrcptto, to prevent backscatter
On Sunday 06 March 2011 06:42:50 Robert Spier wrote: Todd Brunhoff wrote: Your scripts look like they have a good deal of qmail sophistication. Some years ago I ran qmail 1.0.3, after each major system crash, I would revisit whether to use qmail, and eventually decided to switch to qpsmtp+postfix because both seem to have better support. And in fact, the reason I included /etc/alias was to replace the very useful alias mechanism in qmail. I really didn't need much, so that was sufficient for me. So it seems that among these collections of scripts there are backscatter solutions for qmail sites and qpsmtp sites. Perhaps one of the developers can fold these into a contrib folder? A lot of plugins are linked from the wiki, http://wiki.qpsmtpd.org. check_goodrcptto looks like something that might be worth having in core. Tim and Todd, are you interested in reconciling the differences between your versions? (Maybe some sort of configuration interface?) Mine is very qmail specific - I sort of feel generalising it would make it worse. Either you use qmail, in which case you might like it as it stands, (possibly in addition to other recipient checks) or you don't use qmail, in which case you can ignore it completely. I've posted the source (with disclaimers - I'm still on qpsmtpd v0.28) at http://schmerg.com/checkgoodrcptto-a-qpsmtpd-plugin-for-checking and will see about adding it to the wiki when I can set up an account there. Cheers -- Tim
Re: check_badrcptto, to prevent backscatter
Tim's view seems appropriate. His script is centered on qmail, and mine is centered on postfix (or more specifically, on /etc/aliases). Both scripts are probably best in their current form with appropriate disclosures. Let me know if there is any prep work you would like me to do to my script. Todd On 3/9/2011 7:23 AM, Tim Meadowcroft wrote: On Sunday 06 March 2011 06:42:50 Robert Spier wrote: Todd Brunhoff wrote: Your scripts look like they have a good deal of qmail sophistication. Some years ago I ran qmail 1.0.3, after each major system crash, I would revisit whether to use qmail, and eventually decided to switch to qpsmtp+postfix because both seem to have better support. And in fact, the reason I included /etc/alias was to replace the very useful alias mechanism in qmail. I really didn't need much, so that was sufficient for me. So it seems that among these collections of scripts there are backscatter solutions for qmail sites and qpsmtp sites. Perhaps one of the developers can fold these into a contrib folder? A lot of plugins are linked from the wiki, http://wiki.qpsmtpd.org. check_goodrcptto looks like something that might be worth having in core. Tim and Todd, are you interested in reconciling the differences between your versions? (Maybe some sort of configuration interface?) Mine is very qmail specific - I sort of feel generalising it would make it worse. Either you use qmail, in which case you might like it as it stands, (possibly in addition to other recipient checks) or you don't use qmail, in which case you can ignore it completely. I've posted the source (with disclaimers - I'm still on qpsmtpd v0.28) at http://schmerg.com/checkgoodrcptto-a-qpsmtpd-plugin-for-checking and will see about adding it to the wiki when I can set up an account there. Cheers -- Tim
Re: check_badrcptto, to prevent backscatter
Todd Brunhoff wrote: Your scripts look like they have a good deal of qmail sophistication. Some years ago I ran qmail 1.0.3, after each major system crash, I would revisit whether to use qmail, and eventually decided to switch to qpsmtp+postfix because both seem to have better support. And in fact, the reason I included /etc/alias was to replace the very useful alias mechanism in qmail. I really didn't need much, so that was sufficient for me. So it seems that among these collections of scripts there are backscatter solutions for qmail sites and qpsmtp sites. Perhaps one of the developers can fold these into a contrib folder? A lot of plugins are linked from the wiki, http://wiki.qpsmtpd.org. check_goodrcptto looks like something that might be worth having in core. Tim and Todd, are you interested in reconciling the differences between your versions? (Maybe some sort of configuration interface?) -R
Re: check_badrcptto, to prevent backscatter
Your scripts look like they have a good deal of qmail sophistication. Some years ago I ran qmail 1.0.3, after each major system crash, I would revisit whether to use qmail, and eventually decided to switch to qpsmtp+postfix because both seem to have better support. And in fact, the reason I included /etc/alias was to replace the very useful alias mechanism in qmail. I really didn't need much, so that was sufficient for me. So it seems that among these collections of scripts there are backscatter solutions for qmail sites and qpsmtp sites. Perhaps one of the developers can fold these into a contrib folder? Todd On 2/5/2011 6:23 AM, Tim Meadowcroft wrote: On Saturday 05 February 2011 08:38:12 Todd Brunhoff wrote: I have a small email server that is just for my wife and I. The biggest problem I have is backscatter (mail received with invalid local address that bounces to an invalid sender address). So the following script blocks all of this at the point of receipt, inside qpsmtpd. Could not find it anywhere else so I wrote this. Comments welcome. I did a similar thing but seeing how I'd started off using qmail before discovering qpsmtpd, mine reads the qmail config files /var/qmail/users/assign including reading alias files configured in there - this way I have a standard qmail setup with partial wildcards addresses and have aliases for postmaster, abuse (and qmail handles things like forwarding email on to other addresses etc). So I then hand out different email addresses to different people (tim_XYZ to company XYZ etc) knowing that the prefix rule will accept any such email that I invent, but if any one address leaks or otherwise becomes too spammy then I block that explicit address with another plugin that runs BEFORE this one which checks a specific list and refuses anything from its own config list. I'm not sure if the check_badrcptto is a standard plugin or one I simply cobbled from elsewhere, so it's attached too. Of course if you don't use qmail for final delivery, then this may not be so useful but it seemed better than coming up with my own user list and wildcards and alias mechanisms :) Cheers -- Tim
