Hacker Newsnew | past | comments | ask | show | jobs | submit | lxst's commentslogin

Please read the cited FAQ entry again:

> On the other hand, own domains need to be registered to the name and address of a person. If you were able to use own domains with us, this would affect the entire concept of Posteo: we would need to start saving user information for all customers who use their own domains with us – and to provide these to the Federal Network Agency to be provided on request to the authorities.


That sort-of makes sense for why they do not offer you domains, but not why they do not have a "bring your own domain" plan (like e.g. mailbox does). There somewhere being a registrar knowing who I am doesn't change what they have to do, they do not need to have or look at that data in any way.


I think they're arguing that, if you bring your own domain, they still know what domain they're storing email for (by checking the reverse lookup) and they could look up the name behind it in the registry.

They don't want to be put in the position where they know what natural person a certain email belongs to.


They could also put the e-mail address in Google and find out who I am...

I get and respect that they want to provide a way to use their service without identifying yourself, but stopping a customer from voluntarily identifying themselves is fairly futile, and counter to how many people intend to use e-mail. (Indeed, they offer payment by bank transfer or paypal, so clearly they do not insist on full privacy)

Well, luckily they have direct competitors that offer the full range, so while I'd love more players in this segment I'm not directly affected by them not wanting such customers (and I find the argument questionable enough to reconsider recommending them in the future)


Even the payments part is addressed in the FAQ link I shared previously [1] and in a separate page about payments. [2]

While I'm sure that we would have to take certain things with a pinch of salt, since Germany is a Fourteen Eyes country, for me this amount of attention is something I haven't seen elsewhere (and not at this price). As I mentioned above, the social responsibility and other factors also heavily influenced me when I did the switch to Posteo.

From the FAQ: [1]

> "How can Posteo be anonymous, when I’m paying by bank transfer or PayPal?

> Credit is always added to your Posteo account anonymously – regardless of whether you pay by bank transfer, PayPal, credit card or in cash. We do not attach the data we receive with payments to the email accounts. We developed our own system for this in 2009, with which all payment processes are anonymised.

> The payment system is the core of our concept of data reduction, above all, because we keep payment information strictly separate from our customers' email accounts, we do not attach any user information to the accounts – and can thereby ensure the fundamentally anonymous use of our email service. You can find out in detail how the anonymisation of payment processes occurs at Posteo on our payment info page."

[1]: https://posteo.de/en/site/faq

[2]: https://posteo.de/en/site/payment


The point is, it's their company and they get to decide their features, not you. They don't owe you any kind of explanation.


Of course it's their right to decide the features. Just as it is my right to talk about how their given reasons for their decisions don't seem to make sense and let that influence my view of the company. Which is all we're doing here: talking about the companies to inform each other.


What on earth gives you the impression it's appropriate for you to prevent other users from wanting a company to have/build certain features?

It's neither the user's wish, nor the company as the company most certainly wants user feedback. Your post quite literally is only there to satisfy yourself.


Touched a nerve did I? Sorry to puncture your sense of entitlement.


No, they can't. If I wanted to protect my privacy I'd use a service like RespectMyPrivacy that hides my name.

Just as a rhetorical question: do they decline local parts in the form of firstname.lastname? Thought so.


Not sure I got what your rhetorical question is about. You don't have to provide any first name or last name or a real name. I've also linked to the FAQ and the payments explanation in another comment above, which go into more detail about what information they avoid collecting, storing and processing.


Really? I am from Germany and have hard time finding dumb TVs . Blaupunkt TVs (>40'') are hard to find online too.

Do you have any store/other brand recommendations?


Looks like they are using Rainloop (https://www.rainloop.net/) with a customized skin.


I'm a bit suprised: While Rainloop seems to the most modern opensource webmail client I could find (and I did do some research), from their github: _This is NOT a stable version of RainLoop Webmail. It's not recommended to use in production environment._ From my own testing there are certainly still a few bugs. Interesting they go with this for their primary webmail.


If they are using the AGPL community version of Rainloop, that might also pull in some obligations they aren't meeting.

AGPL is pretty viral, even for a web app.


You can watch the talk here: https://www.youtube.com/watch?v=gweDBQ-9LuQ


is it just me, or does he think that swearing makes him look cool?


I'd be fine with the swearing if it'd be backed up by some knowledge and experience, but that smug attitude is just incredibly irritating when coupled with such level of ignorance. First decide what are you going to bash. Some libraries, some applications, the entire programming environment ? Using induction from DBI->quote/CGI and a few old apps to bash the entire Perl ecosystem is just boringly stupid. It is fine and useful to patch those old apps, but to give an arrogant lecture as if all programmers use the same broken approaches in 2014 is just ignorant.

It is extensively documented to prefer placeholders when working with DBI, that is, if you even use DBI directly and not via an OO mapper. CGI as an approach is entirely deprecated on all languages/platforms not just Perl. List expansion ? It is a feature, use it or leave it. You have the option to use references. If you prefer Python, just use Python. It's like bashing C for having pointers. So, what else ? Try PHP with those examples. Find some Ruby apps prone to sql injection. Bash some NodeJS libraries. If Perl is dead already, be a rockstar bashing the new stuff, why even bother with the ghosts ? I think it is because deep down all Pythonistas know that Perl is a far superior platform and they all carry a deep ancestral envy. Otherwise they'd just be happy with their choice already. :)


Oh wow. The attitude on display is really not good.


Which Mail provider are you currently using?

I am also German and currently checking out solutions for moving my mail, calender, etc. off of outlook. A major requirement for me is to manage different E-Mail addresses and send via different SMTP servers.

1&1 Hosted Exchange looks quite nice, but 9,99€ isn't that cheap, and there is no tryout unfortunately and afaik does Exchange lack an alias-Feature (+ send via another SMTP, so it gets send without "on behalf of...").


I am using domainfactory for email and a raspberry pi and owncloud for calendar and contacts.


Technically speaking: Isn't Nokia HERE also a global non-US map-service, seeing as Nokia is based in Finnland?


Nokia's cartography is from Navteq, a Chicago-based subsidiary. https://en.wikipedia.org/wiki/Navteq


Actually, Navteq is no longer an independent entity since 2011-2012. The business unit is now called HERE [1] and mostly divided between Germany and the US.

It provides maps services for MS, MapQuest, Garmin, Amazon, Yahoo! Maps, Yandex, BMW, Oracle GIS...

But the Navteq brand still exists.

[1] http://www.nokia.com/global/about-nokia/about-us/our-structu...


Ah okay - thanks :)


Yes I was coming to post this.

Clearly the person who wrote the title of this message is uninformed.


Or maybe you are!


One example would be Calendar. First they announce that they retire EAS for CalDav. A few month later they announce that CalDAV will be deprecated and only available for selected developers and other services should use the proprietary Google calendar API.

Which is kinda sad as Google could have really improved CalDAV with their move. Now it is back to "walled garden".


While I think that pattern sucks, I'm not sure that "not supporting" a standard constitutes "sabotaging" it. There's a big gap between "promoting" and "destroying/undermining", it's not either-or. Saying Google "sabotaged" a standard implies that they somehow made it unusable for everyone.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: