Graham - did you get this resolved? (OK, this is updated, I re-read the
thread in its entirety, more comments follow surrounded by [brackets]
Near as I could tell -
your smtp email service got rehomed to a different email provider, yes?
[na - your client got their service rehomed elsewhere]
You'll need a valid user name and password for a valid
account on that new box.
[this isn't a 'new box', per se, but the new service provider has not set
up any valid email user accounts. They need to do so. Ask for a new
account via your client, use it for testing. Ask for another email
account as well, to use for production (when you have finished with your
testing) . ]
If you don't have that, then anything you use in your old, unedited, code,
will 'seem' to push to your current internet connection provider as 'relay
mail' - and if you haven't sent up a relay mail account, all outbound will
get tossed, error messages vary.
Here's what you said on the first post -
"I've just inherited an ASP.NET (c#) app. The customer has just moved the
hosting and now it won't send emails. There are no obvious error messages,
it seems to go through but the emails never arrive. The code hasn't changed
and I can't see anywhere the application is sending any sort of
authentication. It just uses the standard built in SMTMail object.
My guess is that the new hosts have their mailserver locked down to prevent
spam but I don't know, and of course the new webhosts have washed their
hands of it!!
Could anyone point me in the general direction of any troubleshooting guides
or give me any sort of pointers?"
[i learned pop3/smtp from the linux source code and the man sections.
It's painful - I can't recommend any one else to do that. However - Blat
emulates a lot of the functionality - but - you aren't using blat - you
are encapsulating something else in a C# program that resides on a web
instance in a web farm, yes? ]
I can't point you to 'a guide' - as I've soaked up this minutiae like a
sponge.
But -
lets throw around some terms a bit - you ask around on the admin staff and
see what you can co-relate with/on, ah?
1. Internet Connection Provider - the company that provides your company
with an internet connection at your office. This could be DSL,
Broadband/cable-modem, T1, fractional T1, ISDN or *gasp* dial up.
Which is it for your company site?
[lets assume it doesn't matter, as your email component that you are
editing is supposed to reside on a server, and is really a
server-component to send email. ]
2. Email Service Provider - The entity that handles both smtp and pop3
email services between your computer and the internet. May, or may not
be, the same as item 3. May or may not require user authentication.
Depends on the settings, depends on the connection, depends on physical
connection type (see #1 for the list) .
[you mentioned 'localhost' in a subsequent post. EEK. ok - even with
'localhost' - you need a valid email account, username and password].
3. Web Hosting Company - The entity that hosts your company's web space.
May or may not provide SMTP / POP3 email servers .
Now - with these defs set down - and with your PRIOR codebase - which
entity did this codebase send mail to ? Where in the codebase did the smtp
settings 'get set' ? Gimme some code, obfuscate the hostname and the
password.
I swear - if I were using VFP instead of C#, I'd store the pop3/smtp info
into a table, and evaluate everyhing at run time.
Hoping this finds you well, and well rested!!!
Mondo Regards [Bill]
--
William Sanders / efGroup {rmv the DOT BOB to reply}
VFP Webhosting? You BET! -> http://efgroup.net/vfpwebhosting
Failing dotNet Project? -> http://www.dotnetconversions.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
