Earlier quoted context omitted.
Why do they want this?
[deleted]
I guess nobody believed you, because it sounds so ridiculous. Do you have an idea why Google imposes that rule?
You don’t need a password. Posterous fail.
41–50 of 84 posts
Re: You don’t need a password. Posterous fail.
#42Why not let users use email certificates if they want? That's what I've got going on in Tgethr. Let users decide if extra trouble of setting up an email cert is worth it (it's not that bad), and now all of a sudden you have spam proof email discussion lists. We just check the message signature to make sure yep your message is signed as dustincurtis@gmail.com or whatever and we'll accept the message.
Re: You don’t need a password. Posterous fail.
#43It is easy. $ /usr/sbin/sendmail -f dustin@dustincurtis.com dustin@posterous.com Subject: hi Spam spam spam ^D
You don't even need to know the command line, you can often do stuff like that just from Outlook.
You don't even need to know Outlook, you can often do stuff like that just from the command line. ;)
Re: You don’t need a password. Posterous fail.
#44[deleted]
Re: You don’t need a password. Posterous fail.
#45It's possible to forge headers in certain circumstances. It's not easy. And this is the first time this has happened. It's ridiculously easy to forge email headers. Headers are manually created whenever programmatically sending email messages. That's how messages can be sent from addresses that don't exist, like devnull@example.com or noreply@yourdomain.com. They don't even send a confirmation email that you have to…
I updated the post to reflect reality. Usually, Posterous catches this stuff and sends an email asking you to confirm that you really are you. They analyze the headers more closely than just looking at the name. For some reason, this didn't work in this case.
But, if they only analyse the headers, they are screwed anyway. Don't they also check the IP of the SMTP server as well or something?
Re: You don’t need a password. Posterous fail.
#46Twitter had similar issue in their Text -> Tweet system. People were using softwares to send Text messages and using anybody's phone number as they want. They fixed it by using 4 digit pin and I think Posterous should do the same.
Re: You don’t need a password. Posterous fail.
#47Two solutions: 1. Change from "Contributors can post" to "Anyone can post". Counterintuitive, but the first is based on email FROM, the second is moderated. 2. Make a hash as your FROM address. Add it as an alias to send from in Gmail (or whatever you use). Send to posterous from the hash address. Your email address becomes your password.
To add an additional outgoing address to Gmail, don't you have to verify that you can receive messages at that account first?
Re: You don’t need a password. Posterous fail.
#48Two solutions: 1. Change from "Contributors can post" to "Anyone can post". Counterintuitive, but the first is based on email FROM, the second is moderated. 2. Make a hash as your FROM address. Add it as an alias to send from in Gmail (or whatever you use). Send to posterous from the hash address. Your email address becomes your password.
To add an additional outgoing address to Gmail, don't you have to verify that you can receive messages at that account first?
You could presumably use the plus sign "hack" to make that a bit easier: http://gmailblog.blogspot.com/2008/03/2-hidden-ways-to-get-m...
Re: You don’t need a password. Posterous fail.
#49I did it. Sorry Dustin. It really was me. I changed one field in outlook. I realise Posterous requires you to "confirm" the post, I just wanted to see if you had defaulted that requirement to off.
I find it bizarre that it took this long for someone to do this...
Re: You don’t need a password. Posterous fail.
#50Earlier quoted context omitted.
> "The other fix would be to use an email address that can't be guessed from the blog address. In other words, the email address is the password." You'd still be sending your password in the clear, possibly through other peoples mail servers. Not great security.
The perfect is the enemy of the good. There is a trade-off here between security and usability. 99% security is good enough for a lot of purposes and has its place.
Except that's more like 10% or 1% security.