Just so I understood clearly, if I turn on SMTP AUTH and have the "treat authenticated IPs as local hosts" turned off, will that likely help secure the possibility that this SIMS box could be used as a relay?
Thanks, Chris > From: Dan Brotsky <[EMAIL PROTECTED]> > Reply-To: "SIMS Discussions" <[EMAIL PROTECTED]> > Date: Wed, 26 Feb 2003 09:57:43 -0800 > To: "SIMS Discussions" <[EMAIL PROTECTED]> > Subject: Re: APOP. > > Chris, > > There are two parallel systems in play, here, each with its own > protocol, and each systems protocol provides for authentication. The > analogy is as follows: > > SMTP (Simple Mail Transport Protocol) > used: for sending messages, either from a mail client to a mail server, > or from one mail server to another (the latter is called a "relay"). > alternate protocols commonly in use for this: none > authentication mechanism: SMTP AUTH (allows both clear-text and > encrypted passwords) > most common default authentication policy: not required (that is, > senders are not required to authenticate by the receiving server) > > POP (Post Office Protocol) > used: by mail clients (e.g., Eudora) for retrieving messages from a > mail server > alternate protocols commonly in use for this: IMAP, but SIMS doesn't > support IMAP > authentication mechanism: POP authentication (clear text password), > APOP (hashed password) > most common default authentication policy: required (that is, clients > must authenticate before they can retrieve mail) > > Notice that it's common for mail servers NOT to require authentication > before they will receive messages. But a mail server that will receive > from anyone AND will relay messages (send them on to other mail > servers) as needed is what's called an OPEN RELAY: it can be used by > spammers to send messages to anyone. To avoid being an open relay, > most mailservers will receive from anyone BUT they will only relay > messages that come from known senders (senders they trust). > > So the trick for SIMS (and most mail servers) is to figure out who's > sending a message WITHOUT requiring them to authenticate. There are > three common mechanisms used for this: > > 1. only relay messages that come from a known IP address (i.e., a known > machine). This is what SIMS means by "Only relay from Clients Hosts": > the client hosts list are the trusted machines. > > 2. only relay messages where the sender has, in fact, used the > (optional) SMTP AUTH mechanism to authenticate themselves. SIMS does > this, too. In fact, almost all mail servers do, but until fairly > recently (say a three years ago) there weren't that many mail client > programs which knew how to do this. Now they pretty much all do, so > this is increasingly the mechanism of choice for servers whose clients > move around (i.e., do not use only known hosts). > > 3. (the hack) only relay messages that come from an IP address which > has "recently" used POP authentication to retrieve messages. This hack > is enabled by the fact that SIMS runs both a POP service (so users can > retrieve messages) and an SMTP service (so users can send messages). > Since all clients authenticate themselves when retrieving messages, and > since most machines (these days) only have one user at a time, and > since it takes a few minutes for someone to log out and someone else to > log in, it's almost safe for a mail server to assume that any machine > that has retrieved mail using POP and then immediately (within, say, 15 > seconds) sends mail using SMTP probably is still being used by the > known POP user. Thus SIMS can be configured to "temporarily" (for up > to 10 minutes) add hosts which have authenticated using POP to the > known clients list. > > If your users have modern mail clients, then you can tell them all to > turn on STMP authentication. This will allow them to send mail through > your SIMS server from anywhere. > > If your users have older mail clients, then you can tell them to always > do "fetch mail" right before "send queued messages" (Eudora actually > does this in that order; that is, it does receive then send), and turn > on the "hack" in SIMS. > > The effect of both techniques is the same, but the first one doesn't > allow for the strange timing glitch that comes from using Microsoft > mailers (which send before they receive). > > dan > > On Wednesday, February 26, 2003, at 09:02 AM, Chris Wagner wrote: > >> Christopher, >> >> Exactly what is SMTP AUTH? >> >> Is that something similar to APOP but done with the SMTP module? >> >> I guess I need to see how that would be an advantage. >> >> Also, if I required that all our local clients to use SMTP AUTH, would >> that >> setting also work for them on a remote basis? >> >> I mean, can they go home and still check and send mail using the SIMS >> box? >> >> And exactly how does SIMS approach the transaction between the two to >> allow >> permission? >> >> Thanks, >> >> Chris >> >>> From: Global Homes Webmaster <[EMAIL PROTECTED]> >>> Reply-To: "SIMS Discussions" <[EMAIL PROTECTED]> >>> Date: Tue, 25 Feb 2003 14:09:49 -0800 >>> To: "SIMS Discussions" <[EMAIL PROTECTED]> >>> Subject: Re: APOP. >>> >>> On 02/25/03 at 15:41, Chris Wagner opined: >>> >>>> Trying to figure out a better way to allow remote users to use their >>>> mailboxes for a reasonably longer time period you can set SIMS up to >>>> "treat authenticated IPs as client host". >>> >>> Do you mean you want to extend the time that a user can send via SMTP >>> after >>> they've authenticated a POP session? For that, there are only the >>> options >>> in the corresponding menu in SIMS' SMTP settings, ranging from >>> 'never' to >>> 10 minutes. But POP-before-send is a band-aid to begin with. Better >>> to use >>> SMTP AUTH if your mail client supports it. Then there is no time >>> limit for >>> sending via SMTP after authenticating to the POP server. >>> >>>> I guess my question is this: >>>> >>>> How much more secure (or is it more secure) / less of a relay >>>> opportunity to setup APOP? >>> >>> APOP only makes POP password exchanges more secure, since the >>> password is >>> hashed, as opposed to sending the password in clear text. It wouldn't >>> make >>> a difference in terms of SMTP relays from the client's IP address >>> once a >>> POP session has been authenticated. >>> >>>> At that point (running APOP for each box), would SIMS rely on the IP >>>> from the sender's network to verify against its client host list? >>> >>> Yes, the IP address of the sender is matched agains the client host >>> list. >>> If there's been an authenticated POP session from that host within the >>> configured time period, the host will be allowed to relay. This is >>> true >>> whether or not APOP is used. >>> >>>> If this is the case, then how can you work around this and not >>>> totally >>>> set yourself up as a relay? >>> >>> What are you trying to work around? The POP-before-send strategy, >>> using >>> APOP or not, is itself a work-around to block relays from unauthorized >>> hosts. It's not the best solution, but if you can't use SMTP AUTH, >>> it's >>> better than nothing. >>> >>> -- >>> Christopher Bort | [EMAIL PROTECTED] >>> Webmaster, Global Homes | [EMAIL PROTECTED] >>> <http://www.globalhomes.com/> >>> >>> ############################################################# >>> This message is sent to you because you are subscribed to >>> the mailing list <[EMAIL PROTECTED]>. >>> To unsubscribe, E-mail to: <[EMAIL PROTECTED]> >>> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> >>> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> >>> Send administrative queries to <[EMAIL PROTECTED]> >>> >> >> >> ############################################################# >> This message is sent to you because you are subscribed to >> the mailing list <[EMAIL PROTECTED]>. >> To unsubscribe, E-mail to: <[EMAIL PROTECTED]> >> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> >> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> >> Send administrative queries to <[EMAIL PROTECTED]> >> > > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list <[EMAIL PROTECTED]>. > To unsubscribe, E-mail to: <[EMAIL PROTECTED]> > To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> > To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> > Send administrative queries to <[EMAIL PROTECTED]> > ############################################################# This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
