Re: SMTP authentication misery

I'm just guessing here, so please feel free to slap/--/throw-a-brick-at me.

Looking at the dump, the "plain" password doesn't look plain to me. If it was plain it would be 'plaintext_pw_here'.

You probably want to run the auth_types() function from Net::SMTP_auth to find out exactly what values you can use for the auth type when interacting with that server. This isn't a guess. I read that in the docs.

Lastly, SMTP is dirt simple and you can do it from telnet (eg telnet hostname 25). You may want to look at the RFC and try it out. It's fun and it helps you debugging problems like this if you've done it once or twice by hand.

Post-lastly, if you're writing a CGI that sends email, make sure it's damn secure. I'm an admin at a community colleges, which means insecure scripts all over the place, and baddies will find insecure scripts and you will get blackholed as a spammer if your scripts are exploited.

Comment on Re: SMTP authentication misery

Replies are listed 'Best First'.
Re^2: SMTP authentication misery by tirwhan (Abbot) on Nov 20, 2009 at 19:09 UTC
Looking at the dump, the "plain" password doesn't look plain to me. If it was plain it would be 'plaintext_pw_here'. Wrong. PLAIN authentication requires the username and password to be sent as a NULL-separated string encoded in base64. You can get a valid authentication string like this by running the following on the command line. `perl -MMIME::Base64 -e 'print encode_base64("\000localpart\@domain.com\000password")'` <Reveal this spoiler or all in this thread> You probably want to run the auth_types() function from Net::SMTP_auth to find out exactly what values you can use for the auth type when interacting with that server No need for that either, the dump output clearly tells him: `250-AUTH LOGIN PLAIN XYMCOOKIE` says he can either use the LOGIN, PLAIN or XYMCOOKIE methods The problem he is having is most probably due to the fact that he says he needs to use SSL via port 465, but isn't actually doing that(as gman already correctly pointed out). All dogma is stupid.	[reply] [d/l] [select]
Re^3: SMTP authentication misery by cypress (Beadle) on Nov 20, 2009 at 19:20 UTC
Mmm. I will give MIME::Base64 a try, as well. Thanks much, tirwhan.	[reply]
Re^4: SMTP authentication misery by tirwhan (Abbot) on Nov 20, 2009 at 19:25 UTC
No, the MIME::Base64 line won't help you much, I only posted it to show how the line in the dump output came about. More importantly, please read the /msg I sent you (in the chatterbox node on the right of your screen) or view the spoiler in the above node. All dogma is stupid.	[reply] [d/l]
Re^2: SMTP authentication misery by cypress (Beadle) on Nov 20, 2009 at 19:15 UTC
Thanks, pileofrogs. I've now left for the day, but I'll try your suggestions tomorrow morning and report back then. I suppose I'll need to raise the question of how to go about 'securing' my code in another post -- I really know nothing concerning how others hack into programs for use as spammers. The program I'm writing will be installed locally, run pretty much continuously on that single machine, and, triggered by a date/time stamp, send email to another address in the organization. Again, I haven't a clue what security issues are involved or how to deal with them. I'd be happy for your input. cypress Update: What I'm writing isn't a CGI script (if I understand the term correctly), as it does not receive input from outside users (eg, via a webpage). The only time it connects with the outside world is when it sends email. Here, all I should need to be concerned with is the authentication password being snatched during this event. Uh, right?	[reply]
Re^3: SMTP authentication misery by pileofrogs (Priest) on Nov 20, 2009 at 22:39 UTC
Not accepting input from the outside world is definitely good for security, though you'll want to consider the risks from input from the inside as well. If it's not used by multiple humans, it's probably fine. The classic CGI security failure is a script that accepts the TO: address as one of the input variables, so anyone can use the script to send email to anyone else. The most important rule of secure coding is to always check that values are OK before you use them. Taint checking (see perlsec) goes a long way toward helping you do that. Also, you cannot trust input from web pages, even if you use java script to validate the input because anyone can bypass the javascript and the web form. You can surf the web from a telnet client just like you can send SMTP (HTTP is text based). Here's a fun thing to try run "telnet google.com 80" and then type "GET /" at the prompt. You can do any HTTP request, including POST or PUT or whatever, so an HTML form is just a "suggestion". You can put any value you want into the Referrer: header so, that's no help for security either. Users can really send any value they want. I know this isn't on topic but any chance to say this stuff is worth taking. --Pileofrogs	[reply]


Your skill will accomplish what the force of many cannot
	PerlMonks