Koozali.org: home of the SME Server
Legacy Forums => Experienced User Forum => Topic started by: Joseph on March 27, 2003, 05:23:44 AM
-
I has been testing and started to use the SME server for my company's primary email server until I found out that users couldn't check their emails from outside (I.E. over the internet).
Does ANYONE know how I can set the SME server up so that users can send SMTP from the internet without opening email server up as an open relay AND not using secure email????? All emails have to be over SMTP/POP/IMAP as that is the only protocals my users will be able to connect with.
Thanks in advance for your help.
Regards,
Joseph
-
Joseph,
Sound like you have 2 different issues from your post?
1. Check external email accounts.
2. Send email using the SME for SMTP from external clients.
Is that right?
Cyrus Bharda
-
Actually,
The the external clients can login using both POP and IMAP fine and retrieve their email, just as SME is designed to do. The issue is send email using SMTP for external clients that login via the internet using SMTP/IMAP. I know there is a contrib to use Secure SMTP but for my users it's unacceptable just as it's unacceptable for me to run an "open" email server.
Outside of this simple issue, I haven't had and problems with SME at all and found the contribs and forums EXTREMELY helpful in solving problems. It is just on SME's ability to send SMTP email from external clients is a wall I am running into and the HowTo of "SME can't do it" seems a bit harsh as if I can find a solution, I will be force to find a diff product. :-/
thanks for any insight you can give me on how to do this!
-
Hmmmm sorry I have no idea then :-(
Cyrus Bharda
-
Joseph wrote:
>
> The the external clients can login using both POP and IMAP
> fine and retrieve their email, just as SME is designed to
> do. The issue is send email using SMTP for external clients
> that login via the internet using SMTP/IMAP. I know there is
> a contrib to use Secure SMTP but for my users it's
> unacceptable just as it's unacceptable for me to run an
> "open" email server.
I applaud the fact that you don't want to use the SME server as an open relay. Presumably, your external clients are using an ISP of some sort. Is there some reason why they cannot use the smtp server of that isp to send their outgoing mail?
Mike
-
Um...yes...users cant send the emails thru their ISP (Earthlink for example) as then my users would be trying to relay their SME hosted, company emails thru their ISP which any ISP worth their grain of salt will not allow to happen. ANd I know in fact, Earthlink won't let the emails be sent thru and Earthlink SMTP connection (I tried it).
Doesn't it make sense to send emails thru the email server (SMTP) in which the email was received from (POP3)???? Seems like a bit of a flaw in design when users can check email but not reply to them as is the case when users check their SME hosted emails from the Internet. :-/
-
Hmmmm I have 5 email addresses at home, all of which use my ISP's SMTP server to send, and funnily enough none are the actual email that I got from them! This is not relaying as a good ISP's SMTP should accept ALL requests from the IP's that that company owns, because they are "authorised" IP's it is not considered relaying, well at least that's wat the have told me.
But I do not know what Earthlink's policy's are but it does sound strange that you would not be able to use their SMTP servers when you are connected with them?!?!
Cyrus Bharda
-
Have your users use your SME's webmail.
If that doesn't work for them, have them set up a new account within Outlook (if they're using something else make changes as needed), with the pop3 account as your server, with the smtp server as their ISP, make sure the email they use is the SME (company) email addy, with the ISP's smtp server. I don't see why this is such a proplem and why people don't figure it out on thier own.
I have users using both senarios, ones that only use webmail cause they don't want to explain the differences to the end user and users with employess that can understand setting up the differences. You'll need to understand your customers users then implement the right course of action.
-
I surely thank you all for the help and guidance on this issue, but the only answers to my question/issue is hacks/and semi-work arounds. Which surely is not a knock on the advice that this thread has generated or anything else I read in other threads, rather, it would seem an inherent limitation to SME: the inability to send SMTP emails from external clients that have been autheticated regardless of encryption technique. All of the advice I have gotten has been TRUELY valuded that is for sure!
With SME it would seem as it is all or none, meaning, all external SMTP email traffic must be sent over SSL or SME won't send the mail, regardless of user account authentication. What seems like a simple feature, the ability for external clients to login, authenticate and send emails from the Internet using standard SMTP while NOT relaying for non-authenticated accounts or foriegn domains, SME wasn't designed to do. Seems like they assume that ANYONE outside of firewall is a spammer or else they would connect securely. In my case that is not true. The correct answer would be for SME to allow relaying ONLY for authenticated users and/or local domains using SMTP *like other email servers I have used*
Please if someone ever figures out how to actually allow SME 5.6 to send emails for authenticated external clients using standard SMTP, PLEASE let me know.
In mean time, I guess I am going back to Ipswitch's IMail on Win2K as my companies email server. >:-(((
Thanks for your help!
-
You wrote:
> Um...yes...users cant send the emails thru their ISP (Earthlink for example)
> as then my users would be trying to relay their SME hosted, company emails
> thru their ISP which any ISP worth their grain of salt will not allow to happen.
No, that's not right. They're not interested in forcing their users to use
only their Earthlink email addresses; they only care about making sure
that only Earthlink users can use the server to relay, regardless of what
email address those Earthlink users use in the headers of their messages.
If they connect to Earthlink's SMTP server from an Earthlink address, it
should let their mail through regardless of the contents of the header.
That's how relay controls work on normal systems (including SME
Server, by the way -- see /etc/tcprules/tcp.smtp for the per-IP-address
relay rules used by smtpfront).
If Earthlink is refusing their mail despite them sending it through the SMTP
server that Earthlink told them to use, they need to contact Earthlink
technical support. They're one of the more clueful ISPs, and I'm positive
that their SMTP servers operate in the expected fashion.
Cheers,
--Rich
-
Rich...thanks for the advice...but I want my users to send their email thru MY email server...not their own personal ISP's.
-
Well, you're always welcome to have your users do whatever you want
them to do, but it seemed to me that you didn't want to have to use
Win2k to do it.
After all, it's becoming more and more common for ISPs to completely block
port 25 outbound from their dialups. Authenticated SMTP doesn't do much
good when you can't get there to authenticate. That's *why* ISPs provide
SMTP smarthosts for their users.
Cheers,
--Rich
-
Joseph,
Could you use POP before SMTP auth maybe? And dont count this thread dead just because only two people have responded, wait till people in the USA wake up and you might get other opinions or ideas :-)
Other than that I am in agreement with Rich, I do not see the huge problem with letting clients use there own ISP's SMTP servers, how would the reciever know the difference between SME relayed SMTP and thier ISP's SMTP anyway?
And why should it bother the client, just as long as the email just through then they should be happy!
Cyrus Bharda
-
Cyrus...I agree....and would not like to give up so easy on SME as other then this issue I am really happy with it. Problem is I have until tomorrow morning to get the emails working for the Presidents of two seperate companies that have TIGHT deadlines and NEED to send emails thru my server as they use AOL to dialup and are currently in California *I'm on east coast*.
When you wrote "Could you use POP before SMTP auth maybe?" What does that mean?
Basically I have to users that dial in to smelly AOL, fire up Outlook and try to send emails using it as a client. I agree the person that wrote that it's possible, that normally with an ISP like Earthlink, to send it thru their ISP by using it as a SmartHost (?). The question is: how the heck to I set it all up prior to tomorrow morning?!?!
I have to agree with Rich that I rather NOT use Win2K as OS for my email server, but as I am not as literate with Linux as I am with Windows, I dont have time to jerk around at command line to add new accounts and domains as I am not that familuar with configuring SMTP/POP at command line. That was part allure of SME server...the web based management screen for users/domains. Minus that, while I rather nor use Windows, it's a matter of time allocation and ease of use.
-
You wrote:
> I agree the person that wrote that it's possible, that normally with an ISP
> like Earthlink, to send it thru their ISP by using it as a SmartHost (?).
> The question is: how the heck to I set it all up prior to tomorrow
> morning?!?!
A smarthost is just an SMTP server designed to take email in one end and
send it out the other -- the "outgoing" part of an ISP's mail server, in other
words.
For tomorrow morning: Find out the address that the user's ISP wants them
to use for an SMTP server. Put it in their mail client (even though the From:
address still contains your domain). You're done!
This looks helpful, although I can't vouch for accuracy:
http://www.bruceb.com/isp.htm
Cheers,
--Rich
-
Rick....thanks for the short term solution as it looks like it should work for now. I will do as you as say as you seem to know more about this then I do. :-) In the long run, i dont know if your suggestions are a true "solution" to my problem. I prefer all outside users to use WebMail to check email, but those pesky bosses and sales persons on the road like Outlook as they can sync emails with their Blackberrys/Palm Pilots and are hard to get them to change.
Again, thanks to all that gave me advice tonight/this morning!
~Joseph
-
I have the same problem... But my clients using only two locations with known IP adresses. If this is the same in your case, just put those (say safe) IPs into the Loacl Networks - leaving ROUTER BLANK. Users from those IP range will be granted to send mails using SMTP !!!
Cheers,
Andrej
-
Hi Joseph,
I'm a little surprised no one aside from Cyrus has brought this up after all this discussion. Unfortunately Cyrus appears to have missed out giving you the link :-
http://www.stickit.nu/pop-before-smtp/
Kelvin
-
Nathan's pop-before-smtp does not work with mailfront, so it only works on SME 5.1.2 and older. Mailfront doesn't use the smtpd_check_rules file that the script modifies to allow access. The script still works fine, but the changes made by the script aren't seen by the new mail program.
Damien's SASL contrib *does* have the option to allow authorized SMTP without SSL. I can't vouch that it works in that setup, but it's great over SSL. http://www.pagefault.org/code/e-smith.shtml#securemail
-
Joseph wrote:
>
> Rick....thanks for the short term solution as it looks like
> it should work for now. I will do as you as say as you seem
> to know more about this then I do. :-) In the long run, i
> dont know if your suggestions are a true "solution" to my
> problem. I prefer all outside users to use WebMail to check
> email, but those pesky bosses and sales persons on the road
> like Outlook as they can sync emails with their
> Blackberrys/Palm Pilots and are hard to get them to change.
Joseph,
Preventing an open relay requires restriction of those permitted to use the smtp server. There's just no getting around that fact. These external clients of yours are paying an ISP good money for several services, including a pipe to the internet and an outgoing mail server. That is what it's there for. So far, I've only had one ISP check the return address of outgoing mail, and suffice it to say that I'm no longer one of their customers.
If, for some reason I cannot fathom beyond braindead ISPs, your clients _must_ use your server as their smtp server, then I would suggest the only secure way that can be done is a VPN. Either that, or they use Webmail while out of the office.
Using the ISP's mail server is, IMHO, the proper solution.
Mike
-
> Nathan's pop-before-smtp does not work with mailfront
Oops ! My mistake (been around 5.1.2 too long !).
Kelvin
-
Michael Soulier wrote:
>
> If, for some reason I cannot fathom beyond braindead ISPs,
> your clients _must_ use your server as their smtp server,
> then I would suggest the only secure way that can be done is
> a VPN. Either that, or they use Webmail while out of the
> office.
It's a pain to use the ISP's SMTP server, especially for people who move around a lot and use several ISPs. For relatively clueless users, having to monkey with SMTP settings is nearly impossible.
SME is a very capable server on which you already have an account. Why not use its SMTP server anywhere on earth you happen to be?
Unless there's some sort of bug with Damien's contrib (highly unlikely, but I haven't tried it myself), http://forums.contribs.org/index.php?topic=16934.msg65600#msg65600 contains the solution. Users just have to check the "My server requires authentication" box, and you have SMTP access for all of your accounts without opening it up to any unauthorized users.
-
Joseph,
I am not sure why you do not want to use the "securemail" package. As explained by Bill Talcott, you do not have to use SSL, and it still allows authenticated users to send email from your server using SMTP.
I have users in Australia, that have ISP's ranging from Telstra BigPond (Australia's largest ISP) to many small regional ISP's as well as some Australian AOL users. They all authenticate against my server (without SSL) and send/receive emails.
Having said that, I have one user who uses my server for incoming mail (POP), but uses his ISP (iPrimus) for sending (SMTP), Like other users have discussed, all he does is change his reply address to the account on my server, rather than email address provided by his ISP.
Hope you get it sorted.
James
-
Just out of curiosity,
"you don't have to use SSL"...
I didn't see this mentioned on the website (url in a previous post). Bearing in mind that I haven't instlled the RPM's yet, does this mean that it supports SMTP AUTH? is it in Plain mode? Given the multitude of email clients (some of which either don't support SSL or it's flaky), the least common denominator (and still providing "some" protection) would be plain AUTH.
I'm surprised that no-one has posted an rpm with a patch to support this yet. I've only seen source code patches (which require that I install dev tools on my server).
I'd like to get a bit more info before mucking around on my server...
Thanks,
Steve
-
Steve Crowers wrote:
>
> Just out of curiosity,
>
> "you don't have to use SSL"...
>
> I didn't see this mentioned on the website (url in a previous
> post). Bearing in mind that I haven't instlled the RPM's
> yet, does this mean that it supports SMTP AUTH? is it in
> Plain mode? Given the multitude of email clients (some of
> which either don't support SSL or it's flaky), the least
> common denominator (and still providing "some" protection)
> would be plain AUTH.
>
> I'm surprised that no-one has posted an rpm with a patch to
> support this yet. I've only seen source code patches (which
> require that I install dev tools on my server).
>
> I'd like to get a bit more info before mucking around on my
> server...
http://www.pagefault.org/code/e-smith.shtml#securemail
----------------------------------------
* Sat Jan 04 2003 Damien Curtain
- Include seperate ssmtpfront-qmail variables.
- SASL can now be set either on smtp or ssmtp or both.
----------------------------------------
Just install the RPMs, choose the options in Server Manager, and it works. That's all there is to it. There are instructions after each file's section. You can just install the RPMs, then issue a single "/sbin/e-smith/signal-event post-upgrade", rather than doing it after each file (to save time).
Remember that non-SSL email is sent plaintext over the internet. Whenever possible, you should use the secure versions so that your password is encrypted.