SMTP server name for a Python script?

[webber]

Is there a security measure preventing Python scripts from sending email?

A tutorial for sending email with Python is here:
http://www.eskimo.com/~jet/python/ex...ail/smtp1.html

The script at the end of this post uses the function given here:
http://www.eskimo.com/~jet/python/ex...simple_mail.py

The script works on my local machine using my ISP's mail server.

It doesn't work from my Page-Zone account with either of the last two mail server names in the script.

Why do I think that the last two server names might work in the script? Because they work to varying degrees in my email program.

The "MyDomain.com" server accepts the password from my email program, but my email program complains about a mismatch between the domain name and the name in the certificate. I wouldn't expect that to be an issue when the script resides on the same server.

I can send messages from my email program via the "southbend-xx.pgzn.com" server. But it doesn't work in the script below.

Nor does "mail.MyDomain.com".

Why do I care?

Because I am trying to set up GypsyMail on my site. GypsyMail is written in Python.

It is available here:
http://www.thinkspot.net/sheila/stat...page=gypsymail

I got it to work on my local machine -- using my ISP's mail server.

I seem to be stuck at the step of telling it what SMTP server name to use when it resides on my site at Page-Zone.

Please help me to get the script below -- and GypsyMail -- working when they reside on my site.

Thanks,
Webber

==========
import smtplib

# this works from my local machine
SMTPhost = "mail.MyISP.com"

# none of these work from my Page-Zone account
# SMTPhost = "mail.MyDomain.com"
# SMTPhost = "MyDomain.com"
# SMTPhost = "southbend-xx.pgzn.com"

from_email = "from@MyDomain.com"
to_email = "me@MyDomain.com"
subj = "Hello"
msg = "World"

def mail(serverURL=None, sender='', to='', subject='', text=''):
"""
Usage:
mail('somemailserver.com', 'me@example.com', 'someone@example.com', 'test', 'This is a test')
"""
headers = "From: %s\r\nTo: %s\r\nSubject: %s\r\n\r\n" % (sender, to, subject)
message = headers + text
mailServer = smtplib.SMTP(serverURL)
mailServer.sendmail(sender, to, message)
mailServer.quit()


mail(SMTPhost, from_email, to_email, subj, msg)
==========

[midwest]

I dont do python, I hate being controlled by indentation. But have you tried 'localhost'?

.

[cmyksteve]

I have only a couple Joomla accounts that will send mail via SMTP. Using PHPmail and sendmail seems to work on all. In my case, I've suspected SMTP w/authorization is being blocked by default.

[webber]

Thanks for the replies.

I tried "localhost" based on the suggestion. It doesn't seem to work either.

I am not as encouraged by finding four ways the didn't work as Edison was about finding a thousand.

In light of later findings (discussed at length after an aside), I am abandoning this issue for the moment.

I'm with you here:

I don't do python, I hate being controlled by indentation.

It's one of the biggest drawbacks of the language.

I usually use perl or PHP for that reason -- in spite of the added complications of $-prefixed variables and semicolon-terminated lines.

What was wrong with BASIC?! I think that much has been lost in exchange for the snob-appeal of C-like languages.

Python did away with some complications, but they turned white-space into a structural element! What were they thinking?!


More about why I am abandoning the question about SMTP in Python for the moment:

I spent about a day trying to get GypsyMail to work. The flexibility that it offers is enticing. This report about cgiemail pushed me over the edge to try to switch to GypsyMail:
===
http://groups.google.com/group/comp....1b825aa893c617
---
This exploit works on ANY cgiemail form where any of the form fields
are reproduced in ANY header of the template file.
===

Unlike cgiemail: GypsyMail seems to be in active development, it is written in what I find to be an easier language than C, and the program isn't so large as to be odious to tweak if necessary. Plus, this is something that sounds like it has great appeal to me (though I haven't actually gotten far enough in testing to see whether it does what I want it to do):
======
http://www.thinkspot.net/sheila/stat...page=gypsymail
--------
Several "Success Page" options, including ... options for including parts of the sent email and/or form data
======

After being stymied in getting GypsyMail to work, I tried to see whether cgiemail is, in fact, as vulnerable as the old newsgroup posting suggests. Somehow, it wasn't. It appears that Page-Zone is on top of keeping cgiemail from becoming trouble.

Given the number of message forms submitted on my site so far, it isn't worth as much effort as I have put into it to improve on the drab "success" page emitted by cgiemail. I'm not happy that cgiemail reports the username for my account in error messages, but perhaps that isn't a huge problem.

Though it seems preferable in many ways, I don't know what, if any, kind of mischief GypsyMail is vulnerable to. I am not anxious to risk having my account turned off by finding out.

