You shouldn't actually reset the password as soon as someone makes a password recovery request.  What keeps someone from maliciously entering known email addresses in your form and resetting others' passwords?

Try something like this:

1. User makes a request to reset their forgotten password by entering their account email address (or username).

2. Generate a random request ID. Store this ID in your database, associated with the user id and having an expiration date/time.  48 hours is a reasonable request expiration.

Email a message to them. "A request has been made to reset your MySqueezebox.com account password.  If you made this request, you can follow the link below to reset your password.  Or you can ignore this message and the request will expire in 48 hours."

The link in the message contains the request ID in the URL.

3. When (if) they follow the link, they can enter a new password.  Only then is the password changed.

Andy to follow up with Brandon on this.

Brandon - mail.log is filling up with these:

Mar  2 21:17:22 www postfix/qmgr[2758]: 4BB9658468F: to=<svcprod@squeezenetwork.com>, orig_to=<svcprod>, relay=none, delay=31640, delays=31639/0.68/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]: Connection refused)
Mar  2 21:17:22 www postfix/qmgr[2758]: 4CF1E5845F4: to=<sn_auto@slimdevices.com>, relay=none, delay=215229, delays=215228/0.69/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]: Connection refused)


Anything wrong with the mail server configuration?

thanks!

Are you sure this is fixed?  I'm not receiving an email when I attempt to reset my password.

Brandon - some recipient servers still refuse to accept mail from us. Jim is just on example:

