>One additional consideration: to prevent spam mail servers worth using (i.e., they have hacking protection) will limit the number of emails being sent per time unit (typically day). To get around that requires signing up for a commercial email sender on a "plan". The more $$ plans allow custom domain sending, etc.
>

Not an issue for this application. It's a vertical for auto repair shops and they need to be able to email invoices and quotes right from the application. Not huge numbers, just normal business stuff, but out of the application instead of having save a file and then have the user go to their email and send it.

Tamar

>
>>>>>>>Thanks everyone for all the advice here. I finally was able to test my code yesterday using an email address hosted on Dreamhost (one I control, but wouldn't normally think to use for something like this). Once I filled in the right SMTP info, my original code worked and I've been able to move forward in giving my client what he needs.
>>>>>>
>>>>>>And what was the sticking point, i.e. the cause?
>>>>>
>>>>>I think just different ISP's rules. I needed to keep trying until I found an SMTP server to test with that didn't require some complicated extra steps in validating, but would let me sent with just the sender's log-in credentials.
>>>>>
>>>>>And yes, I'm aware this means that my client's customers may run into issues, but we'll cross that bridge when we come to it and with luck, IT people will get involved to set up what's needed to allow them to have the application send email.
>>>>>
>>>>>Tamar
>>>>
>>>>The problem is simple: You run a server on a static IP and are trusted: SMTP will run without credentials. The system trusts your serve, that the server cares about validation etc. But not on 25 and unprotected.
>>>>Or you are a "user" then you must validate against the system - some server providing your mail address.
>>>>
>>>>If anybody could spam any server with SMTP, it would be unbearable. The mail envelope is just some characters, the basic mail system trusts this information. abuse on a silver plate. So for that you must validate against the SMTP server - and the server will check that the envelope fits to your credentials.
>>>
>>>But what started me down this path was that even on an appropriate port and with credentials, the SMTP server for my primary email wouldn't let me send this way. It wanted some much more serious authentication than just sending the right credentials.
>>>
>>>We'll see how much of an issue stuff like that is for the client's customers. (The app is a vertical.)
>>>
>>>Tamar
>>
>>Hi Tamar,
>>
>>Now I'm confused
>>> ... the SMTP server for my primary email wouldn't let me send this way. ...
>>This is The SMTP server for my primary email wouldn't receive this way ?
>>
>>> It wanted some much more serious authentication than just sending the right credentials.
>>
>>Sure, that's what I would expect. just sending the right credentials sounds to much like open communication. Encrypted is standard, and a normal server will not accept open communication for ages. And encryption needs a bit more work.
>>
>>You must allow all (combinations of) settings that for example Thunderbird allows for outgoing mail. You never know how the customers (remote) e mail server is set up. There is no standard. Each server / ISP has it's own combination, sometimes none standard ports. Some might run a local server, what might have different requirements. But a sane admin would set up encryption there as well.
>>To say it the other way around, you must create an interface like Thunderbird or whatever for the settings you need for the (remote) SMTP server, and set up connection according to this settings. Customer must set this up.
>>And you constantly need to watch for security problems there and for the tools you use to open communication. Much fun storing the credentials, watch for GDRP issues.