[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Julian Hall wrote: > Neil Stone wrote: >>> Kevin Bailey wrote: >>>>> aaron Moore wrote: >>>>> >>>>>> Hi all >>>>>> I have been using a web email (linuxmail.org) service for a >>> while with no probs. But I now want to down load my mail using >>> evolution, mozilla or some such. I have payed my subscription and >>> tried to make all the settings but I am unable to send mail from >>> said applications.... the server does not recognise by password. I >>> can recieive mail though. I have sent several plaintive mails to >>> Linuxmail but to no avail. Can anyone offer any suggestions. I am >>> using Suse 10.0 >>>>>> Thanx for any suggestions no matter how small >>>>>> Aaron >>>>>> >>>>>> >>>>>> >>>>> You probably need to use the SMTP server provided by your ISP: >>>>> >>>>> post.demon.co.uk or smtp.btconnect.com etc. >>>>> >>>>> kev >>>>> >>> You paid money for a service.. the ISP should help you out as much as >>> they can... if not, demand a refund. >>> >>> -- >>> Neil Stone >>> >>> Systems Administrator >>> FlashTek UK > Assuming they support Linux.[1] You cannot demand a refund for the > ISP failing to supply a service they didn't say they would. In my old > job we lost a lot of time (and in some cases customer goodwill) by > technicians arbitrarily supporting items they were not supposed to, > *and* had not been officially trained on. There are two problems with > that: > > 1. Assuming support is on a Premium Rate phone line, ICSTIS[2] > guidelines state that staff may only support what they have been > trained on. In actual fact that ruling itself was an extension of the > official line that staff may only support what they have *supplied*. > In our case that would have limited us to supporting our dialup > software supplied on CD - which for an ISP is laughable - so the > extension was agreed. > > That rule meant in essence that if anyone supported something we had > not been trained on, and ICSTIS had found out, we could have been shut > down until assurances were given it would not happen again. > > 2. Notwithstanding 1. above, even if the support is not Premium Rate > there are practical issues. Staff were not encouraged to give out > their extension numbers for several reasons: > > a: the incoming phone system was incapable of allowing the customer to > type in an extension anyway. > b: on a Premium Line it is a breach of the ICSTIS code to put a > customer on hold (which would have to be done to transfer the call) > c: in a shift based callcentre the person may not even be in for a > couple of days. > > That always left the poor sod who received the follow-up call with a > very irate customer that he/she was physically unable to help. > > We *did* offer 'Courtesy Support' on rare occasions to non-Premium > Rate customers, however the customer had to be told up-front it was > courtesy support, and that we could not, as a company, offer further > advice if the suggestion did not work: > > examples: > > a) Customer rings up using Evolution and wants the mail settings - No > problem at all - supported as the information is standard in all mail > clients. I actually gave techs a verbal thick ear if I monitored > calls and they refused to assist in simple calls like that. > b) Customer rings up using Evolution and wants to know how to > configure it with the mail settings - Unsupported as the information > is specific to that mail client which the technician had not been > trained on. *IF* the tech knew Evolution inside out and *advised the > customer it was personal advice*, then a blind eye was turned if it > was a non-Premium call. > > At the end of the day it helps neither customer nor support staff if > some well meaning person tries to support something off their own back > and it goes all wahoonie-shaped. > > [1] If they DO support Linux feel free to ignore the rest of this :) > [2] http://www.icstis.org.uk/ - Premium Rates Services Regulator > > Kind regards, > > Julian This may be the case but a few well thought about questions such as. 1) What is your SMTP server ? 2) on which port do i connect to your SMTP server ? 3) Do i need to provide login details to your SMTP server ? 4) if yes to 3, what details do i need to provide ? etc..etc.. Not rocket science really, if their advisors do not know this information they should not be in their job... - -- Neil Stone Systems Administrator FlashTek UK - -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT d+(++) s: a-(?) C++++(--) UL++++$ P+ L+++ E- W+++ N+ o+ w--- O M PS+ Y+ PGP++ t+ 5+ X+ R+ tv+ b- DI++ D+++ G e h--- r+++ y++++(**) - -----END GEEK CODE BLOCK----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE0mcgz3Av8JKgzxQRAoW1AJ9Q+3QAFK/X50fwOSIhwrUEdNP4JACeO5AC TOqty+cqtsqnH8uJTs5YGCc= =MqZz -----END PGP SIGNATURE----- -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html