Mar  4 09:31:13 www postfix/smtp[28959]: B74BE5845FA: to=<jim@zolx.com>, relay=127.0.0.1[127.0.0.1]:2222, delay=0.12, delays=0.02/0/0/0.09, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as BC98C5845F9)
Mar  4 09:31:13 www postfix/smtpd[28960]: disconnect from localhost[127.0.0.1]
Mar  4 09:31:13 www postfix/qmgr[17575]: B74BE5845FA: removed
Mar  4 09:31:14 www postfix/smtp[28962]: BC98C5845F9: to=<jim@zolx.com>, relay=mail.zolx.com[75.126.223.192]:25, delay=1.2, delays=0.09/0/0.69/0.39, dsn=5.0.0, status=bounced (host mail.zolx.com[75.126.223.192] said: 550-Verification failed for <registration@mysqueezebox.com> 550-Called:   209.85.211.15 550-Sent:     RCPT TO:<registration@mysqueezebox.com> 550-Response: 550-5.1.1 The email account that you tried to reach does not exist. Please try 550-550-5.1.1 double-checking the recipient's email address for typos or 550-550-5.1.1 unnecessary spaces. Learn more at 550-550 5.1.1 http://mail.google.com/support/bin/answer.py?answer=6596 15si1545991ywh.75 550 Sender verify failed (in reply to RCPT TO command))

Comcast is a prominent other:

Mar  4 10:04:54 www postfix/smtp[29012]: 5C78C5845FF: host mx4.comcast.net[76.96.26.14] refused to talk to me: 554 imta35.emeryville.ca.mail.comcast.net comcast 74.201.85.104 Comcast requires that all mail servers must have a PTR record wi
th a valid Reverse DNS entry. Currently your mail server does not fill that requirement. For more information, refer to: http://help.comcast.net/content/faq/PTR
Mar  4 10:04:54 www postfix/smtp[29014]: AD405584638: host mailin-01.mx.aol.com[205.188.59.194] refused to talk to me: 421 4.7.1 : (DNS:NR) http://postmaster.info.aol.com/errors/421dnsnr.html

There are multiple problems in play here.  The first, that was fixed a day or two ago, was that a mail daemon on the test squeezenetwork instance was dead, that fixed about 90% of the email issues.

The next is that the reverse DNS for the test instance is missing or wrong, which is causing some recipients to reject us as a spam sender.  We're moving the test instance back to its normal location tomorrow anyways, so it's pointless to try to get the DNS fixed for the current IP tonight.

Then there's also the fact that I can't even send you (Jim) an email from my corporate Logitech account, owing to what I'm guessing is overzealous anti-spam efforts on your end and/or misconfiguration on Logitech's end, but either way, neither of the two presumably have problems talking to most of the rest of the world...

Delivery to the following recipient failed permanently:

    jim@zolx.com

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550-Callback setup failed while verifying <bblack@logitech.com>
550-Called:   64.74.222.146
550-Sent:     initial connection
550-Response: 554 us01m10.logitech.com
550-The initial connection, or a HELO or MAIL FROM:<> command was
550-rejected. Refusing MAIL FROM:<> does not help fight spam, disregards
550-RFC requirements, and stops you from receiving standard bounce
550-messages. This host does not accept mail from domains whose servers
550-refuse bounces.
550 Sender verify failed (state 14).

That mail was sent via Logi's Google-hosted mail, so it should have sent out through Google's senders, and us01m10 isn't on our MX list either, so I'm not sure where that hostname is even coming from....

Thanks for looking into it.  My email is hosted on a shared server and the ISP may have recently enabled those callbacks.  Brandon, 'us01m10.logitech.com' is how the SMTP server at 64.74.222.146 identifies itself.

Apparently the mail server for my domain has been configured to use something called callback verification as an anti-spam measure.  If I can't get it turned off then I'll probably have to move the domain and email hosting elsewhere.

But... apparently it is a technique being used by some SMTP servers.

http://en.wikipedia.org/wiki/Callback_verification

Looking up the mail exchangers for mysqueezebox.com:

;; ANSWER SECTION:
mysqueezebox.com.       259200  IN      MX      20 alt2.aspmx.l.google.com.
mysqueezebox.com.       259200  IN      MX      30 aspmx2.googlemail.com.
mysqueezebox.com.       259200  IN      MX      30 aspmx3.googlemail.com.
mysqueezebox.com.       259200  IN      MX      30 aspmx4.googlemail.com.
mysqueezebox.com.       259200  IN      MX      30 aspmx5.googlemail.com.
mysqueezebox.com.       259200  IN      MX      10 aspmx.l.google.com.
mysqueezebox.com.       259200  IN      MX      20 alt1.aspmx.l.google.com.

And telnetting to aspmx.l.googl.com to see if it accepts email for the FROM address of registration@mysqueezebox.com, yields the same messages that Michael posted earlier:

220 mx.google.com ESMTP 16si2648121iwn.53
HELO ns1.mediaodyssey.com
250 mx.google.com at your service
MAIL FROM:<>
250 2.1.0 OK 16si2648121iwn.53
RCPT TO:<registration@mysqueezebox.com>
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 http://mail.google.com/support/bin/answer.py?answer=6596 16si2648121iwn.53

IMO, it would be in your best interest to send out any messages from mysb.com, including these password resets, using a valid email address.

Same thing for the FROM address used in the SD Forums notifications (forums@slimdevices.com), which explains why I stopped receiving forum email at about the same time.  I'm also no longer receiving bugzilla notifications.

220 mx.google.com ESMTP 32si2598977iwn.51
HELO ns1.modyssey.net
250 mx.google.com at your service
MAIL FROM:<>
250 2.1.0 OK 32si2598977iwn.51
RCPT TO:<forums@slimdevices.com>
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 http://mail.google.com/support/bin/answer.py?answer=6596 32si2598977iw
n.51

Thanks Jim.

test.sn has moved back to its original location.  It still doesn't have valid reverse DNS yet, but the request is in, just waiting on it to get done.

As for the callback stuff, I *think* we can fix this for mysqueezebox.com and slimdevices.com senders, I'm not sure whether we'll be able to for logitech.com addresses.  There are multiple groups involved with different ideas about mail server software and policies :)

This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release.

If you are still seeing this issue, please let us know!