On Wed, 28 Jul 2004 15:16:11 -0400 Tracy <[EMAIL PROTECTED]> wrote: > At 14:28 7/28/2004, Shiloh Jennings wrote: > >Personally, I think it is a better idea to require everybody to use SMTP > >AUTH to relay. Trusting IPs opens the door to a lot of relaying, > >especially when one of the PCs gets a virus on it. Even using POP > >before SMTP is a bad idea in my opinion because it is a form of IP > >based trusting. I've seen open proxy problems that allowed for > >relaying through machines via POP before SMTP. The user would > >check his email and the IP would be temporarily trusted by POP > >before SMTP, and then the open proxy would suddenly become a > >spam cannon. So personally, I think only allowing SMTP AUTH is the > >way to go. If somebody has an email client that won't support SMTP > >AUTH, convince then to upgrade to a version that does support SMTP > >AUTH. In my experience, trusting based on IP is just too risky. > > I agree with you that IP based trust schemes are not the most secure, > and > should only be considered in limited situations (such as the need for > automated reporting tools to be able to send mail from specific IP > addresses). > > However, I don't believe that SMTP AUTH is the full picture, either. > While > it is fairly secure (assuming that an encrypted connection method is > chosen > to send the credentials), it is still subject to abuse. For instance, > the > mail client typically stores the password used for SMTP AUTH somewhere > (it > may be a configuration file, or on Windows platforms it may be in the > registry). It would be fairly trivial for a malware author to put > together > a list of typical storage locations for the major mail clients and check > each of those locations to attempt to find the necessary password. > > SMTP AUTH does have flexibility that IP based trust schemes do not - > such > as the ability to allow users to travel to remote locations while still > sending mail through the same mail servers. But it's certainly not the > end-all-be-all for preventing abuse. Rate limiting and other protection > schemes are still needed.
With one exception. Using SMTP AUTH I know who's account to shut down for abuse without ever having to leave the mail log and cross reference a connection log. Especailly if the user is sending mail while connected via some other ISP or corportae network. If I get a spam report I can open the mail log and track the message ID right back to the [log-ID] [EMAIL PROTECTED] -- AUTHENTICATED line in the log and disable that account on the spot. The AUTHENTICATED marker always has the true local email account info for the sender. Doesn't matter what's in the "From:" or "Sender:" headers. Other auth methods (including SMTP after POP) don't directly relate the sending account to each individual message. The best you can do is have a look at the logs to see did a POP within the last "x" minutes and go check other spam messages to look for a pattern of "user Y always does a POP just before a spam burst goes out". Gerald - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
