- Added an option to enable smtp debugging via SMTP_DEBUG. This will
trigger a trace of the smtp commands sent/received to/from the mail
server. Useful when troubleshooting.
- Added two options to ignore invalid certificates which either do not
match at all, or only doesn't match the hostname.
- Updated lettre to the latest alpha.4 version.
plain/text emails should not contain html elements like <p> <a> etc..
This triggers some spamfilters and increases the spam score.
Also added the github link into the text only emails since this also
triggers spamfilters to increase the score since the url/link count is
different between the multipart messages.
- Added check if settings are changed but not saved when sending test
email.
- Added some styling to emphasize some risks settings.
- Fixed alignment of elements when the label has multiple lines.
Some issue people report are because of misconfiguration or bad .env
files. To mittigate this i added error handling for this.
- Panic/Quit on a LineParse error, which indicates bad .env file format.
- Emits a info message when there is no .env file found.
- Emits a warning message when there is a .env file, but not no
permissions.
- Emits a warning on every other message not specifically catched.
If for some reason the hashed password is cleared from memory within a
bitwarden client it will try to verify the password at the server side.
This endpoint was missing.
Resolves#1156
When using MariaDB v10.5+ Foreign-Key errors were popping up because of
some changes in that version. To mitigate this on MariaDB and other
MySQL forks those errors are now catched, and instead of a replace_into
an update will happen. I have tested this as thorough as possible with
MariaDB 10.5, 10.4, 10.3 and the default MySQL on Ubuntu Focal. And
tested it again using sqlite, all seems to be ok on all tables.
resolves#1081. resolves#1065, resolves#1050
Made some small changes to the description of the config options for
SMTP. Some were a bit cryptic and missing some extra descriptions.
Also made it more clear which type of secured smtp connection is going
to used.
Currently when for example using the admin interface to send out a test e-mail just
returns `SmtpError`. This is not very helpful. What i have done.
- Match some common Lettre errors to return the error message.
- Other errors will just be passed on as before.
Some small other changes:
- Fixed a clippy warning about using clone().
- Fixed a typo where Lettere was spelled with one t.
- Allow all SMTP Auth meganisms supported by Lettre.
- The config value order is leading and values can be separated by a
comma ','
- Case doesn't matter, and invalid values are ignored.
- Warning is printed when no valid value is found at all.
General:
- Updated several dependancies
Lettre:
- Updateded lettere and the workflow
- Changed encoding to base64
- Convert unix newlines to dos newlines for e-mails.
- Created custom e-mail boundary (auto generated could cause errors)
Tested the e-mails sent using several clients (Linux, Windows, MacOS, Web).
Run msglint (https://tools.ietf.org/tools/msglint/) on the generated e-mails until all errors were gone.
Lettre has changed quite some stuff compared between alpha.1 and alpha.2, i haven't noticed any issues sending e-mails during my tests.
If org owners/admins set their org access to only include selected
collections, then ciphers from non-selected collections shouldn't
appear in "My Vault". This matches the upstream behavior.
Diesel requires the following changes:
- Separate connection and pool types per connection, the generate_connections! macro generates an enum with a variant per db type
- Separate migrations and schemas, these were always imported as one type depending on db feature, now they are all imported under different module names
- Separate model objects per connection, the db_object! macro generates one object for each connection with the diesel macros, a generic object, and methods to convert between the connection-specific and the generic ones
- Separate connection queries, the db_run! macro allows writing only one that gets compiled for all databases or multiple ones
Currently, favorites are tracked at the cipher level. For org-owned ciphers,
this means that if one user sets it as a favorite, it automatically becomes a
favorite for all other users that the cipher has been shared with.
