Sv: Better not post your email password on a public mailing list, was: Re: no full syncs after upgra
Even more stupid that the IMAP port is available to the public. Should have been firewalled to authorized IPs only, then it wouldn't have mattered that the password have leaked. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Daniel Lange Skickat: den 27 april 2022 14:59 Till: Paul Kudla (SCOM.CA Internet Services Inc.) Kopia: dovecot@dovecot.org Ämne: Better not post your email password on a public mailing list, was: Re: no full syncs after upgrading Am 26.04.22 um 11:36 schrieb Paul Kudla (SCOM.CA Internet Services Inc.): > #imapc_host = mail.scom.ca > #imapc_password = Pk554669 > #imapc_user = p...@scom.ca I suggest to change that password immediately. $ openssl s_client -crlf -connect mail.scom.ca:993 CONNECTED(0003) * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] SCOM.CA Internet Services Inc. - Dovecot ready A login p...@scom.ca Pk554669 A OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY PREVIEW=FUZZY PREVIEW STATUS=SIZE SAVEDATE LITERAL+ NOTIFY SPECIAL-USE] Logged in A status INBOX (messages) * STATUS INBOX (MESSAGES 344) A OK Status completed (0.002 + 0.000 + 0.001 secs). ^C Kind regards, Daniel
Sv: Does disabling POP3 just mean removing it from the protocols list?
However, you SHOULD IMHO lock the access so it has to be manually opened for each user that wants it. Another way is to do a PTR lookup on IP and [DROP] the packet if its not a google IP. And then have a IP restriction on IMAP and also 587/SMTP Auth. This because there is bots out there that guess passwords and then send spam. By locking access for POP3 by Google IP, you ensure it can only be used with the fetch feature of Gmail (which do have account-wise rate-limits to prevent password hacking). In this way, you increase security. Of course it must be combined with IP restrictions and firewalling for IMAP and Auth on 587 aswell. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Harlan Stenn Skickat: den 2 mars 2022 01:15 Till: Peter ; dovecot@dovecot.org Ämne: Re: Does disabling POP3 just mean removing it from the protocols list? The reason to support POP3 is that if you forward email to another account and that includes any spam, you are gonna get dinged. If folks want to read their email from gmail, they really need to suck that email over via POP to avoid this problem. H On 3/1/2022 3:13 PM, Peter wrote: > The only modern reason I can think of to continue to support POP3 is > that gmail's email fetch feature only works over POP3, so if you want > people to be able to import their email from your server to gmail or > google workspace then you should probably continue to support POP3. > > > Peter > > > On 2/03/22 10:54 am, Sean McBride wrote: >> Hi all, >> >> Hopefully a simple question. If I want to disable POP3 support >> (because everyone is using IMAP anyway), it is just a matter of >> removing |pop3| from the |protocols| setting in dovecot.conf? >> >> Are there side effects or other considerations I should be aware of? >> >> Thanks, >> >> Sean >> >
Sv: Sv: Sv: dovecot mailing list (this mailing list), DKIM, SPF and DMARC
Yep. Its a lot of TLDs that is banned at me, but I haven’t had any problems
with .ru so .ru isn’t yet banned.
Here is my TLD banlist:
deny
message = 5.7.1 Banned TLD where sending IP is not listed on DNSWL (
https://www.dnswl.org/selfservice/?action=register )
condition = ${if eq {$acl_m4}{dnswl_whitelisted}{no}{yes}}
sender_domains =
^(?i).*\\.(accountant|accountants|asia|auto|berlin|bid|buzz|camera|car|cam|cars|christmas|click|club|college|computer|country|cricket|date|design|download|exposed|email|fail|faith|fit|fun|gdn|global
|guru|help|host|jetzt|kim|icu|life|live|link|loan|london|media|men|mom|news|ninja|online|party|photography|pro|protection|pub|racing|realtor|reise|ren|rent|rest|review|rocks|science|security
|shop|site|solutions|space|storage|store|stream|study|surf|tech|technology|theatre|today|top|trade|university|uno|us|viajes|vip|vividal|wang|webcam|website|win|work|works|world|xin|xyz|zip|xn--.*)\$
This crap that ICANN started with “custom” TLDs is of more harm than useful. So
much spam TLDs in the registry.
Från: dovecot-boun...@dovecot.org För justina
colmena ~biz
Skickat: den 12 februari 2022 14:06
Till: dovecot@dovecot.org
Ämne: Re: Sv: Sv: dovecot mailing list (this mailing list), DKIM, SPF and DMARC
The ".top" TLD is popular among Russian spammers, ".ru" is a little too obvious
and honest for what it is, unless that's part of Biden's sanctions, the others
you mention look like vice domains, but looking at GitHub:
* https://github.com/dovecot
There's an "Oy" which is a Finnish "osalliyhdistys" and a ".fi" -- I have not
heard of recent hostility between Finland and Russia, notwithstanding the
Ukraine situation. Your mail client is all configured in Swedish, but Sweden &
Finland are not officially part of NATO, AFAIK, and Sweden has its own currency
whereas Finland did give up the markka in exchange for the Euro some 20-odd
years ago I don't recall.
On February 12, 2022 2:58:03 AM AKST, Sebastian Nielsen mailto:sebast...@sebbe.eu> > wrote:
Thats a TLD ban. Meaning *.ru is banned.
same applies for my domain for example, I ban *.xyz, *.date and a few others.
-Ursprungligt meddelande-
Från: dovecot-boun...@dovecot.org <mailto:dovecot-boun...@dovecot.org>
mailto:dovecot-boun...@dovecot.org> > För Lev
Serebryakov
Skickat: den 12 februari 2022 12:08
Till: dovecot@dovecot.org <mailto:dovecot@dovecot.org>
Ämne: Re: Sv: dovecot mailing list (this mailing list), DKIM, SPF and DMARC
On 11.02.2022 16:31, Marc wrote:
(sorry for posting to list this, but I don't have any ways to contact Marc
off-list now)
Problem is, I need to unpack each of them to be sure, that these
are false positives and I'm afraid, that it could lower reputation of
my mail server IP address with major providers (like Google Mail).
How can you get a lower reputation? Afaik dmarc is just signing your outgoing
messages.
Marc, my domain already has problems sending mail to you, for example:
mailto:m...@f1-outsourcing.eu> >: host
spam1.roosit.eu[212.26.193.45] said: 553 5.3.0
550We have blocked this toplevel because of spam. Use another toplevel
until the maintainer has resolved these issues (in reply to MAIL FROM
command)
--
// Black Lion AKA Lev Serebryakov
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Sv: Sv: dovecot mailing list (this mailing list), DKIM, SPF and DMARC
Thats a TLD ban. Meaning *.ru is banned. same applies for my domain for example, I ban *.xyz, *.date and a few others. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Lev Serebryakov Skickat: den 12 februari 2022 12:08 Till: dovecot@dovecot.org Ämne: Re: Sv: dovecot mailing list (this mailing list), DKIM, SPF and DMARC On 11.02.2022 16:31, Marc wrote: (sorry for posting to list this, but I don't have any ways to contact Marc off-list now) >> >>Problem is, I need to unpack each of them to be sure, that these >> are false positives and I'm afraid, that it could lower reputation of >> my mail server IP address with major providers (like Google Mail). >> > > How can you get a lower reputation? Afaik dmarc is just signing your outgoing > messages. Marc, my domain already has problems sending mail to you, for example: : host spam1.roosit.eu[212.26.193.45] said: 553 5.3.0 550We have blocked this toplevel because of spam. Use another toplevel until the maintainer has resolved these issues (in reply to MAIL FROM command) -- // Black Lion AKA Lev Serebryakov
Sv: dovecot mailing list (this mailing list), DKIM, SPF and DMARC
I get it too. These appear because they don't replace either MAIL FROM: or Mime From: with the list address. This causes validations to fail since the mailing list is trying to spoof mail in your name, and of course, anti-spoofing security is going to react. DKIM can be troublesome since mailing lists sometimes change or reencode content so DKIM signature fails. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Lev Serebryakov Skickat: den 4 februari 2022 21:58 Till: dovecot@dovecot.org Ämne: dovecot mailing list (this mailing list), DKIM, SPF and DMARC My domain (serebrtyajov.spb.ru) has all these "new" e-mail technologies configured. It works fine till I write to this mailing list. After that I've got several DMARC reports about "spam" from my domain. All these reports are about my mailing list post. I don't have such problems with other mailing lists (FreeBSD ones, OpenJDK ones, and others). Looks like mailing list software for this mailing list is misconfigured. I'm sure, I'll get new after this message. -- // Black Lion AKA Lev Serebryakov
Sv: banning
I would say, lock accounts to for example IP address, ASN or GeoIP. This can be accomplished simply by a custom login handler, which also checks IP against database. And first time users, and those who change country/ISP/IP have to simply logon to a web interface (where 2FA can be required and also Captcha) and add their IPs/ASNs/Geo's. For a larger user base, I would recommend GeoIP and no web interface, save country of first login to database, and subsequent logins must originate from same country. Users that want to reset have to contact support. If you are a web hotel who only sell service to a specific country at all, lock the ports in firewall to that GeoIP. For smaller user base, like 50-100 users, I would recommend locking to ASN and providing a web interface where multiple ASN can be added. So people syncing from mobile and home can succeed. For very small user base, like 10's of users, just plan lock to IP. By connecting IP to accounts, you greatly reduce the attack surface.
Sv: patch: make received-header on submission optional or optionally drop the from-part in it
MUA/browser based things are not considered be in scope for GDPR unless they are truly unique. So you do NOT need to hide user-agent/MUA for privacy reasons. Received lines is only applicable (in scope for GDPR) if they identify the end user. A good solution to this would be to just scrap every received-line EXCEPT for the received line *immediately* before receiving the mail (which will be the remote server connecting). This will guaranteed protect against mail providers that DO insert their end user IP or client IP as a Received line. Example: If 123.222.123.222 connects to us and sends an email, and you have the following received lines: Received: from 127.0.0.1 (localfw-mailscanner) bablabla Received: from 23.34.56.33 (spamscanner.someservice.com) blablabla Received: from 123.222.123.222 (remote.mailserver.com) blablabla Received: from 99.99.99.99 (somecustomer.someisp.com) blabla Received: from 192.168.1.100 (somerouter.atsomecustomer.local) blabla Then you scrap the 2 earliest, so you are left with: Received: from 127.0.0.1 (localfw-mailscanner) bablabla Received: from 23.34.56.33 (spamscanner.someservice.com) blablabla Received: from 123.222.123.222 (remote.mailserver.com) blablabla For X-PHP-Originating-Script I don't think you need to hide that unless it contains the IP of the web user submitting the form. Same applies here, if someone sets up a server, they have automatically consented to the processing of personal details, since they publish things. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Michael Kliewe Skickat: den 5 januari 2022 17:25 Till: dovecot@dovecot.org Ämne: Re: patch: make received-header on submission optional or optionally drop the from-part in it Hi, Am 03.01.2022 um 20:08 schrieb dc...@dvl.werbittewas.de: >> @others: due to the importance of it for us, I'm currently trying to >> implement it, but because that's my first deeper view in dovecots >> code, maybe I'll need some help. > the patch for 2.3.17.1 is attached. > > please let me know, if you're integrating it, because then I'll send > the patch for the old version to the devuan/debian-maintainers for > integration, so that we can update normally again. > Thanks for implementing a patch to be more privacy-aware! In Postfix many privacy-friendly submission servers do the following: === header_checks = pcre:/etc/postfix/header_checks === /^Received: from .*? \([\w-.]* \[.*?\]\)(.*)/ REPLACE Received: from [127.0.0.1] (localhost [127.0.0.1])$1 /^User-Agent:/ IGNORE /^X-Enigmail:/ IGNORE /^X-Mailer:/ IGNORE /^X-Originating-IP:/ IGNORE /^X-PHP-Originating-Script:/ IGNORE === The Received-Header is still there, so you can see the receiving server and the date+time of the server, but the IP address has been anonymized by replacing it with 127.0.0.1, so the format of the Received:-line is still valid for parsers. And some fingerprintable headers have been removed, because an "X-Mailer" or "User-Agent" could tell the recipients if you are at work or at home for example, or they could learn that you use an outdated vulnerable MUA... It would be cool if the Dovecot-submission-server would also be able to remove headers like the ones above (or for example "X-Authenticated" which sometimes contains IP addresses or auth-usernames...). Michael
Sv: Force clients to use pgp encryption when sending email?
Another solution is to use for example Ciphermail to automatically encrypt mail server-side. In this way you don't need to reject non-encrypted mail, you can just make sure it gets encrypted before it leaves premises. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Austin Witmer Skickat: den 8 december 2021 07:15 Till: dove...@ptld.com; dovecot@dovecot.org Ämne: Re: Force clients to use pgp encryption when sending email? Thanks for that info! It’s just what I needed! > On Dec 7, 2021, at 8:35 PM, dove...@ptld.com wrote: > > >> >> Basically I want the server to check if the message being sent is encrypted >> with OpenGPG and either proceed or reject the message based on that criteria. > > > Postfix is your submission service so i think best to look that direction. If > there is a header you can check for (if the header exist then allow sending) > then postfix has header checks regexp/pcre that would be simple enough to > setup. > > On the more complex side, postfix also supports policy servers you can write > as a script (php, perl, python, etc) or you can go full on milter. > > > http://www.postfix.org/header_checks.5.html > http://www.postfix.org/SMTPD_POLICY_README.html > http://www.postfix.org/postconf.5.html#non_smtpd_milters
RE: IPv4/v6 based access checking and logging
If yore gonna check for IP, you should do it in pre-login so you can reject the username/password combo if the registred IP of account does not match.But guess its better to write a custom login handler for that, that also checks user's ip against database, in addition to username/password, and tells client username/password is wrong if IP is unauth.. Originalmeddelande Från: Lefteris Tsintjelis Datum: 2021-11-12 18:48 (GMT+01:00) Till: dovecot@dovecot.org Ämne: IPv4/v6 based access checking and logging Hi,I am currently using postfix/dovecot with postfix admin and I track the last login date already by using this:https://doc.dovecot.org/configuration_manual/lastlogin_plugin/Besides last login date, I would like to also implement IPv4 and IPv6 last login tracking also and if possible, IP based login checking. Is post-login scripting the best most efficient way to go?Regards,Lefteris
Re: Sv: 2FA/MFA with IMAP & postfix/submission
Problem is that not many client support it - especially mobile ones.So wireguard VPN is the way to go, much simpler for the users. Originalmeddelande Från: Rick Romero Datum: 2021-07-15 17:04 (GMT+01:00) Till: dovecot@dovecot.org Ämne: Re: Sv: 2FA/MFA with IMAP & postfix/submission Quoting Alex : Hi, Unfortunately the best way to do multifactor authentication today is to use OAUTH2, which isn't currently supported for own installations. Or you can use client certs. If you want to use some kind of MFA with tokens, you end up having to feed your token all the time. So the best option, for now, is device passwords. Client certs appears to be a good solution. What's the process for managing them with more than a hundred client accounts? I believe the problem they are trying to solve is hacked accounts from compromised passwords. Does client certs solve that problem? Client certs would solve that - but you'll need some management around it (creation/deployment/renewal/device changes/etc). The easiest method is to run MDM and PKI infrastructure, but with 100 clients I kinda doubt that's in place and I wonder if they have the budget for it. Another option, not open source, but if you engage Recorded Future, you can get a report and notifications of password compromises, and then take action on that info (ie, force affected user to change password). Alternatively, and free, don't use the email address as the username for authenticaiton, use some other generic ID. Rick smime.p7s Description: S/MIME Cryptographic Signature
SV: SV: Looking for a guide to collect all e-mail from the ISP mail server
>>Whatever Gmail wants is essentially a defacto standard. Gmail have solved it with a Oauth authorization scheme. Basically, first time setting up mail, you are asked to authenticate by 2FA in a webview, then a shared secret is established, that is used during SMTP and IMAP time. Both Hotmail and Gmail is using this hackish webview solution for Outlook integration (and integration in some other email clients). Thats why Google and Microsoft have their own buttons inside Outlook and some other mail clients. smime.p7s Description: S/MIME Cryptographic Signature
SV: Looking for a guide to collect all e-mail from the ISP mail server
>>EU have very strict laws on the security of email and the requirement to keep it archived and to ensure the data cannot get out. No. GDPR is very organization-specific, meaning that a small organization or non-profit with 5 employees, don't need the same security as a 100 employee multi-million dollar organization. They were going to require small companies and even private persons processing data outside of the "personal space" limitation, to have the same sort of physical and digital security as any multi-billion dollar corporation, and require those that cannot cash up for such security, to only use hosted cloud services and rented centrally-managed computers without any own IT department. Of course, they dropped that idea, because it was not fair against small companies. They changed the ruling so the amount of security you need, is dependant on how much people is at risk if the emails leak, and what type of content the email has (if it has sensitive data, requirements are higher). But also, export of data to third-world countries is not permitted at all, regardless of organization size, due to the data losing legal protection (if someone outside EU leaks the data, you cannot hold someone responsible), unless specific requirements are met. This means, a somewhat maintained mail server, physically located at a company, is much better than using a hosted cloud service, as the cloud services usually take extra payment to keep the data inside EU. Same with the rulings on security bulletins - if you have a multi-billion dollar company then you are expected to apply security fixes and patches, even on a Saturday night. They are obliged by EU law to have alarms that wake them up on any major security bulletin regarding any of the server software. For a small non-profit or family company - its OK to wait until business hours with that - if that leads to the server being hacked - its okay. You did what you could. Novody expects you to be available 24/7 to patch 0-days. So its totally dependand on what type of organization you run, and the size - that govern how much security you need. And no, you don't need an UPS or backuped ISP connections, unless you run something mission critical. Most mailservers will queue mails for several days, so if your mailserver disappear for 1-2 days, it don't matter. The "availability" requirements of GDPR only applies to society-cricical services where it can actually cause harm to end-users if a service is down. If its just a small non-profit with 5 employees, GDPR is not gonna care because the email server was down for a day or two. smime.p7s Description: S/MIME Cryptographic Signature
SV: Looking for a guide to collect all e-mail from the ISP mail server
1: I meant like this: Without whitelisting, you can't login to SMTP or IMAP, password isn't valid at all. To enable SMTP and IMAP, you then either surf ro webmail, or the 2FA gateway, and login with: Username + password + 2FA code + captcha. When all is valid, then your IP is whitelisted for SMTP and IMAP access. This still means you have to use usename/password for SMTP/IMAP. So how would this be a security hole? Instead of using only username+password for SMTP/IMAP? The whitelisting procedure ADDS to the security. The baseline security with username+password is already there, but now you ALSO need a whitelisted IP to even get a chance to authenticate. Kind of stupid that there doesn't exist some common standard for 2FA that works in email clients. Some clients do support TLS client certificates, and some clients do support certain "extensions" for 2FA auth. But only common supported in all clients is password auth without 2FA, which is pretty insecure. Outlook have solved 2FA auth with a webview that uses OAUTH to create a authentication token, for use with SMTP/IMAP using some proprietary extension with gmail and hotmail. But that webview is not something you can trigger from a third party service. Captcha is there to prevent bruteforcing. If a valid captcha is submitted along with a 2FA code, you could lock out the account for 1 minute for each invalid attempt. If a invalid captcha is submitted, you ignore the request completely. This then prevents a attacker from flooding the server with invalid auth requests for the sole purpose of keeping a user locked out. (Account Lockout DDoS attack) I had problems with my mail password getting hacked all the time. The instant I added IP whitelist to my system and blocked all non-approved IPs from authenticating at all (so you must have username + password + correct IP to gain access) - then all hacking of my passwords have stopped. IP lockout was the solution to my problems. 2: The idea with the reverse-proxy gateway, is only to prevent auth-bypass or non-authenticated security holes. If you have a web service that has a suspected vulnerability that could be used without authenticating, or could be used to bypass authentication, then you put a reverse proxy in front. The reverse proxy does the authentication, and only forwards requests belongning to authenticated users. Even if the webservice behind, has a auth-bypass hole, it cannot be exploited, as the reverse proxy is behind the service, and non-authenticated users cannot even touch the webservice at all. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För @lbutlr Skickat: den 27 oktober 2020 15:57 Till: dovecot mailing list Ämne: Re: Looking for a guide to collect all e-mail from the ISP mail server On 25 Oct 2020, at 22:47, Sebastian Nielsen wrote: > The second way, is to not have webmail at all, but instead have a authentication gateway in browser, where you must auth with 2FA and captcha. The only purpose of this gateway, is to authenticate users with 2FA before their IP is whitelisted. I mostly agree with the sentiments in your email, but whitelsiting IP addresses is a HORRIBLE idea and a massive gaping security hole and using a captcha is only slightly less horrible and user-hostile. If you are using 2FA there is absolutely no reason to use a captcha. A 2FA gateway that reverse proxies the webmail is quite good, but enforcing good passwords and using TLS is good enough for nearly all use cases. (I recently upped the minimum password length from 12 characters) -- Ah we're lonely, we're romantic / and the cider's laced with acid / and the Holy Spirit's crying, Where's the beef? / And the moon is swimming naked / and the summer night is fragrant / with a mighty expectation of relief smime.p7s Description: S/MIME Cryptographic Signature
SV: Looking for a guide to collect all e-mail from the ISP mail server
>> Running an unmaintained mail server is a BAD thing. Of course. You maintain it. >>I think you are confusing gmail and google apps (or whatever it is called now, seems to change all the time). Google apps uses the same restrictions. What I recall, you can disable SPF and DKIM checks for trusted sources, but you cannot disable reputation checks. >>Wow. That sounds sooper not secure. How? Of course, you must have some sort of secure communication between the access controller system, and the system that manages logins for the computers and such. Then when you scan the badge at your personal office space (where only you have access), the access controller tells the system to automatically logon the computer. Another way is to have a RFID card reader where you put the badge to login computer, and remove badge to logout. Also a easy and secure system, but requires lots of integration work if you want to use it with third-party services. If you have own in-house servers, you can just tell those servers to check on-the-fly with the access control system if there is a valid card on the reader before giving computer X access to account Y - making it secure, since you can then not tamper with anything to bypass the auth check - the server, which is located in secure space, formally asks the access controller "master", which is also located in secure space, if user X is authenticated at reader Y. >>You cannot keep a mail server automatically updated, sorry. That is a fantasy. You can. Ubuntu have packages with mail servers automatically updated. However, sometimes manual intervention is required to change the config when some security holes appear that cannot be resolved with patches. smime.p7s Description: S/MIME Cryptographic Signature
SV: SV: Looking for a guide to collect all e-mail from the ISP mail server
Because when I email to friends that are using gmail, my mail ends up in spam unless my friends put me in whitelist. Seems to vary however, and seems to get better with time. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Marc Roos Skickat: den 26 oktober 2020 09:07 Till: dovecot ; sebastian Ämne: RE: SV: Looking for a guide to collect all e-mail from the ISP mail server > and also the problem is that gmail imposes heavy spam filters and "reputation blocks" > meaning smaller providers with low email volumes, are put in the spam folder, even if > they never send spam, just because their email volume is so low (ergo, they must > prove they don't spam before getting out of ispam folder) How do you know that? smime.p7s Description: S/MIME Cryptographic Signature
SV: Looking for a guide to collect all e-mail from the ISP mail server
>> why not just point them at a hosting service like google apps, and let google keep things up to date? Costs money, and also the problem is that gmail imposes heavy spam filters and "reputation blocks" meaning smaller providers with low email volumes, are put in the spam folder, even if they never send spam, just because their email volume is so low (ergo, they must prove they don't spam before getting out of ispam folder) Another thing is that you cannot impose IP restrictions when using Google Apps, or have SSO with trusted access from inside the office. (for example - scan your badge at the office door, your personal computer is automatically logged on and you get access to everything). With locally hosted servers, of course you have to keep them updated. Most linux distributions can keep them updated automatically. smime.p7s Description: S/MIME Cryptographic Signature
SV: Looking for a guide to collect all e-mail from the ISP mail server
>>"Never use a browser for email." I don't agree. In fact, using a browser for email or atleast initial setup, is actually more secure. This because SMTP/IMAP clients normally don't support 2FA, so you would have to "hack" a solution to enable 2FA for email. This can be made in 2 ways: Either, you have a full fledged email setup. Whats important, is, to prevent auth-bypass holes, you remove the authentication in RoundCube or whatever webmail you use, and instead use a reverse-proxy or firewall authentication instead. Thus an unauthenticated user doesn't even touch RoundCube/webmail at all, but must authenticate at a prior stage. The second way, is to not have webmail at all, but instead have a authentication gateway in browser, where you must auth with 2FA and captcha. The only purpose of this gateway, is to authenticate users with 2FA before their IP is whitelisted. After this, you simply have a script, that upon valid login (with 2FA) in either webmail or auth gateway, you set the authorized IP of the user to this. Whats happen then, is that each account will have an authorized IP attached (you could limit it to the /24 to cater for mobile clients), and then login to that account, will only be accepted from that authorized IP. This then allows SMTP/IMAP usage from that IP. If you want to go even more secure, you could restrict the firewall to the list of all IPs that all users have dynamically, and then in the SMTP/IMAP server, lock down auth to the authorized IP of that particular user account only. Its very important, that upon authing with a incorrect IP, that the server responds in the same way as a invalid password was specified, in this way, if someone attempts to bruteforce the password, they will "miss" the correct password, if the server does not react differently to a correct password but invalid IP. Thus bots that bruteforce will not gain any success. All this can be combined with permanent whitelists and geoIP whitelists, to avoid users having to authenticate with 2FA for "trusted" locations. One example would be to have the local office as permanent whitelist, and also have it that any IP in the user's "home country" is permanently whitelisted for his account once the user authenticates with 2FA. Other IPs outside his home country, is then only whitelisted once, next 2FA login, the old whitelist is simply deleted. smime.p7s Description: S/MIME Cryptographic Signature
SV: forwarding email with sieve of spf domains
He of course meant the From: MIME sender. This can fail in a SPF check if identity aligment is set to strict. Rewriting the From: heasder is one way to solve it, another way which preserves the original message in full, is to encapsulate the original message ina new message/rfc822 container where the new outer container, does have the rewritten details. Från: dovecot-boun...@dovecot.org För Scott Q. Skickat: den 25 oktober 2020 17:02 Till: Marc Roos ; dovecot Ämne: Re: forwarding email with sieve of spf domains There's no ambiguity here, if you send a message, you are the sender. The envelope from should be yours. On Sunday, 25/10/2020 at 11:48 Marc Roos wrote: Say someone has setup spf for his domain and sends an email to a user that has in roundcube enabled the sieve forward. If the message is forwarded without altering the message headers, this could result in a message being blocked or not relayed, because sending hosts ip, is not in the spf of the from: domain. Possible solutions are: - add option if enabled, it replaces the From: with that of the email address of the sieve user. (Maybe move the original sender to the Reply-To header? Maybe exception for 'internal' forward?) - Upon processing the message, check the spf records, if they are enforced, do the above, otherwise do nothing. https://tools.ietf.org/html/rfc5228#section-4.2 smime.p7s Description: S/MIME Cryptographic Signature
SV: forwarding email with sieve of spf domains
Yes, putting the From: into Reply-To: is a good idea to ensure the reply button in receiver´s client doesn't break. But remember to ONLY do it when Reply-To: is not present. To avoid removing important information from the email, like the original sender, it can be good to always add a header like X-Original-Sender with the original from: when rewriting in this way. OTOH I think this type of rewriting should be done in the MTA that is responsible for sending the email off the server, NOT in dovecot/sieve. In exim theres already built-in support for this type of rewriting, and I have such rewriting on all domains for which are forward-only - to avoid SPF errors. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Marc Roos Skickat: den 25 oktober 2020 16:49 Till: dovecot Ämne: forwarding email with sieve of spf domains Say someone has setup spf for his domain and sends an email to a user that has in roundcube enabled the sieve forward. If the message is forwarded without altering the message headers, this could result in a message being blocked or not relayed, because sending hosts ip, is not in the spf of the from: domain. Possible solutions are: - add option if enabled, it replaces the From: with that of the email address of the sieve user. (Maybe move the original sender to the Reply-To header? Maybe exception for 'internal' forward?) - Upon processing the message, check the spf records, if they are enforced, do the above, otherwise do nothing. https://tools.ietf.org/html/rfc5228#section-4.2 smime.p7s Description: S/MIME Cryptographic Signature
SV: SV: How to Modify Message and add more Attachments
Agree completely. Sending data to third party requires a processing agreement yes. Its even enough that a third party has administrative access to the server (and thus potentially have access to data) - then a processing agreement is required. When the data leaves EU, then its prohibited in many cases as you can't fine a company in for example iran for have disclosed details to a fourth party, thus disclosing to a third-party outside EU is prohibited even with a data processing agreement. You are also correct that they can't send these files to facebook or Google. What I wanted to point out, is that when people hear the word "email" they think a large can of GDPR worms is opened, but as long as email is done right, with restricted access and encrypted transfer and for sensitive things - a restriction so email can only be internally sent, all external domains blocked/prohibited, you can even use email to send super sensitive details. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Marc Roos Skickat: den 6 oktober 2020 23:42 Till: dovecot ; sebastian Ämne: RE: SV: How to Modify Message and add more Attachments > >Thats because in your example the data is sent outside the facility to a third party (in this case, wetransfer/outlook) And wetransfer/outlook is operated in third countries, which can cause GDPR problems as the legal protection for the data disappears. > That is just a part. We had to sign such agreement between companies in the same country, city even. Data is not even leaving the country. Putting personal data at a third party requires a processing agreement. >The OP were asking about a solution which modifies email which have already been received in a local, secure facility to add the voice mail to locally stored messages. >Thats not prohibited. That has not been questioned, sending that data to google is being questioned. >Imagine if the OP has a SIP server and email server inside the same physical machine. Do you really think it would be prohibited to move a file from "asterisk/vm" to "var/spool/mail/"? No because it belongs to the expected necessary processing activities of a voip provider. This voip provider cannot just send these files to facebook that is easy to understand. So you can not send these files to google as well. Does not matter if they have some fancy AD processing api. >The security for the data is the same regardless of which format is used. Obviously smime.p7s Description: S/MIME Cryptographic Signature
SV: How to Modify Message and add more Attachments
Thats because in your example the data is sent outside the facility to a third party (in this case, wetransfer/outlook) And wetransfer/outlook is operated in third countries, which can cause GDPR problems as the legal protection for the data disappears. The OP were asking about a solution which modifies email which have already been received in a local, secure facility to add the voice mail to locally stored messages. Thats not prohibited. Imagine if the OP has a SIP server and email server inside the same physical machine. Do you really think it would be prohibited to move a file from "asterisk/vm" to "var/spool/mail/"? The security for the data is the same regardless of which format is used. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Marc Roos Skickat: den 6 oktober 2020 23:23 Till: dovecot ; msharma Ämne: RE: How to Modify Message and add more Attachments I have clients that process personal data and they even need to have 'special' processing agreements with companies like wetransfer and outlook.com. I had to sign also such agreement and prepare a vm for hot/cold data encryption for processing personal data. If someone leaves a voice mail message, he does not expect that this is going to be send to a third party. I think this expectation causes the gdpr 'by default' highest privacy/security of personal data protection to be applicable. Lots of companies are being fined currently for breaching gdpr, small, large, international even nation governmental organisations. Better check this. -Original Message- Subject: RE: How to Modify Message and add more Attachments Can you elaborate on the concern? -Original Message- From: Marc Roos Sent: Tuesday, October 6, 2020 4:17 PM To: dovecot ; Mrinal Sharma Subject: RE: How to Modify Message and add more Attachments CAUTION - EXTERNAL EMAIL This email originated from outside of Smith Micro Software. Do not click links or open attachments unless you recognize the sender and know the content is safe. If are processing Europeans voice mail you have to check if that is even allowed, could be a problem with GDPR legislation. -Original Message- Subject: RE: How to Modify Message and add more Attachments Thanks, am planning to use Google's Speech-to-Text. -Original Message- Sent: Tuesday, October 6, 2020 3:39 PM To: dovecot ; Mrinal Sharma Subject: RE: How to Modify Message and add more Attachments CAUTION - EXTERNAL EMAIL This email originated from outside of Smith Micro Software. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hmmm, that does not sound nice storing files as email. Maybe use document database? Look at this[1], see if it is possible to use the rados plugin to store files directly as objects? What are you using for speech to text? [1] https://github.com/ceph-dovecot/dovecot-ceph-plugin -Original Message- To: dovecot@dovecot.org Subject: How to Modify Message and add more Attachments Hello Everyone, I am working on a product in which we are planning to store voice messages in Dovecot sent by a user to another user. The message would be stored as an email with .wav attachment. Once the Voice message is received, it may get Transcribed. The message can be further be processed and more information can be added to the message later. The original plan was to Modify the email and add New information as attachments to same message. As I understood, messages stored in Dovecot are immutable. What is the best option to achieve this functionality? Thanks, Mrinal smime.p7s Description: S/MIME Cryptographic Signature
SV: How to Modify Message and add more Attachments
No. Many think that sensitive data is prohibited to process/store as email at all, but thats not true. What can be prohibited, is sending sensitive data as email, ergo letting it leave as SMTP email, depending on circumstances, because that might mean that the sensitive data is sent unencrypted. Or that unauthorized individuals (like the remote email administrator at the receiver) has access to the data. Injecting sensitive data directly into an email system by internal means, is as allowed as saving the sensitive data as word documents or similiar. Just because you use .eml format of the storage doesn't mean its prohibited. What this means, is that if you do inject GDPR sensitive data into an email system, then the email system may need additional security, like local at-rest encryption at the server and maybe an additional VPN layer with 2FA to access the email server. It depends on how sensitive the data stored is, and you might need routines to auto-delete data from the emails once the storage period is over. The biggest problem with using email as GDPR data storage, is if you allow any email adress to be used, the data could end up outside of EU (third country) if the employee's provider is located there which is prohibited. But here its about using email FORMAT as storage only. Or to make it more blunt: Sending sensitive info as postcards may be prohibited depending on circumstances, but converting mail sent securely into postcards when they have arrived into the secure facility, is usually no problem at all - it depends on how you store them afterwards. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Marc Roos Skickat: den 6 oktober 2020 22:17 Till: dovecot ; msharma Ämne: RE: How to Modify Message and add more Attachments If are processing Europeans voice mail you have to check if that is even allowed, could be a problem with GDPR legislation. -Original Message- Subject: RE: How to Modify Message and add more Attachments Thanks, am planning to use Google's Speech-to-Text. -Original Message- Sent: Tuesday, October 6, 2020 3:39 PM To: dovecot ; Mrinal Sharma Subject: RE: How to Modify Message and add more Attachments CAUTION - EXTERNAL EMAIL This email originated from outside of Smith Micro Software. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hmmm, that does not sound nice storing files as email. Maybe use document database? Look at this[1], see if it is possible to use the rados plugin to store files directly as objects? What are you using for speech to text? [1] https://github.com/ceph-dovecot/dovecot-ceph-plugin -Original Message- To: dovecot@dovecot.org Subject: How to Modify Message and add more Attachments Hello Everyone, I am working on a product in which we are planning to store voice messages in Dovecot sent by a user to another user. The message would be stored as an email with .wav attachment. Once the Voice message is received, it may get Transcribed. The message can be further be processed and more information can be added to the message later. The original plan was to Modify the email and add New information as attachments to same message. As I understood, messages stored in Dovecot are immutable. What is the best option to achieve this functionality? Thanks, Mrinal smime.p7s Description: S/MIME Cryptographic Signature
RE: 2 factor authentication
Yes, but not many client support it. Use a IP locking solution instead, where the 2FA solution is used to approve IPs for the account instead. Originalmeddelande Från: The Doctor Datum: 2020-08-24 14:07 (GMT+01:00) Till: dovecot@dovecot.org Ämne: 2 factor authentication Is 2 factor authentication possible on dovecot?-- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.caYahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b New Brunswick Save The PRovince Vote Liberal 14 Sept!! smime.p7s Description: S/MIME Cryptographic Signature
SV: Outlook vs Thunderbird (re disabling SSL)
>>Actually, there is a regedit "trick" for Win7 but that is beyond the ability >>of our customers to apply, and that doesn't help the older Apple device users. You could build a .reg file with the trick inside, and then distribute it to your users. However it wont solve the Apple problem. smime.p7s Description: S/MIME Cryptographic Signature
SV: SV: Outlook vs Thunderbird
Sorry about that, its just outlook that does that by default. But manually deleted your adress now in reply. I don't know what you mean with "top posting"? What I mean is that if you have another security on the connection (be it physical security - the connection doesn't go over public means, or VPN - connection level encryption) then you don't need another encryption on top of that. Of course you must judge other risks in the physical enviroment - if a hacker connects his laptop to a guest wifi or reception RJ45 port and ARP spoofs - whats gonna happen? So you must of course segment and separate those networks from your internal LAN (so a hacker is now gonna need a access badge to even get a foot into the internal LAN), and also activate static ARP in your switches so even if a hacker ARP spoofs (from an infected client inside internal LAN), nothing gonna come out of the pipe. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Alexander Dalloz Skickat: den 7 juli 2020 18:30 Till: dovecot@dovecot.org Ämne: Re: SV: Outlook vs Thunderbird Am 07.07.2020 um 18:11 schrieb Sebastian Nielsen: > Plaintext access is no problem if the connection is secured via other means - > for example internal network or VPN. > If the IMAP server cannot be accessed from the outside, and the traffic don't > travel over wifi or public networks, no danger. First of all, please keep answers on the mailing list only. Obviously I am subscribe and I don't need to get your reply twice, by list distribution and in addition to my personal address. And top-posting is another thing you should avoid. To your answer: I disagree and see that you have a false understanding of security. You want service protocol encryption (here for IMAP or POP3) from end to end. Nothing which breaks up encryption in between. That's valid for any size of environment. You may judge the risk is tolerable in case you run you own small setup where you are the only user. But I replied to Mark's note where he wrote about ~100 clients. So he either running an IMAP service for clients - where it is inresponsible to not teach them about security and instead lower the protection to none - or administering a company network for which end to end service encryption is a must too. Alexander smime.p7s Description: S/MIME Cryptographic Signature
SV: Outlook vs Thunderbird
Plaintext access is no problem if the connection is secured via other means - for example internal network or VPN. If the IMAP server cannot be accessed from the outside, and the traffic don't travel over wifi or public networks, no danger. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Alexander Dalloz Skickat: den 7 juli 2020 18:05 Till: dovecot@dovecot.org Ämne: Re: Outlook vs Thunderbird Am 07.07.2020 um 08:07 schrieb Mark Constable: > > FWIW I meant if the client is Windows7/old-Outlook then changing > either 993/SSL or 143/STARTTLS to 143/NONE could help pick up the > mail. We had to do this for a 100 or so clients a few months ago after > upgrading to Ubuntu 20.04. Curious, what's the rationale behind that move? Is it because that old beast of Outlook does not have the capabilities modern TLS/STARTTLS implementations require regarding TLS minimal version and ciphers? But plaintext auth for mail access, seriously? Alexander smime.p7s Description: S/MIME Cryptographic Signature
SV: handling spam from gmail.
This is not a job for dovecot. You should look into whatever is your MTA (exim, postfix etc) and implement the solution there. But my initial suggestion is to check SPF and DKIM of the email. Because I know that gmail does terminate spammers quick, but if you don't validate SPF or DKIM, you might be a victim of spoofed Gmail email. Best regards, Sebastian Nielsen -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Marc Roos Skickat: den 11 juni 2020 10:21 Till: dovecot ; users Ämne: handling spam from gmail. I am sick of this gmail spam. Does anyone know a solution where I can do something like this: 1. received email from adcpni...@gmail.com 2. system recognizes this email address has been 'whitelisted', continue with 7. 3. system recognizes as this email never been seen before 4. auto reply with something like (maybe with a wait time of x hours): Your message did not receive the final recipient. You are sending from a known spam provider network that is why we blocked your message. Please confirm that: - you are not a spammer and - you have permission to use the mail adress you send your message to - you and your provider agree to uphold GDPR legislation - you and your provider are liable for damages when breaching any of the above. Click link to confirm and you agree with the above https://www.domainwithoutletsencryptcertificate.com/asdfasdfadsfaf 5. sender clicks confirm url 6. email address is added to some white list. 7. email is delivered to recipient. smime.p7s Description: S/MIME Cryptographic Signature
SV: What causes mails to get striked-over only, and not deleted?
Thanks. That solved the problem. Finally got rid of all duplicate items in sent folder. (Because of some mail clients not supporting disabling "Save a copy in sent folder when sending"). But why isn't this documented in the documentation? https://wiki2.dovecot.org/Pigeonhole/Sieve/Plugins/IMAPSieve -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Robert L Mathews Skickat: den 23 maj 2020 01:43 Till: dovecot@dovecot.org Ämne: Re: What causes mails to get striked-over only, and not deleted? On 5/22/20 4:01 PM, Sebastian Nielsen wrote: > and this sieve file (sent.sieve): > > discard; > > This should clearly cause the mail to be deleted right? > But whats happen, is that the mail is not deleted, its just marked for > deletion (gets a strike-through in Microsoft Outlook). That means the message has had its "\Deleted" flag set, which is what the discard command does: https://tools.ietf.org/html/rfc6785#section-3.5 But the mailbox has not been "expunged". You probably want to set "imapsieve_expunge_discarded=yes"; see: https://github.com/dovecot/pigeonhole/blob/master/doc/plugins/imapsieve.txt#L125 -- Robert L Mathews, Tiger Technologies, http://www.tigertech.net/ smime.p7s Description: S/MIME Cryptographic Signature
What causes mails to get striked-over only, and not deleted?
I have tried with this sieve config: imapsieve_mailbox1_name = Sent imapsieve_mailbox1_causes = COPY APPEND imapsieve_mailbox1_after = file:/etc/dovecot/sieve/sent.sieve and this sieve file (sent.sieve): discard; This should clearly cause the mail to be deleted right? But whats happen, is that the mail is not deleted, its just marked for deletion (gets a strike-through in Microsoft Outlook). (have tried with _before too, but it wont help). What can I do to ensure the mail actually gets deleted (completely, not moved to trash) and not just flagged for deletion? smime.p7s Description: S/MIME Cryptographic Signature
SV: SV: Marking all emails in "Trash" as opened, and also prohibiting email clients from creating ne
t;3385220>: Info:
Connection closed (CLOSE finished 0.010 secs ago) in=160 out=1192 deleted=0
expunged=0 trashed=1 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0
May 10 03:53:44 imap(sebast...@sebbe.eu)<3385185>: Debug:
Mailbox Trash: Mailbox opened because: SELECT
May 10 03:53:44 imap(sebast...@sebbe.eu)<3385185>: Debug:
Mailbox Trash: UID 1190: Opened mail because: full mail
Then in trash, its still unread.
-Ursprungligt meddelande-
Från: dovecot-boun...@dovecot.org För Mark
Constable
Skickat: den 10 maj 2020 03:48
Till: dovecot@dovecot.org
Ämne: Re: SV: Marking all emails in "Trash" as opened, and also prohibiting
email clients from creating ne
On 10/5/20 3:33 am, Sebastian Nielsen wrote:
> And then this in plugins.conf:
>
> plugin {
>sieve_plugins = sieve_imapsieve
>imapsieve_mailbox1_name = Trash
>imapsieve_mailbox1_before = file:/etc/dovecot/sieve/trash.sieve
> }
Maybe adding this will help...
imapsieve_mailbox1_causes = COPY FLAG
smime.p7s
Description: S/MIME Cryptographic Signature
SV: Marking all emails in "Trash" as opened, and also prohibiting email clients from creating new ma
Another problem, is that running discard; on the Sent folder, just marks the
email for deletion - ergo it gets a strike-through.
It doesn't get deleted.
Tried with both Before and After.
Otherwise, the discard; on Sent folder works fine - ergo it only selects
emails that were written through IMAP, it doesn't select emails written from
appendfile in exim4, which is good.
So now I somehow need to get exim4 to actually delete the email completely
and not just mark it for deletion.
-Ursprungligt meddelande-
Från: Sebastian Nielsen
Skickat: den 9 maj 2020 19:33
Till: dovecot@dovecot.org
Ämne: SV: Marking all emails in "Trash" as opened, and also prohibiting
email clients from creating new ma
I tried with following:
require ["imap4flags"];
if not hasflag :is "\\Seen" {
setflag "\\Seen";
}
And then this in plugins.conf:
plugin {
sieve_plugins = sieve_imapsieve
imapsieve_mailbox1_name = Trash
imapsieve_mailbox1_before = file:/etc/dovecot/sieve/trash.sieve
}
It works in outlook, the mail is opened (mark as read) when it goes to
trash.
But in Samsung Email it doesn't work.
(or it works when I select in Samsung email, "Move to Folder" and then
"Trash", but if I select "Delete", the mail is trashed without becoming
read)
(I have checked, the sieve script gets executed)
-Ursprungligt meddelande-
Från: dovecot-boun...@dovecot.org För Marc
Roos
Skickat: den 9 maj 2020 18:30
Till: dovecot
Ämne: RE: Marking all emails in "Trash" as opened, and also prohibiting
email clients from creating new ma
Someone just told me about imapsieve. Sieve rules for folders. I assume
that could solve your issue.
https://wiki.dovecot.org/HowTo/AntispamWithSieve
-Original Message-
Sent: 09 May 2020 17:32
To: dovecot@dovecot.org
Subject: Marking all emails in "Trash" as opened, and also prohibiting
email clients from creating new mails
Dovecot version: 2.3.7.2 (3c910f64b)
(pkg shipped by: Ubuntu-Desktop 20.04)
I want to accomplish 2 things in dovecot:
1:
I want to force all mails inside Trash to have an "opened"/"read" flag
and "Non-Recent" flag. Basically Status: RO This regardless how the flag
appears, either by copying/moving the mail into trash, creating a new
mail in trash, flagging email in Trash or whatever.
Basically, no email in Trash should ever be able to have a recent or
unread flag.
I tried with a static mail filter and sieve filter to add \\seen to the
email upon COPY (as mentioned here:
https://dovecot.org/pipermail/dovecot/2017-November/110122.html ), but
regardless how I do it, it doesn't work when Samsung Email client
trashes an unread email, AND/OR also, it causes weird issues like
duplicate email in the trash folder sometimes.
Best would be some event filter that executes for every mail that
somehow end up in Trash, that checks if \\seen is present, if not, then
it will add it, on all emails in trash? But how I do to prevent the
duplicate copy that appears sometimes?
2:
I want to prohibit email clients from ever creating a new mail in Sent
folder.
If its possible to allow MOVE and/or COPY, it should be allowed, only
new mail should be prohibited.
(also note that external processes must be able to create new mail in
Sent)
HOWEVER - this prohibition must be silent - ergo the newly created email
is simply discarded. No error message or error codes should be returned
to IMAP client.
(The reason I want this, is because I have configured my outgoing SMTP
server to populate Sent, and some email clients doesn't have the option
to "Don't store a copy of the email in Sent folder" resulting in
duplicates)
Best regards, Sebastian Nielsen
smime.p7s
Description: S/MIME Cryptographic Signature
SV: Marking all emails in "Trash" as opened, and also prohibiting email clients from creating new ma
I tried with following:
require ["imap4flags"];
if not hasflag :is "\\Seen" {
setflag "\\Seen";
}
And then this in plugins.conf:
plugin {
sieve_plugins = sieve_imapsieve
imapsieve_mailbox1_name = Trash
imapsieve_mailbox1_before = file:/etc/dovecot/sieve/trash.sieve
}
It works in outlook, the mail is opened (mark as read) when it goes to
trash.
But in Samsung Email it doesn't work.
(or it works when I select in Samsung email, "Move to Folder" and then
"Trash", but if I select "Delete", the mail is trashed without becoming
read)
(I have checked, the sieve script gets executed)
-Ursprungligt meddelande-
Från: dovecot-boun...@dovecot.org För Marc
Roos
Skickat: den 9 maj 2020 18:30
Till: dovecot
Ämne: RE: Marking all emails in "Trash" as opened, and also prohibiting
email clients from creating new ma
Someone just told me about imapsieve. Sieve rules for folders. I assume
that could solve your issue.
https://wiki.dovecot.org/HowTo/AntispamWithSieve
-Original Message-
Sent: 09 May 2020 17:32
To: dovecot@dovecot.org
Subject: Marking all emails in "Trash" as opened, and also prohibiting
email clients from creating new mails
Dovecot version: 2.3.7.2 (3c910f64b)
(pkg shipped by: Ubuntu-Desktop 20.04)
I want to accomplish 2 things in dovecot:
1:
I want to force all mails inside Trash to have an "opened"/"read" flag
and "Non-Recent" flag. Basically Status: RO This regardless how the flag
appears, either by copying/moving the mail into trash, creating a new
mail in trash, flagging email in Trash or whatever.
Basically, no email in Trash should ever be able to have a recent or
unread flag.
I tried with a static mail filter and sieve filter to add \\seen to the
email upon COPY (as mentioned here:
https://dovecot.org/pipermail/dovecot/2017-November/110122.html ), but
regardless how I do it, it doesn't work when Samsung Email client
trashes an unread email, AND/OR also, it causes weird issues like
duplicate email in the trash folder sometimes.
Best would be some event filter that executes for every mail that
somehow end up in Trash, that checks if \\seen is present, if not, then
it will add it, on all emails in trash? But how I do to prevent the
duplicate copy that appears sometimes?
2:
I want to prohibit email clients from ever creating a new mail in Sent
folder.
If its possible to allow MOVE and/or COPY, it should be allowed, only
new mail should be prohibited.
(also note that external processes must be able to create new mail in
Sent)
HOWEVER - this prohibition must be silent - ergo the newly created email
is simply discarded. No error message or error codes should be returned
to IMAP client.
(The reason I want this, is because I have configured my outgoing SMTP
server to populate Sent, and some email clients doesn't have the option
to "Don't store a copy of the email in Sent folder" resulting in
duplicates)
Best regards, Sebastian Nielsen
smime.p7s
Description: S/MIME Cryptographic Signature
Marking all emails in "Trash" as opened, and also prohibiting email clients from creating new mails
Dovecot version: 2.3.7.2 (3c910f64b) (pkg shipped by: Ubuntu-Desktop 20.04) I want to accomplish 2 things in dovecot: 1: I want to force all mails inside Trash to have an "opened"/"read" flag and "Non-Recent" flag. Basically Status: RO This regardless how the flag appears, either by copying/moving the mail into trash, creating a new mail in trash, flagging email in Trash or whatever. Basically, no email in Trash should ever be able to have a recent or unread flag. I tried with a static mail filter and sieve filter to add \\seen to the email upon COPY (as mentioned here: https://dovecot.org/pipermail/dovecot/2017-November/110122.html ), but regardless how I do it, it doesn't work when Samsung Email client trashes an unread email, AND/OR also, it causes weird issues like duplicate email in the trash folder sometimes. Best would be some event filter that executes for every mail that somehow end up in Trash, that checks if \\seen is present, if not, then it will add it, on all emails in trash? But how I do to prevent the duplicate copy that appears sometimes? 2: I want to prohibit email clients from ever creating a new mail in Sent folder. If its possible to allow MOVE and/or COPY, it should be allowed, only new mail should be prohibited. (also note that external processes must be able to create new mail in Sent) HOWEVER - this prohibition must be silent - ergo the newly created email is simply discarded. No error message or error codes should be returned to IMAP client. (The reason I want this, is because I have configured my outgoing SMTP server to populate Sent, and some email clients doesn't have the option to "Don't store a copy of the email in Sent folder" resulting in duplicates) Best regards, Sebastian Nielsen smime.p7s Description: S/MIME Cryptographic Signature
