cypht
cypht copied to clipboard
cypht-org
Using "same login" for SMTP from IMAP
🗣 Suggestion
Using multiple accounts with the same mail provider will result in many configured IMAP servers (different login data)
When using Cypht profiles, it's possible to tie together an IMAP and SMTP server so that sending a mail / replying chooses the right SMTP server.
Problem: There is only one set of login data per SMTP server.
As the provider I'm using forces me to use the correct login data (in my case the mail address) to be able to set FROM: to the corresponding mail address, I need to create one SMTP server for every profile.
The solution would be to add a checkbox to the SMTP server configuration called "Use login data from incoming server" and then decide what these are based on the IMAP server in the profile configuration.
If those can't be determined sending the mail must fail with a descriptive error message.
I'm not versed in the login-mechanics in Cypht to make a working proposal PR.
K
Well no.
IMAP before SMTP in classic fashion would mean, first and foremoremost, that the server admin has enabled that feature, and mine doesn't - which I also wouldn't want for security reasons.
What I would like Cypht to see do, is authenticate at the SMTP server, exactly as if I'd never IMAP'd before, but behind the scenes the above described process shall find the username and password for this authentication.
Kai
What kind of security reasons are you talking about, as there are none. A good mailserver admin knows the advantages of IMAP before SMTP, there is more then just authentication there.
What you want is not very common anymore because of that IMAP before SMTP exists, it's more secure. Most providers don't even allow sending emails by only SMTP authentication anymore because it's a big taks to maintain such servers if you are allowed to relay for domain/senderip/etc. IMAP before SMTP fixes that issue by default.
The solution would be to add a checkbox to the SMTP server configuration called "Use login data from incoming server" and then decide what these are based on the IMAP server in the profile configuration.
@kmpoppe This is not a bad idea and might not even be too hard to work out. I will check into it and let you know. Thanks for the feedback!
@di-rect, I cannot follow your argumentation as to why IMAP before SMTP should be more secure than just SSL/TLS-enabled CRAMD-MD5 authentication directly at the SMTP server. If you have the login data that allows you to send data through the SMTP, anyone with enough time on their hand (which spammers usually have) would be perfectly capable of authentication at the IMAP with the data they know, immediately quitting without doing anything with the mails, and then sending loads of mails through the SMTP.
No matter my opinion about IMAP-before-SMTP, I'm just not able to use it. My mail-server provider simply does not have this option and I have quite frankly not found any working instance of it that are currently offered by any providers.
@jasonmunro Thanks for looking into this!
Kai
@kmpoppe You are confused about authentication and security used by doing authentication. I don't discuss any SSL/TLS/etc encryption type which the authentication uses, I'm trying to explain you how SMTP is authenticated using the backend.
Because you don't understand how it works you think in a wrong way of solution, your solution, which is not used very common anymore these days because it's maintenance is not very nice these days.
Which providers have you checked out ? Even Gmail supports it and you can host your domains there.
Point me which providers you have checked out and how you made sure they don't support it and you could not fine any other, because literally almost every provider these days supports it with reasons; better "security" against spammers, even Google understands that 😉
@di-rect this is not the appropriate place to discuss opinions about authentication methods and which are better or widely supported thanks. @kmpoppe asked for a reasonable feature that addresses his particular situation and if possible we will try to accommodate that. It would be appreciated if we can keep it focused on that thanks!
@jasonmunro If you want to implement all feature requests without thinking it over it won't do this software any good. This problem can be solved in a way he asks, it doesn't mean it's the right way and you end up with options that should be fixed on a lower level; so to say: backend.
If you want to keep your software good and maintainable you cannot satisfy everyone, you cannot get around discussions there.
Please ask yourself: Do you like to fix everything with Duct-tape and Ty-raps as well ?
Just chiming in to clarify the original request :wink:.
@kmpoppe if you setup manually one SMTP server configuration for every (IMAP) profile, then you have the guarantee you filled in the correct credentials for the particular IMAP profile, right? I assume you have to have lots of IMAP profiles then (more than hundred, because that's about the amount I'd consider manageable manually).
So basically the problem is "tedious addition of SMTP server configuration properly linked with given IMAP account". I further assume this tedious addition happens only once without any further maintenance/changes.
Correct me if I'm wrong, but what you're proposing is esentially a heuristic (hidden behind a checkbox) to find out the credentials for you automatically - namely the credential "login name" should be taken from From: header of the newly composed email and the credential "password" shall be taken from an existing IMAP profile chosen based again on the content of the From: header.
If my understanding is correct, then I'd say, yes this heuristic makes sense on its own, but the question is whether it's not too fragile to justify hardcoding it into a generic email application.
There are surely other ways to solve the tedious addition - maybe some smart prefilling of the form after clicking the "add SMTP server configuration" button or maybe a button "send this newly written email with a different SMTP server" which would open a list of smartly prefilled input forms with SMTP credentials and a checkbox "remember my choice for {the_email_in_From:} and don't ask next time" (which would essentially add the SMTP credentials configuration and link it with the given IMAP profile).
Any thoughts how to present this to the user for best UX?
@dumblob difficult to say what the best way is for the user his UX when you are not sure if this should be in the code or not.
I think using a module is not possible but as POP would be moved to module as well as I have read it might be a good solution so you can decide what you want to have in or what to have in not.
@jasonmunro If you want to implement all feature requests without thinking it over it won't do this software any good. This problem can be solved in a way he asks, it doesn't mean it's the right way and you end up with options that should be fixed on a lower level; so to say: backend.
If you want to keep your software good and maintainable you cannot satisfy everyone, you cannot get around discussions there.
Please ask yourself: Do you like to fix everything with Duct-tape and Ty-raps as well ?
This comment is condescending and rude. I'm not sure if you are just trolling or unaware that you are being rude. I will give you one more opportunity to be respectful in your comments here. Thanks!
@kmpoppe to clarify, you would be using the username + password from the associated IMAP server, or is the username coming from somewhere else? Many configurations use the same username + password for both IMAP and SMTP so there may be a wider audience for this type of feature than just your use case.
@jasonmunro If you want to implement all feature requests without thinking it over it won't do this software any good. This problem can be solved in a way he asks, it doesn't mean it's the right way and you end up with options that should be fixed on a lower level; so to say: backend. If you want to keep your software good and maintainable you cannot satisfy everyone, you cannot get around discussions there. Please ask yourself: Do you like to fix everything with Duct-tape and Ty-raps as well ?
This comment is condescending and rude. I'm not sure if you are just trolling or unaware that you are being rude. I will give you one more opportunity to be respectful in your comments here. Thanks!
Criticism for good development is not always nice for people that cannot deal with it, that's whats you confirm yourself. Your "warning" doesn't make you a nice person at all with your "privileges" here as owner, that is being inappropriate and rude, happily Github offers the possibility to fork which does not help your project again.
I can also tell you: You won't tell me what to do in a FOSS world, you will tell NO-ONE!
I have read some more discussions with you and it seems you simply cannot handle it at all which is a pity, it doesn't help you or your software apparently, neither the users.
Tip: Don't try to satisfy everyone that has a bad setup in their basics or don't understand that much of Technics (in combination with UX).
Let me make this very clear again: You start inappropriate and rude discussions because you don't seem to respect anyone else with a wider view then yourself or people who try to make an advantage of that behavior because of their selfish involvement.
Sad.
Many configurations use the same username + password for both IMAP and SMTP
That is the case for all the mail servers I use, so I'd appreciate if both were added at once. And if a password is modified on my mail server, I just need to change it once in Cypht.
Thanks!
@dumblob
@kmpoppe if you setup manually one SMTP server configuration for every (IMAP) profile, then you have the guarantee you filled in the correct credentials for the particular IMAP profile, right? I assume you have to have lots of IMAP profiles then (more than hundred, because that's about the amount I'd consider manageable manually).
150, yes.
So basically the problem is "tedious addition of SMTP server configuration properly linked with given IMAP account". I further assume this tedious addition happens only once without any further maintenance/changes.
Yes, and of course this ought to happen only once, but hasn't yet.
Correct me if I'm wrong, but what you're proposing is esentially a heuristic (hidden behind a checkbox) to find out the credentials for you automatically - namely the credential "login name" should be taken from
From:header of the newly composed email and the credential "password" shall be taken from an existing IMAP profile chosen based again on the content of theFrom:header.
Unfortunately, I need to correct you, but I wasn't thinking along the lines of anything like that. The reason that my provider uses the From:-address as the username just happens to be the case.
I have therefore no real problem with adding said IMAP servers and providing them with the correct login data. The problem I'm facing is, that the SMTP server used in the Cypht-profile needs the correct login data for every From:-address. So that leaves me with 150 IMAP servers and 150 different SMTP server entries (which are all accessed by the same DNS-name) JUST because I need to send mails using the correct username and password that is already set up in the IMAP profile.
Any thoughts how to present this to the user for best UX?
As described in my original post, what I am thinking of is a simple checkbox that says "use login data from IMAP for SMTP" in the server configuration - that a) stops Cypht from checking whether it can login and b) will do as the name says when any IMAP server and said SMTP server are together in a Cypht profile.
Am I making any sense?
For the record, Henock is working to revamp the whole process of setting up accounts. Next steps is a pull request with his proposal.
Here is PR: https://github.com/cypht-org/cypht/pull/855
It is part of https://github.com/cypht-org/cypht/releases/tag/v2.0.0
@kmpoppe
Please retest, as a lot has changed since you reported this issue. Notably, we now have 3 active branches and recently released Cypht 2.0.0
- https://github.com/cypht-org/cypht/releases/tag/v2.0.0
- https://github.com/cypht-org/cypht/wiki/Lifecycle