How Should You Handle Remote SMTP Users? 17
keytoe asks: "With all the recent discussion around here about spam relaying, black hole lists, spam police and so on I've decided to start taking part. According to the Securing and Testing page on ORBS, running sendmail with FEATURE(relay_local_from) enabled is Bad(tm) and the sendmail folk agree. How could one go about setting up selective relaying from remote dialup users without first knowing where they're coming from? Listing 'aol.com' and 'uswest.net' in '/etc/mail/relay-domains' simply subverts the original goal. I'm aware that authenticated SMTP will move toward this goal, but that needs to be supported on the client side - and it's not there yet for all platforms. Additionally, I've seen suggestions to use a POP-before-SMTP hack, but I'm not using the sendmail POP server. In short, I'm seeking a transparent (to the users) replacement for FEATURE(relay_local_from) that actually -will- pass the ORBS test and keep the nasty people out. Am I screwed?"
You're Screwed (Score:1)
The only good solution is to authenticate users before allowing them to send mail. As a temporary kludge, you could setup sendmail to listen to a non-standard port.
A few suggestions (Score:2)
Well, I cannot give you actual code or configuration files, but here are some ways others are doing it:
vpn or ssh portforwarding (Score:1)
I have used ssh's portforwarding feature and it works fine. Set up the foward of a port on localhost to a machine running sshd and smtp and then configure your mail client to send to localhost.
Set it up by IP and purge old IPs (Score:1)
You could probably modify your POP software (assuming it's open source) to log the source IP to a file. It should only be a line or two of code in the right place. Then set up a script to 'tail -f' that log and add IPs to the relay list. Purge the relay list on a regular basis so that IPs don't stay on it for too long.
Re:vpn or ssh portforwarding (Score:2)
Basically, you first establish an ssh connection from client to server. Then set up the client SMTP to go to port 25 on localhost. You configure ssh to forward port 25 on localhost to port 25 on the server. When the email is sent, it goes to port 25 on localhost, where ssh picks it up, encrypts it, and sends it to a nonprivileged port on the server. There, ssh decrypts it, and forwards it to port 25 on the server, and the mail is sent. And you don't need to be a relay.
The pitfall in all this is that it places the onus on the user to be savvy enough, and also requires ssh (which is only free for SOME people).
Authenticated SMTP (Score:1)
why are you still using sendmail? (Score:2)
I recommend qmail in its place. Using it, you can put all of your dialup user's ips. This is assuming that you are the one handing out IP's -- you will have a specific block of them, so you can force that you only relay from those hosts.
Also, don't use sendmail. It stores all of your emails in one big file. What happens when you get a mailbox file that is 70-700megs big? When pop comes along, it starts timing itself out when you copy the box from username to
qmail stores each email in a seperate file to prevent this. If you have all the wrapper programs it runs under give the process the resources it needs, you can easily store gigabytes 'in your pop account'.
Not to mention all the benefits of vpopmail.
I could probably go on and on about why you shouldn't use sendmail.. so I'll stop now.
ha (Score:1)
Ha, that's funny... that's a joke eh?
-rt-
Re:why are you still using sendmail? (Score:3)
Sendmail is ancient. Stop using it.
sendmail.8.10.1.tar.gz Fri Apr 07 17:45:00 2000
Ancient? 2 weeks is ancient?
Yes, the design is old, and admittedly, some of the worst pain in the ass security holes of all time have been from sendmail. But it -works-. It's up to date. And it's standard in every *NIX distribution I've seen (Slackware, redhat, debian, suse, and mandrake linux, solaris/sunos, etc etc.)
I recommend qmail in its place. Using it, you can put all of your dialup user's ips. This is assuming that you are the one handing out IP's -- you will have a specific block of them, so you can force that you only relay from those hosts.
This is what /etc/mail/relay-domains is for with sendmail.
Also, don't use sendmail. It stores all of your emails in one big file. What happens when you get a mailbox file that is 70-700megs big? When pop comes along, it starts timing itself out when you copy the box from username to .username.pop and you'll kill your pop server.
Uhhhh. If you have a user that's leaving 70 megs of email on the server, your problem does not reside in your MTA. Your problem lies in your method of systems administration. POP3 isnt really designed (IMO) for users to leave their mail on your server. IMAP maybe, but not pop3. Personally, I use quotas on user mailboxes set for 2 megs, maybe 5, depends. And if they leave mail on the server, they get bitched at.
qmail stores each email in a seperate file to prevent this. If you have all the wrapper programs it runs under give the process the resources it needs, you can easily store gigabytes 'in your pop account'.
Again, if you're storing gigabytes in a POP3 account, you need your head examined (and/or your user shot). If I need to store a gig of data somewhere, it's gonna be in an SQL database, or some other facility. Not my damned email account.
And to return on topic and answer the question at hand.... It's sucky, but SMTP-Auth or POP3 before SMTP seems to be the best thing going these days. I haven't had to deal with it much, yet, but I'm afraid it's getting ready to happen. You could design a quick little hack of a website to authenticate users to relay for 15 minutes (10? 5?). Just have it ask them for their dialup username/password, authenticate it, grab their IP out of the environment, and add them to /etc/mail/relay-domains. *shrug*
-j
Re:why are you still using sendmail? (Score:1)
IIRC, exim is the standard MTA in Debian (at least Debian woody). In earlier versions, again IIRC, it was smail. Sendmail is available for anyone who wants it, though.
-----
Similar problem (Score:2)
Go for static IP's (Score:2)
No more relaying for entire ISP networks, easier firewall rules..
I am not sure if this can easily be achieved in the USA or anywhere outside of the Netherlands, but we've got plenty of ISP's here that offer a static IP for little or no extra cost.
If such a setup is possible in your area, I'd recommend it. Convincing your client should not be any harder than "your site is insecure [open relaying / fscked firewalls are, aren't they?], but it can be fixed". The client will immediately go: "how?" and will easily accept your suggestion to go with a static IP.
Re:Similar problem (Score:1)
--
The scalloped tatters of the King in Yellow must cover
Yhtill forever. (R. W. Chambers, the King in Yellow)
Re:why are you still using sendmail? (Score:1)
--
The scalloped tatters of the King in Yellow must cover
Yhtill forever. (R. W. Chambers, the King in Yellow)
Re:why are you still using sendmail? (Score:1)
Marty
Why use temporary files? (Score:1)
Erm... that's got nothing to do with sendmail. Why don't you switch to cucipop -- no temporary files at all
Re:why are you still using sendmail? (Score:1)
This is not sendmail doing this, but your local delivery agent. We currently use an LMTP aware mail store [actually several] that are located on a different system. The mail store, in turn allows me to distribute users across multiple filesystems [using a hashed distribution of mailboxes]
Meanwhile the MTA is sendmail