Re: High volume mail handling architecture
On Fri, Sep 10, 2004 at 05:34:07PM +, Gerrit Pape wrote: On Fri, Sep 10, 2004 at 09:49:27AM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: Herre is what happens: A spammer uses my email address as the sender address in spam frequently. So, I sometimes suddenly have 2000 new mails in my inbox :-( So, that's my plea to everybody with big mail installations: make your frontend machines aware of what mail they are supposed to accept, so that you never need to bounce. (Ok, some cases will still bounce: disk full, procmail script errors etc., but these are a very small proportion.) And the other plea is, of course, get rid of qmail and other products which accept all mail by default. As far as my experience goes, pleas or complaints against other people doesn't help much if you want to see something changed. Better help yourself. I suggest to instruct your mail user agent to make use of the (apparently almost forgotten) fact that the sender's addresses in the envelope and in the header can be different. Most today's mail transfer agents should support address extensions. If your address is used as envelope sender in unsolicited mail, it's your public one. Use a non-public address as envelope sender of mail you send, and simply change it in case it gets abused; only bouncers should send mail to this address, and they usually do within two weeks. Now you can configure your MTA to outright reject delivery notifications solely based on the information in the envelope. $ mconnect a.mx.smarden.org 220 smarden.org ESMTP mail from: 250 Sender accepted. rcpt to:[EMAIL PROTECTED] 553 This address cannot get bounces, either you are not bouncing to the envelope sender, or the envelope of the mail you bounce is forged. quit 221 Good bye. $ I'm doing this for about ten months now, and don't see most of the unwanted delivery notifications, including delivery confirmation requests for unsolicited mail with forged envelope. Sorry to reopen such an old thread. I'd saved this mail for reference as I too get a lot of bounces for spam with forged mail headers. A fresh run of spam that some wanker has initiated in my name has made my inbox unbearable this last few days so I need to do something about it. Would it be possible for you, Gerrit, to expand a little on your setup? I currently use fetchmail to get my mail from a catchall mailbox at my ISP. Can I use the envelope sender trick in this case as I can't see an easy way to differentiate between bounces and normal email once the messages reach my box? Cheers John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VPN
On Thu, Jul 01, 2004 at 07:18:12PM -0300, [EMAIL PROTECTED] wrote: Em Qui, 2004-07-01 ?s 04:46, John Hedges escreveu: On Wed, Jun 30, 2004 at 09:47:26PM -0700, Stephen Le wrote: I think your should try openvpn http://www.openvpn.org . Although OpenVPN is a really nice and easy to setup solution, it uses SSL tunneling, rather than IPSEC encryption. There is also the kernel support in 2.6. If you are wanting to use a 2.4 kernel it has been backported. There's a howto here: http://www.pseudorandom.co.uk/2004/debian/ipsec/ Thanks Stephen and John for tips and links. Just 1 more question. How about racoon??? racoon works just fine with the kernel modules and AFAIK with free/openswan too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VPN
On Thu, Jul 01, 2004 at 07:18:12PM -0300, [EMAIL PROTECTED] wrote: Em Qui, 2004-07-01 ?s 04:46, John Hedges escreveu: On Wed, Jun 30, 2004 at 09:47:26PM -0700, Stephen Le wrote: I think your should try openvpn http://www.openvpn.org . Although OpenVPN is a really nice and easy to setup solution, it uses SSL tunneling, rather than IPSEC encryption. There is also the kernel support in 2.6. If you are wanting to use a 2.4 kernel it has been backported. There's a howto here: http://www.pseudorandom.co.uk/2004/debian/ipsec/ Thanks Stephen and John for tips and links. Just 1 more question. How about racoon??? racoon works just fine with the kernel modules and AFAIK with free/openswan too.
Re: VPN
On Wed, Jun 30, 2004 at 09:47:26PM -0700, Stephen Le wrote: I think your should try openvpn http://www.openvpn.org . Although OpenVPN is a really nice and easy to setup solution, it uses SSL tunneling, rather than IPSEC encryption. There is also the kernel support in 2.6. If you are wanting to use a 2.4 kernel it has been backported. There's a howto here: http://www.pseudorandom.co.uk/2004/debian/ipsec/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VPN
On Wed, Jun 30, 2004 at 09:47:26PM -0700, Stephen Le wrote: I think your should try openvpn http://www.openvpn.org . Although OpenVPN is a really nice and easy to setup solution, it uses SSL tunneling, rather than IPSEC encryption. There is also the kernel support in 2.6. If you are wanting to use a 2.4 kernel it has been backported. There's a howto here: http://www.pseudorandom.co.uk/2004/debian/ipsec/
Re: help on masquerading
On Tue, Jun 29, 2004 at 12:38:58PM +0545, Ritesh Raj Sarraf wrote: Hello all, I have a masquerading server with 2 ethernet cards, eth0(202.52.x.x) to the internet and eth1(192.168.100.x) to my local network customers. I've enabled nat and my customers are able to browse the internet well (My customer are cyber cafe owners). I've limited their bandwidth. The issue is that I've limited their bandwidth on ipbasis ( say 192.168.100.6 is assigned 64kbps). My view is that they can change their ip to something else (say 192.168.100.15) and consume full bandwidth because i've not limited or given more bandwidth to that particual ip. To accomplish my condition, I thought of: #iptables -P FORWARD DROP To disable all packet forwarding by default. and then #iptables -A FORWARD -s 192.168.100.6 -i eth1 -j ACCEPT To allow my that particular ip to access the net. But after this command the customer isn't able to browse the net. He's still able to ping my masquerading server. Where am i wrong and what could be a solution ? Please help ! I also think my approach to be insufficient. Because still my customer with ip (192.168.100.6) can connect to the net if he changes the ip to my some other customers ip (192.168.100.15), say if his machine is shutdown at that time. Is there a better approach ? Any reply will be greatly appreciated. Ritesh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Hi Ritesh I don't know much about iptables but you may need to add a rule to allow packets from the net back to eth1. You can use IPSec/racoon configured to use pre-shared keys or X.509 certificates to authorise peers. You could, for example, force certain peers to use specific IPs and allow only nominal bandwidth to those peers that don't authenticate. Cheers John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help on masquerading
On Tue, Jun 29, 2004 at 12:38:58PM +0545, Ritesh Raj Sarraf wrote: Hello all, I have a masquerading server with 2 ethernet cards, eth0(202.52.x.x) to the internet and eth1(192.168.100.x) to my local network customers. I've enabled nat and my customers are able to browse the internet well (My customer are cyber cafe owners). I've limited their bandwidth. The issue is that I've limited their bandwidth on ipbasis ( say 192.168.100.6 is assigned 64kbps). My view is that they can change their ip to something else (say 192.168.100.15) and consume full bandwidth because i've not limited or given more bandwidth to that particual ip. To accomplish my condition, I thought of: #iptables -P FORWARD DROP To disable all packet forwarding by default. and then #iptables -A FORWARD -s 192.168.100.6 -i eth1 -j ACCEPT To allow my that particular ip to access the net. But after this command the customer isn't able to browse the net. He's still able to ping my masquerading server. Where am i wrong and what could be a solution ? Please help ! I also think my approach to be insufficient. Because still my customer with ip (192.168.100.6) can connect to the net if he changes the ip to my some other customers ip (192.168.100.15), say if his machine is shutdown at that time. Is there a better approach ? Any reply will be greatly appreciated. Ritesh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Hi Ritesh I don't know much about iptables but you may need to add a rule to allow packets from the net back to eth1. You can use IPSec/racoon configured to use pre-shared keys or X.509 certificates to authorise peers. You could, for example, force certain peers to use specific IPs and allow only nominal bandwidth to those peers that don't authenticate. Cheers John
