Re: [qmailtoaster] Controlling SMTP access to mail server.
Erik Espinoza wrote: I don't see how tcprules would fix Stephen's problem. He's basically ticked that spammers are hitting his hidden server directly. I say don't just hide it, firewall it. I agree. Two different solutions to the same problem. Either reject it at the firewall, or reject it with tcprules (using the deny option). Doing so with iptables is (very) slightly more efficient. Easier to do with tcprules though. Given the mission of this project, I think the later is preferable. Besides which, I could be a lowly mail administrator in a large corporation where I wouldn't have access to iptables, and the haughty network administrator might not be inclined to change iptables for me. Hypothetically of course. ;) Show me one scenario where this would make sense? I can't think of one. I want to set CHKUSER_RCPTLIMIT=15 for non-local submissions, and CHKUSER_RCPTLIMIT=50 for local submissions and smtp. -- -Eric 'shubes' - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Controlling SMTP access to mail server.
Erik Espinoza wrote: A BSD admin that can take qmailtoaster and make it run on BSD can implmenet a firewall policy using ipf. Sure ;-D. But you're not taking into account admin laziness. ES, port 587 is all about SMTP-AUTH, meaning that tcprules shouldn't really matter as it's all done through auth. Port 25 doesn't require auth, therefore it would need independent control. What possible scenario would we need to control port 587 independently of port 25 and why? This seems like unnecessary complication, with no pay off at all. You know, that is the reason I'd like to see that files separated. Submission service and SMTP service in fact serve for totally different purposes. One is used for MUA-MTA message submission, other is used for MTA-to-MTA message transfer. I can hardly see why should I use same tcprules for totally different services? In ideal world I would enable things like SPF and simscan only on SMTP service, and domainkeys or dkim signing only on SUBMISSION service. And I would never-ever add IP ranges with RELAYCLIENT= to the tcprules for SUBMISSION service as it will look like nonsence there - I always want my users to auth themselves to use SUBMISSION service. That is why I use separate rulesets for SMTP and SUBMISSION. I asked nearly the same thing a couple of weeks ago and was told we use one file. Since I consider much of what we do as a basic package and in many cases a work in progress, I created a second tcpserver submission file for my toaster box. Submission port usage is similar, but very different. It even has different services for each (part of the reason i decided to separate them)... if I typo the file for the smtp service (port 25), tcp.smtp, it would take down my smtp service, but not my submission service... thus making it easier to tell where the problem is... we already separate the logs. Not to mention I have totally different rules in each for handling things like rbl lookups and friendly ip's. I know about putting firewall/spam filters in front too we have a barracuda as an mx filter for some of our domains (debian, non-toaster server) and it's ridiculous to have it go through the scans too. Our debian box essentially allows the mailfilter ip through unmolested and uses :deny for the rest because the customers are pointed to the submission port already. I used to setup port 26 for customers (before submission and didn't use smtp auth's port) to get around isp's blocking port 25 to send (for our hosted customers off-net). I allow relaying for friendly ip's through submission, and others can auth and send without passing through spamscanning and rbl lookups. For anything on port 25... tough... you get the works (either mx level filtering on another box or rbl's/spam/clamd on the local server). George - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Controlling SMTP access to mail server.
Hi, On 2/1/07, George Sweetnam [EMAIL PROTECTED] wrote: I used to setup port 26 for customers (before submission and didn't use smtp auth's port) to get around isp's blocking port 25 to send (for our hosted customers off-net). I allow relaying for friendly ip's through submission, I still use this method: I run another smtp at port 2525 for authentication. Is there any reason I should change to using the submission port? Regards, Peter - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Controlling SMTP access to mail server.
Other than it's the standard, no. Erik On 2/1/07, Peter Peltonen [EMAIL PROTECTED] wrote: Hi, On 2/1/07, George Sweetnam [EMAIL PROTECTED] wrote: I used to setup port 26 for customers (before submission and didn't use smtp auth's port) to get around isp's blocking port 25 to send (for our hosted customers off-net). I allow relaying for friendly ip's through submission, I still use this method: I run another smtp at port 2525 for authentication. Is there any reason I should change to using the submission port? Regards, Peter - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[2]: [qmailtoaster] Controlling SMTP access to mail server.
Greetings, Erik. 31 ?? 2007 ?., 6:02:20 you have wrote: Separate tcprules file for submission port seems to me as a better approach. It keeps administration of QT flexible and unified, and also it is more cross-platforming way, as tcpserver works on any platform qmail can run on, while iptables is available only on linux systems based on kernels 2.4.x and later. Who cares? We don't even support Debian. . . :) Me, for example ;-D. A friend of mine, also a system engineer, administer small FreeBSD based cluster, and he uses QT in his setup. Accordingly to his words, it wasn't too hard to build and install RPM system on his BSD boxes, and then to correct specs so basic QT parts builds up and install successfully. Well, in any case we can always create tcp.submission ourselves, just like I do it for tcp.pop3 ;-D. But the laziness of sysadmin is the thing that makes me want tcp.submission to be included in stock toaster. -- Best Regards, Alexey Loukianov mailto:[EMAIL PROTECTED] Software Development Department, Lavtech Corp http://mnogo.ru, http://lavtech.ru - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Controlling SMTP access to mail server.
Alexey Loukianov wrote: Greetings, Erik. 31 ?? 2007 ?., 6:02:20 you have wrote: Separate tcprules file for submission port seems to me as a better approach. It keeps administration of QT flexible and unified, and also it is more cross-platforming way, as tcpserver works on any platform qmail can run on, while iptables is available only on linux systems based on kernels 2.4.x and later. Who cares? We don't even support Debian. . . :) Me, for example ;-D. A friend of mine, also a system engineer, administer small FreeBSD based cluster, and he uses QT in his setup. Accordingly to his words, it wasn't too hard to build and install RPM system on his BSD boxes, and then to correct specs so basic QT parts builds up and install successfully. Well, in any case we can always create tcp.submission ourselves, just like I do it for tcp.pop3 ;-D. But the laziness of sysadmin is the thing that makes me want tcp.submission to be included in stock toaster. I agree with Alexey on this. Besides which, wouldn't it be nice to have QT on BSD as well? I wonder if Alexey's friend would care to contribute in this area. -- -Eric 'shubes' - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[2]: [qmailtoaster] Controlling SMTP access to mail server.
A BSD admin that can take qmailtoaster and make it run on BSD can implmenet a firewall policy using ipf. I don't think having two tcp.smtp's is going to help, it doesn't seem to solve any problems we are having. Erik On 1/31/07, Alexey Loukianov [EMAIL PROTECTED] wrote: Greetings, Eric. 31 января 2007 г., 22:05:38 you have wrote: Alexey Loukianov wrote: Greetings, Erik. 31 ?? 2007 ?., 6:02:20 you have wrote: Separate tcprules file for submission port seems to me as a better approach. It keeps administration of QT flexible and unified, and also it is more cross-platforming way, as tcpserver works on any platform qmail can run on, while iptables is available only on linux systems based on kernels 2.4.x and later. Who cares? We don't even support Debian. . . :) Me, for example ;-D. A friend of mine, also a system engineer, administer small FreeBSD based cluster, and he uses QT in his setup. Accordingly to his words, it wasn't too hard to build and install RPM system on his BSD boxes, and then to correct specs so basic QT parts builds up and install successfully. Well, in any case we can always create tcp.submission ourselves, just like I do it for tcp.pop3 ;-D. But the laziness of sysadmin is the thing that makes me want tcp.submission to be included in stock toaster. I agree with Alexey on this. Besides which, wouldn't it be nice to have QT on BSD as well? I wonder if Alexey's friend would care to contribute in this area. It is not so easy, as BSD way is not to use RPMS, while main toaster advantage is it's RPM nature. A friend of mine came to BSD world from RedHad based linux distros, that is why he uses RPM even on BSD - it is just a matter of habbit. Well, it is still possible to port QT on BSD and distribute is as a bunch of tarballs if we will find some BSD geek who will want to maintenance it. But I don't think it is a urgent task for qt-dev team ;-D. -- Best Regards, Alexey Loukianov mailto:[EMAIL PROTECTED] Software Development Department, Lavtech Corp http://mnogo.ru, http://lavtech.ru - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Controlling SMTP access to mail server.
Problem: controlling/configuring smtp and submission independently is difficult, if not impossible. Is there are reason why there *shouldn't* be separate tcprules files? I see no advantage to having them share the same one. Erik Espinoza wrote: A BSD admin that can take qmailtoaster and make it run on BSD can implmenet a firewall policy using ipf. I don't think having two tcp.smtp's is going to help, it doesn't seem to solve any problems we are having. Erik On 1/31/07, Alexey Loukianov [EMAIL PROTECTED] wrote: Greetings, Eric. 31 января 2007 г., 22:05:38 you have wrote: Alexey Loukianov wrote: Greetings, Erik. 31 ?? 2007 ?., 6:02:20 you have wrote: Separate tcprules file for submission port seems to me as a better approach. It keeps administration of QT flexible and unified, and also it is more cross-platforming way, as tcpserver works on any platform qmail can run on, while iptables is available only on linux systems based on kernels 2.4.x and later. Who cares? We don't even support Debian. . . :) Me, for example ;-D. A friend of mine, also a system engineer, administer small FreeBSD based cluster, and he uses QT in his setup. Accordingly to his words, it wasn't too hard to build and install RPM system on his BSD boxes, and then to correct specs so basic QT parts builds up and install successfully. Well, in any case we can always create tcp.submission ourselves, just like I do it for tcp.pop3 ;-D. But the laziness of sysadmin is the thing that makes me want tcp.submission to be included in stock toaster. I agree with Alexey on this. Besides which, wouldn't it be nice to have QT on BSD as well? I wonder if Alexey's friend would care to contribute in this area. It is not so easy, as BSD way is not to use RPMS, while main toaster advantage is it's RPM nature. A friend of mine came to BSD world from RedHad based linux distros, that is why he uses RPM even on BSD - it is just a matter of habbit. Well, it is still possible to port QT on BSD and distribute is as a bunch of tarballs if we will find some BSD geek who will want to maintenance it. But I don't think it is a urgent task for qt-dev team ;-D. -- Best Regards, Alexey Loukianov mailto:[EMAIL PROTECTED] Software Development Department, Lavtech Corp http://mnogo.ru, http://lavtech.ru - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Eric 'shubes' - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Controlling SMTP access to mail server.
ES, port 587 is all about SMTP-AUTH, meaning that tcprules shouldn't really matter as it's all done through auth. Port 25 doesn't require auth, therefore it would need independent control. What possible scenario would we need to control port 587 independently of port 25 and why? This seems like unnecessary complication, with no pay off at all. Erik On 1/31/07, Eric Shubes [EMAIL PROTECTED] wrote: Problem: controlling/configuring smtp and submission independently is difficult, if not impossible. Is there are reason why there *shouldn't* be separate tcprules files? I see no advantage to having them share the same one. Erik Espinoza wrote: A BSD admin that can take qmailtoaster and make it run on BSD can implmenet a firewall policy using ipf. I don't think having two tcp.smtp's is going to help, it doesn't seem to solve any problems we are having. Erik On 1/31/07, Alexey Loukianov [EMAIL PROTECTED] wrote: Greetings, Eric. 31 января 2007 г., 22:05:38 you have wrote: Alexey Loukianov wrote: Greetings, Erik. 31 ?? 2007 ?., 6:02:20 you have wrote: Separate tcprules file for submission port seems to me as a better approach. It keeps administration of QT flexible and unified, and also it is more cross-platforming way, as tcpserver works on any platform qmail can run on, while iptables is available only on linux systems based on kernels 2.4.x and later. Who cares? We don't even support Debian. . . :) Me, for example ;-D. A friend of mine, also a system engineer, administer small FreeBSD based cluster, and he uses QT in his setup. Accordingly to his words, it wasn't too hard to build and install RPM system on his BSD boxes, and then to correct specs so basic QT parts builds up and install successfully. Well, in any case we can always create tcp.submission ourselves, just like I do it for tcp.pop3 ;-D. But the laziness of sysadmin is the thing that makes me want tcp.submission to be included in stock toaster. I agree with Alexey on this. Besides which, wouldn't it be nice to have QT on BSD as well? I wonder if Alexey's friend would care to contribute in this area. It is not so easy, as BSD way is not to use RPMS, while main toaster advantage is it's RPM nature. A friend of mine came to BSD world from RedHad based linux distros, that is why he uses RPM even on BSD - it is just a matter of habbit. Well, it is still possible to port QT on BSD and distribute is as a bunch of tarballs if we will find some BSD geek who will want to maintenance it. But I don't think it is a urgent task for qt-dev team ;-D. -- Best Regards, Alexey Loukianov mailto:[EMAIL PROTECTED] Software Development Department, Lavtech Corp http://mnogo.ru, http://lavtech.ru - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Eric 'shubes' - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Controlling SMTP access to mail server.
Erik Espinoza wrote: A BSD admin that can take qmailtoaster and make it run on BSD can implmenet a firewall policy using ipf. Sure ;-D. But you're not taking into account admin laziness. ES, port 587 is all about SMTP-AUTH, meaning that tcprules shouldn't really matter as it's all done through auth. Port 25 doesn't require auth, therefore it would need independent control. What possible scenario would we need to control port 587 independently of port 25 and why? This seems like unnecessary complication, with no pay off at all. You know, that is the reason I'd like to see that files separated. Submission service and SMTP service in fact serve for totally different purposes. One is used for MUA-MTA message submission, other is used for MTA-to-MTA message transfer. I can hardly see why should I use same tcprules for totally different services? In ideal world I would enable things like SPF and simscan only on SMTP service, and domainkeys or dkim signing only on SUBMISSION service. And I would never-ever add IP ranges with RELAYCLIENT= to the tcprules for SUBMISSION service as it will look like nonsence there - I always want my users to auth themselves to use SUBMISSION service. That is why I use separate rulesets for SMTP and SUBMISSION. -- Best regards, Alexey Loukianov mailto:[EMAIL PROTECTED] System Engineer, IT Department, Lavtech Corp. - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Controlling SMTP access to mail server.
Erik Espinoza wrote: ES, port 587 is all about SMTP-AUTH, meaning that tcprules shouldn't really matter as it's all done through auth. Port 25 doesn't require auth, therefore it would need independent control. This sounds to me like a good argument *for* separating them. The processes are inherently (naturally) different. Saying that tcprules shouldn't really matter for submission isn't really the case. It's true that there should essentially be no rules, but that's different. If you need to put constraints on MTA sessions, as Stephen needed to do (remember what started this thread?), they would be inappropriate for MSA sessions (which would need to be wide open), which causes a problem. What possible scenario would we need to control port 587 independently of port 25 and why? Any time that an admin might need to control MTA traffic/access independently of MSA. The MSA rules would be simple and static (practically non existent, because SMTP-AUTH is handling everything, and would rarely need to change), while most of the tailoring (allowing only MTA from a limited set of servers, for instance) would exist in the MTA rules. This seems like unnecessary complication, with no pay off at all. I guess what you see as complication I see as simplicity. The payoff is being able to change MTA behavior without impacting the MSA. This is the same reason that MSA was separated to begin with, was it not? Erik On 1/31/07, Eric Shubes [EMAIL PROTECTED] wrote: Problem: controlling/configuring smtp and submission independently is difficult, if not impossible. Is there are reason why there *shouldn't* be separate tcprules files? I see no advantage to having them share the same one. Erik Espinoza wrote: A BSD admin that can take qmailtoaster and make it run on BSD can implmenet a firewall policy using ipf. I don't think having two tcp.smtp's is going to help, it doesn't seem to solve any problems we are having. Erik On 1/31/07, Alexey Loukianov [EMAIL PROTECTED] wrote: Greetings, Eric. 31 января 2007 г., 22:05:38 you have wrote: Alexey Loukianov wrote: Greetings, Erik. 31 ?? 2007 ?., 6:02:20 you have wrote: Separate tcprules file for submission port seems to me as a better approach. It keeps administration of QT flexible and unified, and also it is more cross-platforming way, as tcpserver works on any platform qmail can run on, while iptables is available only on linux systems based on kernels 2.4.x and later. Who cares? We don't even support Debian. . . :) Me, for example ;-D. A friend of mine, also a system engineer, administer small FreeBSD based cluster, and he uses QT in his setup. Accordingly to his words, it wasn't too hard to build and install RPM system on his BSD boxes, and then to correct specs so basic QT parts builds up and install successfully. Well, in any case we can always create tcp.submission ourselves, just like I do it for tcp.pop3 ;-D. But the laziness of sysadmin is the thing that makes me want tcp.submission to be included in stock toaster. I agree with Alexey on this. Besides which, wouldn't it be nice to have QT on BSD as well? I wonder if Alexey's friend would care to contribute in this area. It is not so easy, as BSD way is not to use RPMS, while main toaster advantage is it's RPM nature. A friend of mine came to BSD world from RedHad based linux distros, that is why he uses RPM even on BSD - it is just a matter of habbit. Well, it is still possible to port QT on BSD and distribute is as a bunch of tarballs if we will find some BSD geek who will want to maintenance it. But I don't think it is a urgent task for qt-dev team ;-D. -- Best Regards, Alexey Loukianov mailto:[EMAIL PROTECTED] Software Development Department, Lavtech Corp http://mnogo.ru, http://lavtech.ru -- -Eric 'shubes' - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Controlling SMTP access to mail server.
ES, port 587 is all about SMTP-AUTH, meaning that tcprules shouldn't really matter as it's all done through auth. Port 25 doesn't require auth, therefore it would need independent control. This sounds to me like a good argument *for* separating them. The processes are inherently (naturally) different. Saying that tcprules shouldn't really matter for submission isn't really the case. It's true that there should essentially be no rules, but that's different. If you need to put constraints on MTA sessions, as Stephen needed to do (remember what started this thread?), they would be inappropriate for MSA sessions (which would need to be wide open), which causes a problem. I don't see how tcprules would fix Stephen's problem. He's basically ticked that spammers are hitting his hidden server directly. I say don't just hide it, firewall it. What possible scenario would we need to control port 587 independently of port 25 and why? Any time that an admin might need to control MTA traffic/access independently of MSA. The MSA rules would be simple and static (practically non existent, because SMTP-AUTH is handling everything, and would rarely need to change), while most of the tailoring (allowing only MTA from a limited set of servers, for instance) would exist in the MTA rules. This seems like unnecessary complication, with no pay off at all. I guess what you see as complication I see as simplicity. The payoff is being able to change MTA behavior without impacting the MSA. This is the same reason that MSA was separated to begin with, was it not? Show me one scenario where this would make sense? I can't think of one. Erik - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[qmailtoaster] Controlling SMTP access to mail server.
Hello List, I have a small problem I though someone might have a solution for. I put an anti-spam server in front of our local qmail system and this is working pretty well, it has dropped the load on our qmail server drastically. The problem I’m having is spammers are sending email directly to our server bypassing the anti-spam server, I have tried a deny in /etc/tcpserver.d/tcp.smtp file but then we have problems with offsite customers connecting via smtp, I thought that smtp relay was supposed to get set if they have an authenticated account but apparently I’m not understanding fully how this is supposed to work. Anyway I need Mr. Toaster to receive smtp connections from customers local and off subnet and only except email from our anti-spam system, other than that I want all smtp rejected. I thought about adding a deny for the spammers that are sending directly to the qmail system but there are really to many. Thanks for any help/ideas, Stephen -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.15/659 - Release Date: 1/30/2007 9:31 AM
Re: [qmailtoaster] Controlling SMTP access to mail server.
Stephen Spicer wrote: Hello List, I have a small problem I though someone might have a solution for. I put an anti-spam server in front of our local qmail system and this is working pretty well, it has dropped the load on our qmail server drastically. The problem I’m having is spammers are sending email directly to our server bypassing the anti-spam server, I have tried a deny in /etc/tcpserver.d/tcp.smtp file but then we have problems with offsite customers connecting via smtp, I thought that smtp relay was supposed to get set if they have an authenticated account but apparently I’m not understanding fully how this is supposed to work. Sounds to me like you need two tcprules (tcp.smtp) files, one for port 25 (allowing connections from your anti-spam server and deny everything else), and a separate one for port 587 (submissions). In the present stock toaster, the two qmail-smtp processes share the same tcp.smtp.cdb (tcprules) file. I think you can simply configure a separate tcp.smtp.cdb (tcp.submit.cdb or some other name) file, one for each port. Then change the appropriate run file and qmailctl script accordingly. Someone will undoubtedly correct me here if this isn't right, or there's a better way. EE, it might not be a bad idea to create a separate tcprules file for submissions. I'm kinda surprised you didn't do this when you created the submission port. :( Anyway I need Mr. Toaster to receive smtp connections from customers local and off subnet and only except email from our anti-spam system, other than that I want all smtp rejected. I thought about adding a deny for the spammers that are sending directly to the qmail system but there are really to many. Thanks for any help/ideas, Stephen Do offsite -- -Eric 'shubes' - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Controlling SMTP access to mail server.
Indeed, I'd run port 25 and iptables it so that only the scanning server can connect. Then force the users to use the standard port of 587 for outgoing smtp. Erik On 1/30/07, Eric Shubes [EMAIL PROTECTED] wrote: Stephen Spicer wrote: Hello List, I have a small problem I though someone might have a solution for. I put an anti-spam server in front of our local qmail system and this is working pretty well, it has dropped the load on our qmail server drastically. The problem I'm having is spammers are sending email directly to our server bypassing the anti-spam server, I have tried a deny in /etc/tcpserver.d/tcp.smtp file but then we have problems with offsite customers connecting via smtp, I thought that smtp relay was supposed to get set if they have an authenticated account but apparently I'm not understanding fully how this is supposed to work. Sounds to me like you need two tcprules (tcp.smtp) files, one for port 25 (allowing connections from your anti-spam server and deny everything else), and a separate one for port 587 (submissions). In the present stock toaster, the two qmail-smtp processes share the same tcp.smtp.cdb (tcprules) file. I think you can simply configure a separate tcp.smtp.cdb (tcp.submit.cdb or some other name) file, one for each port. Then change the appropriate run file and qmailctl script accordingly. Someone will undoubtedly correct me here if this isn't right, or there's a better way. EE, it might not be a bad idea to create a separate tcprules file for submissions. I'm kinda surprised you didn't do this when you created the submission port. :( Anyway I need Mr. Toaster to receive smtp connections from customers local and off subnet and only except email from our anti-spam system, other than that I want all smtp rejected. I thought about adding a deny for the spammers that are sending directly to the qmail system but there are really to many. Thanks for any help/ideas, Stephen Do offsite -- -Eric 'shubes' - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Controlling SMTP access to mail server.
Erik Espinoza wrote: Indeed, I'd run port 25 and iptables it so that only the scanning server can connect. Then force the users to use the standard port of 587 for outgoing smtp. Separate tcprules file for submission port seems to me as a better approach. It keeps administration of QT flexible and unified, and also it is more cross-platforming way, as tcpserver works on any platform qmail can run on, while iptables is available only on linux systems based on kernels 2.4.x and later. -- Best regards, Alexey Loukianov mailto:[EMAIL PROTECTED] System Engineer, IT Department, Lavtech Corp. - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Controlling SMTP access to mail server.
Hi Alexey, Separate tcprules file for submission port seems to me as a better approach. It keeps administration of QT flexible and unified, and also it is more cross-platforming way, as tcpserver works on any platform qmail can run on, while iptables is available only on linux systems based on kernels 2.4.x and later. Who cares? We don't even support Debian. . . :) Erik - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