Thanks for your interest,
Webber

[midwest]

That day you spent mucking around with gypsymail you could of wrote your own. Just exactly what you needed and left the kitchen sink where it belonged.

The purists that stick to strict indentation so as to try reading some code requires repeated L-R scrolling really PO me. A trick I learned is to replace all tabs with a single space, it helps some. But python, I hated from the start. I will revisit it in a while again. I was a perlhead for years and did not really like php much but V4 got better and I decided to use it for a script and found I liked it.

One thing in C,C++ favor is this, it is not really very hard to learn the basics. Learning to make a GUI and tie the code in is the challenge. For web use a small C/C++ app is extremely fast. Lots of large busy sites use small C/C++ apps to get things done.

Basic???
The main reason is it lacked functionality to match the hardware growth as well as apps got larger and numbered lines just kinda started to suck.

I've been playing around with AJAX and using php for the server-side work. Interesting stuff.

[webber]

One thing in C,C++ favor is this, it is not really very hard to learn the basics.

Five things that suck about C:
1. Semicolon-terminated lines.
2. Case-sensitive variable names -- discussed below.
3. Pointers. Passing things by reference in a high-level language shouldn't require me to care about pointers.
4. String space must be known ahead of time. True BASIC accommodates strings up to 4 gigabytes long without my having to worry about telling the compiler how long a string array needs to be. C wastes space if I don't need it and can misbehave severely if I try to store a string that is "too long".
5. Null-terminated strings. BASIC's string functions work just fine with binary data. C's are stymied by binary data that contains a NULL.

Why to avoid case-sensitivity when possible:
It took me a while to see the difference between the URL here and the link it contains:
http://en.wikipedia.org/wiki/BlackBerry
For the fruit, see Blackberry

The difference is obvious once it is noticed (and proximity in the excerpt above makes the difference more obvious than it is on the web page). But who looks for such a subtle difference in the location where it occurs in this example?

Avoiding logic errors in coding is difficult enough. Why multiply bugs or create confusion with case-sensitivity? I prefer to read words, not characters.

Basic???
The main reason is it lacked functionality to match the hardware growth

Past-tense -- "lacked".

Most hardware growth is irrelevant to me anyway. I am usually trying to manipulate data, not hardware.

If hardware (or the operating system) is not backward compatible, then that is a platform problem -- not a failing of the language.

Why should I willingly adopt Vista and forego the use of any of the DOS programs which have served me well for years?

as well as apps got larger and numbered lines just kinda started to suck.

Modern BASICs don't require line numbers.

My favorite is True BASIC.

http://www.truebasic.com/

That dialect is from "the horse's mouth" -- the original inventors of BASIC.

Unhappily, they made the marketing decision to cripple all but their most expensive version to prevent access to the Windows API or assembly language.

I still use their DOS version for as many things as I can -- it is stellar.

If I need to talk to the Windows API, I use Rapidq -- a free version which was created by a student in college several years ago. It may be hard to find now that RealBASIC bought the source code for Rapidq.

I've been playing around with AJAX and using php for the server-side work. Interesting stuff.

I am generally opposed to client-side scripting.

I have been to too many sites with broken javascript.

Unless I am inspired to tell the webmaster that his javascript doesn't work in my browser, he is clueless that anything went wrong when I tried to visit his site. If I do tell him, he might say "You should upgrade your browser." Wrong answer!

An even worse answer when a site is designed to work only with one browser: "You should use (the latest version of) my browser."

I usually just go away and find someone who will talk to me in a way that my browser understands -- preferably without javascript or rafts of images. I still make frequent use of a dial-up connection. I have little patience for extraneous images -- or navigation menus which are useless without them.

That some sites require Flash for something as basic as navigation is incomprehensible to me: "We will talk to you only if you turn on your Flash player." Ditto ActiveX -- why would I want to let just anyone run ActiveX on my system?!

If my perl or PHP is so broken that it issues an "Internal Server Error" message, I can know about that without relying on the kindness of a visitor to tell me about it.

My opinion: If a designer thinks that scripting is necessary, then they can spend their own CPU cycles to make it happen -- and experience any broken coding first-hand.

Is the script doing something so fancy that the server's CPU wouldn't actually incur less load by running a tighter script locally instead of doing all the handshaking and bandwidth-consumption involved in spewing 100 kilobytes of supposedly-multi-browser-compatible javascript?

If the script isn't worth spending their own CPU cycles on, then why is it worth 1) my bandwidth to download the script, 2) any of my CPU cycles to run it [my machine might be doing other things besides talking to them], or 3) my frustration if it doesn't work?

Webber