RE: need some spam/relay help
Is it possible to use Bruce Guenter's QMAILQUEUE to hold sent mail in a queue until the user authenticated him or herself via pop. I was thinking a program could be called to dump the mail in the queue and send back a notification to the sender on authorization failure. Thank you Russell
Re: need some spam/relay help
On Tue, Feb 23, 1999 at 01:15:21AM -0800, Russell Evans wrote: Is it possible to use Bruce Guenter's QMAILQUEUE to hold sent mail in a queue until the user authenticated him or herself via pop. I was thinking a program could be called to dump the mail in the queue and send back a notification to the sender on authorization failure. It is certainly possible, if not somewhat difficult, to do this. The biggest problem that I've encountered in implementing things like this is that the envelope information is sent *after* the message is completed instead of *before*. What you would need to do is: - send the message to a temporary file - read the sender address from the envelope - determine if that sender has been authenticated - if so, send the message to qmail-queue, followed by the envelope - otherwise, send the envelope to a temporary file as well - when the user authenticates with POP, check for temporary files that would be caused by that user and deliver them to qmail-queue There are several obvious holes in this, though. What if the user never authenticates, or sends piles of mail before authenticating? This could become a big DOS attack. Ownership also becomes sticky, as the files delivered through the QMAILQUEUE mechanism would be owned by whatever user executes qmail-smtpd (which should not be root), while the program that would feed off the authentication would run as that user, making the files unreadable. How and where do you create secure temporary files? -- Bruce Guenter, QCC Communications Corp. EMail: [EMAIL PROTECTED] Phone: (306)249-0220 WWW: http://www.qcc.sk.ca/~bguenter/
Re: need some spam/relay help
On the qmail list [EMAIL PROTECTED] wrote: I don't recommend that anyone run an open relay and I'll continue to tell people not to and to refer them to FAQ 5.4, but I'm becoming increasingly sympathetic to people who think they need to. Whether the problem can be fixed without some kind of username/password authentication in SMTP I don't know, but I think it's something worth talking about. POP before SMTP ? -- #include std_disclaim.h Lorens Kockum
Re: need some spam/relay help
| I don't recommend that anyone run an open relay and I'll continue to tell | people not to and to refer them to FAQ 5.4, but I'm becoming increasingly | sympathetic to people who think they need to. Whether the problem can be | fixed without some kind of username/password authentication in SMTP I | don't know, but I think it's something worth talking about. Probably the easiest solution is an applet on the PC that tunnels 127.0.0.1:25 to a private smtp or qmtp server on the mail host, doing authentication in the process. SMOP. Wasn't there a usenix paper about this a while back? Bingo! This solution allows all dumb MUAs to function, as well as unattended server scripts. On my laptop (running Linux), I use an ssh tunnel to relay my queued mail. It's secure and it uses data compression, so my mail is sent more quickly. I'd be more than happy to describe my setup for those that want to emulate it. What's needed for Windows is a simple, but configurable program that runs on the user's machine and listens to localhost:25. This program waits for the user's MUA to send mail and then initiates a connection to the mail relay, authenticating in the process. I could write this in Perl, but that would require users to download and install ActiveState's Perl for Win32 on their machines. Anyone interested in writing a little executable? We all agree that the ony solution to provide service for users and not to spammers is authentication before allowing the relay of mail. Since there is no standard (RFC) for this -- and even if there was, there would be many MUAs that didn't follow the standard -- the only solutions are a) to authenticate to server and then allow relaying for a certain amount of time (e.g. POP before relay), or b) taking all the dumb MUAs out of the loop by intercepting the sending of mail. Implementing BOTH is the best solution, IMHO, but a program has yet to be written to do the latter. Glenn Strauss [EMAIL PROTECTED]
Re: need some spam/relay help
A few people requested a description of how I collect and send the mail from my laptop, a 486 running RedHat Linux 5.2, over SSH tunnels. ...No problems with authenticated relaying here. :-) Feel free to email me with additional questions on my setup. Glenn Strauss [EMAIL PROTECTED] Server requirements: (i.e. the pop server to which you connect) MTA (any) SSH which allows user logins Required packages: (on the client machine) qmail http://www.qmail.org/ serialmail ftp://koobera.math.uic.edu/www/serialmail.html fetchmail http://www.tuxedo.org/~esr/fetchmail/ sshhttp://www.ssh.fi/ Basically, follow the instructions that come with each package. I compiled and installed the packages using default settings, and configured qmail to catch all outgoing mail in a maildir ~alias/pppdir, as recommended by serialmail docs. Also, to avoid being prompted by ssh for a password you must set up a ~/.ssh/identity for RSA authentication. The only non-standard thing I did was modify /usr/local/bin/maildirsmtp, which I included below. I changed the port number from 25 (standard SMTP) to because I run my own qmail-smtpd on port 25 and want to send mail out to the remote server's smtp port 25. Port is just an arbitrary free port on my machine over which I chose to use ssh to tunnel the relayed mail; port on my machine is effectively port 25 on the remote server. /usr/local/bin/maildirsmtp #!/bin/sh # WARNING: This file was auto-generated. Do not edit! exec \ /usr/local/bin/maildirserial -b -t 1209600 -- "$1" "$2" \ tcpclient -RHl0 -- "$3" \ /usr/local/bin/serialsmtp "$2" "$4" I run 'fetchmail', which uses my .fetchmailrc (below), in /etc/ppp/ip-up.local each time I dial in, and I run 'upload-mail' (below) before I shut down the ppp connection. Each time ssh is invoked below, it makes the connection and issues the command 'sleep 10' on the remote machine, giving the fetchmail or maildirsmtp process 10 seconds (ample time) to set up its own secure connection, before the original ssh connection is closed. /root/.fetchmailrc # .fetchmailrc defaults forcecr poll localhost protocol pop3 port : preconnect "ssh -C -f [EMAIL PROTECTED] -L :netspace.org:110 sleep 10" user gs is gs pass MyPaSsWoRd /root/bin/upload-mail #!/bin/sh # use serialmail to send queued mail ssh -C -f [EMAIL PROTECTED] -L :netspace.org:25 sleep 10 /usr/local/bin/maildirsmtp ~alias/pppdir alias-ppp- localhost gs.netspace.org
Re: need some spam/relay help
On Fri, Feb 19, 1999 at 12:45:06PM -0500, Scott Schwartz wrote: The question arises, however, why those aol users don't just submit their mail to aol's smtp server? Presumably an aol user, just like any person on the internet, can submit a message to their local smtp server (for which they are authenticated) with a "From:" line that has one of your virtual domains in it (or indeed, any string they like). So why do aol users need to use you as their injection point? Try this with msn.com. If you're connected to their network and submit a message to the local smtp server using a "From" address that isn't an msn.com address, they'll *silently* discard your mail. They'll accept it, and without warning deposit it into a bitbucket. (This was the case several months ago. They may have wised up since, but I doubt it.) I've heard that other ISPs are requiring that the envelope sender domain be one of their domains in order for you to be able to relay, thus making them unusable as relays if you use a different address. At one point (and this may have changed), ibm.net would give you a "550: Unauthorized access" as soon as it saw a MAIL FROM with a non-ibm.net address. Another problem I've had runs along the lines of the following: Me: "Use your ISPs SMTP server to send your mail." AOL user: "Huh?" I'm not even sure that AOL provides relays for outgoing mail, since they use some kind of proprietary mail protocol that's built in to their front-end software. Because of stupid policies like MSN's or users' conceptual problems with relaying mail, it's becoming very difficult to provide people on different ISPs with e-mail addresses that they can use. I usually wind up telling MSN users that their mail will just have to look like it's coming from their msn.com addresses, and there's nothing I can do about it. I tell AOL users to get a real ISP. I don't recommend that anyone run an open relay and I'll continue to tell people not to and to refer them to FAQ 5.4, but I'm becoming increasingly sympathetic to people who think they need to. Whether the problem can be fixed without some kind of username/password authentication in SMTP I don't know, but I think it's something worth talking about. Chris
Re: need some spam/relay help
On Fri, Feb 19, 1999 at 03:59:11PM -0500, Scott Schwartz wrote: Chris Johnson [EMAIL PROTECTED] writes: | On Fri, Feb 19, 1999 at 12:45:06PM -0500, Scott Schwartz wrote: | The question arises, however, why those aol users don't just submit their | mail to aol's smtp server? Presumably an aol user, just like any person on | the internet, can submit a message to their local smtp server (for which they | are authenticated) with a "From:" line that has one of your virtual domains | in it (or indeed, any string they like). So why do aol users need to use you | as their injection point? | | Try this with msn.com. If you're connected to their network and submit a | message to the local smtp server using a "From" address that isn't an msn.com | address, they'll *silently* discard your mail. They'll accept it, and without | warning deposit it into a bitbucket. (This was the case several months ago. | They may have wised up since, but I doubt it.) I've heard that other ISPs are | requiring that the envelope sender domain be one of their domains in order for | you to be able to relay, thus making them unusable as relays if you use a | different address. At one point (and this may have changed), ibm.net would give | you a "550: Unauthorized access" as soon as it saw a MAIL FROM with a | non-ibm.net address. Are you talking about envelope sender or From line? They don't need to be the same at all. For most purposes, getting the From line right should satisfy your virtual domain users. I know they don't have to be the same, but I don't know of any non-Unix MUA that knows that. You stick your e-mail address in the appropriate blank, and the MUA creates the envelope sender and From line from it. I've never seen an MUA that allowed you to specify a different envelope sender, and even if they did allow such a thing I'd hate to have to explain that concept to someone. Chris
Re: need some spam/relay help
Chris Johnson [EMAIL PROTECTED] writes: | On Fri, Feb 19, 1999 at 12:45:06PM -0500, Scott Schwartz wrote: | The question arises, however, why those aol users don't just submit their | mail to aol's smtp server? Presumably an aol user, just like any person on | the internet, can submit a message to their local smtp server (for which they | are authenticated) with a "From:" line that has one of your virtual domains | in it (or indeed, any string they like). So why do aol users need to use you | as their injection point? | | Try this with msn.com. If you're connected to their network and submit a | message to the local smtp server using a "From" address that isn't an msn.com | address, they'll *silently* discard your mail. They'll accept it, and without | warning deposit it into a bitbucket. (This was the case several months ago. | They may have wised up since, but I doubt it.) I've heard that other ISPs are | requiring that the envelope sender domain be one of their domains in order for | you to be able to relay, thus making them unusable as relays if you use a | different address. At one point (and this may have changed), ibm.net would give | you a "550: Unauthorized access" as soon as it saw a MAIL FROM with a | non-ibm.net address. Are you talking about envelope sender or From line? They don't need to be the same at all. For most purposes, getting the From line right should satisfy your virtual domain users. | I don't recommend that anyone run an open relay and I'll continue to tell | people not to and to refer them to FAQ 5.4, but I'm becoming increasingly | sympathetic to people who think they need to. Whether the problem can be fixed | without some kind of username/password authentication in SMTP I don't know, but | I think it's something worth talking about. Probably the easiest solution is an applet on the PC that tunnels 127.0.0.1:25 to a private smtp or qmtp server on the mail host, doing authentication in the process. SMOP. Wasn't there a usenix paper about this a while back?
