Different credentials for IMAP/POP/SMTP vs Webmail.

gsloop

Allow login for webmail with one password, but pop/imap/smtp with another…

In short, we’d like to allow users to use webmail/Sogo with one set of credentials. But use of pop/imap/smtp we’d like to use a different set of credentials. (This would allow users to access mail from the web, but not allow them to use the same credentials to setup mail on their home PC, personal phone etc.)

Yes, I do get that webmail/sogo is simply a web-based smtp/imap client - so this is pretty difficult from a technical perspective. (How do we determine if the authentication is coming from webmail or from a regular IMAP/SMTP client.)

Any ideas on semi-reasonable ways to accomplish this would be handy.

TIA
-Greg

tbrummell

App Passwords in the User UI:

Make sure you see the note, this does not include ActiveSync. So devices using that will still require the SOGo password.

gsloop

The use is ambiguous.

Is the “regular” (sogo) password a “superset” password? (i.e. If you have the sogo password, you can also pop/smtp login, and the pop/smtp password just gives pop/smtp privs?)

Or is the pop/smtp password completely stand-alone - without it, you can’t pop/smtp at all.

The latter makes the most sense - but I want to be sure I’m understanding things correctly. (I hope it’s the latter, because that would essentially do exactly what I want.)

Is this “app” password also settable via API? (Please, oh please, say “yes.”)

gsloop

Now that I think about it. I suspect it’s the former, because it looks like you can have more than one “app” password. [It is settable in the API - which is where I get the idea you can have more than one.]

If you can have more than one, it sounds like a way to allow an “app” to send/receive mail as you, without having full access to your account. Which doesn’t do, at all, what I need.

gsloop

Bump on this.
Any possibilities? To recap, we might want users to read and send mail via the web (sogo) - but not have the same kind of risk of having the credentials for imap/pop/smtp available/known by the end user. Yes, one could lose control of the webmail credentials and someone could abuse them (spam, etc), but that’s less likely, IMO, than having an external actor abuse mail via smtp/imap.

AllgaeuerBraunvie

They are basically equal on the API. It’s meant other way around. Users should normally not store their passwords. But when you have a program that is using an API it should be stored. let’s say you have desktop pc and a notebook you can generate two api passowords for each pc. In case the notebook get’s stolen or is other way compromised you just need to reset that API password.

When the user is “loosing” his password without noticing it is no big difference if it is webmail only - you are doomed.
On the other hand the user can reconfigure his passwords regularly (maybe after beeing unsure that the password might be stolen) without the need to do the same for the programs using the API.