Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Spam

How Should You Handle Remote SMTP Users? 17

Posted by Cliff from the filtering-spam-not-friendly-signals dept.
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?"
This discussion has been archived. No new comments can be posted.

How Should You Handle Remote SMTP Users? More

How Should You Handle Remote SMTP Users?

Comments Filter:
  • How are you going to differentiate between a legitimate user on a dialup and a spammer on a dialup? Add an AI to sendmail that looks for spam-like content?

    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.

  • Well, I cannot give you actual code or configuration files, but here are some ways others are doing it:

    • Yahoo!Mail [yahoo.com] uses POP authentication for SMTP, and mandates that your e-mail must be the Yahoo mail. This works OK, but the problem is that I am behind a corporate firewall that block POP, which means that I cannot use SMTP as a result.
    • My hosting provider allows SMTP from my domain [2bits.com], but only from a predefined set of IP Addresses and/or IP Address ranges. They do this because of the ORB RBL mentioned in the article. This works well from the office and from home, but is annoying when I travel, since I have to check what IP subnet I am using and send it to my host, ...etc.

  • You really do want some kind of authentication when relaying for machines not on your network.
    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.
  • My web provider is using a mechanism involving wtmp. I don't know the details and I haven't used it yet. They say that if you log in to a shell or ftp then the IP you logged in from will be able to relay mail for a limited time. Presumably they're using some home made script to manage the relay list dynamically.

    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.
  • Exactly correct. This works easily, if you can get your users savvy enough to do it.

    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).
  • I'm using Rockliffe Mailsite on (here it comes) NT. The most I seem to be able to do is only accept relay from people authenticated by email address, figuring yeah anyone could guess one of our addresses, but I think it's a line that many spammers wouldn't cross.
  • Sendmail is ancient. Stop using it.

    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 .username.pop and you'll kill your pop server.

    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.

  • I think it's a line that many spammers wouldn't cross.

    Ha, that's funny... that's a joke eh?

    -rt-

  • Re:why are you still using sendmail? (Score:3)

    by schnurble ( 16727 ) on Saturday April 29, 2000 @09:02AM (#1102708) Homepage
    At the risk of starting YAHW (yet another holy war).....

    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

  • And it's standard in every *NIX distribution I've seen (Slackware, redhat, debian, suse, and mandrake linux, solaris/sunos, etc etc.)

    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.

    -----

  • I have a similar problem. I have a few friends that want to remaind somewhat anonymous when sending mail. They don't want their school's IP to show up when sending mail. I volunteered to give them SMTP services but they aren't saavy enough to login via ssh to my box to use pine to send email. If they login, it will be via a free ISP, and allowing relaying from those domains opens a HUGE can of worms. Is there a way to limit "From" domains from the senders?
  • One of the recent decisions made by the tech team in our company was to make a it a requirement for our clients to get a static IP.

    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.

  • Yes, but that's not secure, since anyone can forge a From header (message or envelope). It might cut down on the amount of spam yourelay, but it won't keep you off ORBS.
    --
    The scalloped tatters of the King in Yellow must cover
    Yhtill forever. (R. W. Chambers, the King in Yellow)

  • Sendmail is ancient. Stop using it.

    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.

    If you control your remote users IPs, you don't have a problem with any MTA. If you don't, then qmail is not going to solve this problem (alone). I administer a site running qmail with a lot of virtualdomains, and since we don't provide dialup access, all of our users are remote on untrusted IP's. We're probably going to go to with the POP-before-SMTP method, which can be done with more-or-less any combination of MTA's with a little scripting. The right thing to do is not to relay if you're not a dialup or bandwidth provider, but for business reasons, that option's not available to us.
    --
    The scalloped tatters of the King in Yellow must cover
    Yhtill forever. (R. W. Chambers, the King in Yellow)
  • My hosting provider lets me retrieve my email via POP but any sending has to be done via my dial-up ISPs SMTP box. Surely this is a solution that you could work with. Leave the authenticating to the ISP which is probably already doing it anyway!

    Marty
  • >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.

    Erm... that's got nothing to do with sendmail. Why don't you switch to cucipop -- no temporary files at all :)

    ...MoO!
  • >>Also, don't use sendmail. It stores all of your >>emails in one big file.

    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] ... finally each "mailbox" is a collection of directories (i.e. folders) and files (i.e. messages). And the whole thing is easily accessible via IMAP or POP (though we are no longer using POP).

    Meanwhile the MTA is sendmail .....

Slashdot Top Deals

Trap full -- please empty.

Close