Saturday, October 24, 2015

Panic At The Benefits Site

Bit of a panic moment, this morning. Got an email from my former employer's benefits plan administrator telling me "because your ESOP plan had less than the required minimum balance to be retained under the current program, your plan will be cashed out, taxes assessed and a check sent". This struck me as odd, because the only plan I was aware of that was managed by the brokerage was my 401(k), which, if it was below the minimum balance, would have meant that a not-inconsiderable chunk of money had somehow managed to go "poof".

The initial panic wasn't helped by the fact that, the link that the plan-administrator sent to me to view my plan info was erroring out in a way that could have been interpreted as my account having been deactivated.

Decided, "calm down. Go run your morning errands. Try the site again in a couple hours and see if it was just a transient problem and not something more serious."

Get home and try the link again. Same damned error. Opt to try logging in using a different method. The different method worked. Found all my funds still present an ESOP that I hadn't specifically known about.

And, no, the email wasn't bogus, just broken. I'd checked the headers before clicking the links ...and the fact that it was sent to an address set up specifically for use by the plan-administrator meant that, if it was a phish, they'd have had to have already compromised the administrator's site to get my address. Lastly, the site's URL and SSL certificate were all good. All those details in place, were it an exploit, they likely would have had a better effort-ROI by just extracting data directly from the site-owner than trying to phish me.

Thursday, October 22, 2015

Cloud, The Vogon Way

Me: "I'd like to be able to send account-validation emails to people who register to my bug-tracking system".
AWS Dox: "Sure... but if you mail direct, most sites will treat your email as spam"
Me: "Ok... How do I get around that"

AWS Dox: "Well, you can relay through SES"

Me: "Cool. Lemme go set that up."

AWS-SES: "Rejected!"

Me: "Your SMTP message is a bit vague - are you rejecting the relay because of the sender or the recipient?"


AWS Dox: "To relay with SES you have to validate senders - or sender-domains - and recipients"

Me: "Ok... The SES console says my domain is validated and that any sender in the domain should be good."


Me: "Guess that means the rejection message applied to the recipients. Lemme verify a recipient ...even though that makes SES crap as a smart-relay"


Me: "Fuck... I only validated the recipient in one region and the rejecting relay is in another. Lemme verify my recipient in _multiple_ regions, then ...You do realize this makes SES a real horror-show for smart-relay services, right?"


Me: "What the actual fuck??" (dig through shitty AWS dox some more) "Srsly? I gotta validate my domain in each region I want to relay through SES??"

I swear: Vogons had to have consulted on the design of some of AWS's service-components.