Re: No-novice with Dovecot, but need novice-like advice (was Dovecot cracked?!)
On 9/6/23 09:17, Richard Troy wrote: However if your dovecot SASL is broken, say always permitting access with or without correct password, then there will be a problem I DID find a discrepancy: smtpd_helo_restrictions did NOT have permit_sasl_authenticated. I made the change, of course and with that done, am now going to open the ports and renew my vigil for relays! Fingers crossed! Thanks, Jeremy - even if it doesn't work, it's a good clean shot at a fix! And, if that was it, it's easy to see how that could be overlooked. . . Richard smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination Is most useful to you. The defer means reject after a delay - tarpitting This leaves you to verify if the sasl authentication is working correctly. That is a real exercise as it has multiple config elements in dovecot and then PAM /etc/pam.d/dovecot then calls multiple configs in /etc/pam.d and specifically /etc/pam.d/common-auth in my case I am using only the local user database for dovecot grep -v '^#' common-auth auth [success=1 default=ignore] pam_unix.so nullok auth requisite pam_deny.so auth required pam_permit.so It is quite possible to use remote servers such as ldap and kerberos rather than your local user table ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: No-novice with Dovecot, but need novice-like advice (was Dovecot cracked?!)
Useful, thanks. ... May I then presume that port 587 should be going to Dovecot only and not Postfix? Otherwise, how was I supporting users with this configuration: No, you should not assume port 587 (or port 465) goes to Dovecot. Postfix has enough smarts to handle the authentication itself and many systems will be configured this way. Some systems may use the Dovecot submission proxy as a convenience. If Dovecot and Postfix are running on the same machine, the MUA would not be able to tell the difference. If that were true it'd still be happening because in "shutting down Dovecot", I merely closed off the ports at the firewall. So, there goes that theory. I couldn't draw any conclusion without knowing your network architecture (where the firewall sits) and what ports you closed. I figured that's what was happening, thanks - presuming you mean Dovecot IS the MSA for Postfix in this instance. Dovecot does not maintain a message queue for submissions and does not take responsibility for delivery, so I don't think it would be correct to call it the "MSA", it is just acting as a proxy. As an aside, you should consider the post from Jeremy Ardley and in particular, the Postfix setting "permit_sasl_authenticated". In many setups, Postfix will relay traffic from "trusted networks" or "authenticated users". It may well be that you do NOT have an open relay but simply that the spammers know one of your user's password. -- This email has been checked for viruses by AVG antivirus software. www.avg.com ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: No-novice with Dovecot, but need novice-like advice (was Dovecot cracked?!)
However if your dovecot SASL is broken, say always permitting access with or without correct password, then there will be a problem I DID find a discrepancy: smtpd_helo_restrictions did NOT have permit_sasl_authenticated. I made the change, of course and with that done, am now going to open the ports and renew my vigil for relays! Fingers crossed! Thanks, Jeremy - even if it doesn't work, it's a good clean shot at a fix! And, if that was it, it's easy to see how that could be overlooked. . . Richard ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: No-novice with Dovecot, but need novice-like advice (was Dovecot cracked?!)
The problem will likely be postfix. I actually doubt it but am VERY grateful for this remark: However if your dovecot SASL is broken, say always permitting access with or without correct password, then there will be a problem IT COULD BE?! I don't know (or maybe recall ATM) enough about it to comment. THANK YOU for your configuration exmaple! This I'll be on in just moments, thanks! Richard ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: No-novice with Dovecot, but need novice-like advice (was Dovecot cracked?!)
On Thu, 8 Jun 2023, dove...@x9p.org wrote: Logs? Send the relevant logs so people can analyze the problem. ...The logs in full are HUGE, but I have some excerpts - Hope I caught the right stuff! I'll send along soon. Richard ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: No-novice with Dovecot, but need novice-like advice (was Dovecot cracked?!)
On 9/6/23 07:25, Richard Troy wrote:
The relaying only started and stopped when Dovecot was turned on or off.
Isn't it true that Dovecot performs an authentication function for
inbound connect requests, the successful of which then may use the
submission mechanism from what Postfix takes to be an internal
connection to send emails? Is this mistaken?
However, I get your point and I've spent a lot of work on that area.
And, you may well be right that that's where I need to turn - that is,
to Postfix. Thanks for the link.
The problem will likely be postfix.
However if your dovecot SASL is broken, say always permitting access
with or without correct password, then there will be a problem
This is part of my postfix configuration aand my system doesn't relay.
The key lines are all those with
permit_sasl_authenticated
---
relay_domains = $mydestination
unknown_local_recipient_reject_code = 550
unknown_client_reject_code = 550
#home_mailbox = Maildir/
mailbox_transport = lmtp:unix:private/dovecot-lmtp
#transport_maps = hash:/etc/postfix/transport
# Junk controls
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_unknown_helo_hostname
# reject_rbl_client dnsbl-1.uceprotect.net
# reject_rbl_client cbl.abuseat.org
smtpd_recipient_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unauth_pipelining
reject_non_fqdn_recipient
reject_unknown_recipient_domain
reject_unauth_destination
permit
# reject_rbl_client zen.spamhaus.org
# reject_rbl_client bl.spamcop.net
smtpd_sender_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unknown_sender_domain
reject_unknown_reverse_client_hostname
reject_unknown_client_hostname
smtpd_data_restrictions =
reject_unauth_pipelining,
permit
strict_rfc821_envelopes = yes
disable_vrfy_command = yes
# Redirect mail
smtp_header_checks = regexp:/etc/postfix/smtp_header_checks
# Reduce the time Postfix will sit idle after a client issues STARTTLS.
smtpd_starttls_timeout = 60s
# Renegotiate TLS sessions every hour.
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
# Enable SMTP AUTH.
# This requires TLS on port 25
smtpd_sasl_auth_enable = yes
# Don't allow anonymous logins. DO NOT add noplaintext here, or
# authentication with saslauthd will become impossible.
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =
# Some clients send malformed AUTH commands.
broken_sasl_auth_clients = yes
# Only allow AUTH when a TLS session is active, to reduce the
# possibility for password and message body snooping.
smtpd_tls_auth_only = yes
# Tarpitting
smtpd_error_sleep_time = 50
smtpd_hard_error_limit = 2
smtpd_soft_error_limit = 1
smtpd_junk_command_limit = 10
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mailbox_size_limit = 0
recipient_delimiter = +
inet_protocols = all
compatibility_level = 3.6
policy-spf_time_limit = 3600s
html_directory = /usr/share/doc/postfix/html
# Milter configuration
milter_default_action = accept
milter_protocol = 6
smtpd_milters = local:opendkim/opendkim.sock
non_smtpd_milters = $smtpd_milters
smtputf8_enable = no
postscreen_access_list = permit_mynetworks
postscreen_blacklist_action = enforce
postscreen_greet_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = swl.spamhaus.org*-4
list.dnswl.org=127.0.[0..255].[1..3]*-5
zen.spamhaus.org=127.0.[1..2].[0..255]*3
b.barracudacentral.org*2
bl.spameatingmonkey.net
bl.spamcop.net
postscreen_dnsbl_threshold = 2
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
--
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: No-novice with Dovecot, but need novice-like advice (was Dovecot cracked?!)
The relaying only started and stopped when Dovecot was turned on or off. Isn't it true that Dovecot performs an authentication function for inbound connect requests, the successful of which then may use the submission mechanism from what Postfix takes to be an internal connection to send emails? Is this mistaken? Postfix offers many ways to Authenticate submissions, one of which is to co-opt the Dovecot authentication agent, but generally, only "submissions" are authenticated. Deliveries from the big bad internet are not authenticated. An architectural decision that was made many years ago. If the relaying stops when the Dovecot authentication agent is shut down, perhaps you have a compromised machine "inside" your network that is sending spam through your Mail Submission Agent (probably also Postfix). Dovecot can be configured as a "Front-End" proxy to the MSA to handle the authentication part of the transaction. -- This email has been checked for viruses by AVG antivirus software. www.avg.com ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: No-novice with Dovecot, but need novice-like advice (was Dovecot cracked?!)
Logs? Send the relevant logs so people can analyze the problem. On 6/8/23 22:36, Richard Troy wrote: Hi All, This is my first posting here, and maybe I should have found this WAY back in January, '23, if not LONG before. I want to be but I find it difficult here to be brief. ... Surely background will surely help: A 27 or so year old Fedora / Postfix / Dovecot site I built had a major disaster in January and I've not yet been able to fully recover because Dovecot has let the damned spammers in again and again and again and again! OH, sure, I got it down to a trickle, but these few Russian sites always managed to get their spam through and I just had to shut Dovecot down entirely. I never found out how they got in, etc. And I've STRONGLY suspected Dovecot got cracked - at least the modern version in the youngest version for the youngest Fedora we had back in January - uh, Fedora Server 37 - I've forgotten the matching Dovecot version. In the disaster, we lost /var but not /etc, so I figured recovery would be easy and for nearly everything, it was. But NOT Dovecot (and insofar as it matters, Postfix), and in these 5+ months I've tried so many things, I'm sure I've forgotten most of them and I don't know that a retroactive look is worth doing. ...I kept some notes that might be useful if anyone wants to see the evidence of the cracking, but in short, I kept a constant watch on the logs and when ANY relay happened that shouldn't, I'd instantly know it and shut things off entirely. However, that became untenable as I couldn't find the problem and had to just shut it off, pissing off users, etc, but I've had to do things like spend a month and a half traveling, and so forth and, well... Life goes on, as the saying goes. --- NOW I want to try again. It's my perception that it's a waste of time to even LOOK at the old Dovecot configuration stuff. I feel I need to REMOVE it ALL, and I could use some help being SURE to get it all gone. And then I think I need to do a FULL new installation. Overkill? IDK. I could use some advice about SAFE ways to make changes and test to ensure we do NOT become an open mail relay EVER AGAIN. ALSO WORTH SAYING is that if Dovecot were all that damned safe and secure I wouldn't so easily be able to propose a new feature that would make a HUGE difference to sites like mine: Give me a white-list of the ONLY accounts that can relay; NOTHING ELSE can relay. ... THAT would do it! But no! Neither in Postfix nor dovecot is there such a thing! Combine that with a greylist type function where the usual IP addresses for particular users were let through, and new ones delayed, THAT would be awesome, too! And this isn't even all that hard to do - I could do it if I didn't already have a thousand obligations in life! And if someone tells me I'm wrong and points me at how to do these things, I'll fall out of my damned chair! And after picking myself up, I'll find a way to send that person some sort of gift. THIS WOULD HAVE SOLVED ALL MY PROBLEMS. And I'm sure MANY others could use this, too! --- THIS configuration: I'd like to find a way to have both virtual and our existing "unix accounts" users. IF we had an IMAP supported password CHANGING scheme, we'd gladly run encrypted passwords, but there isn't, and we haven't invented (finished inventing!) our own web-way to change 'em and so we're stuck with plain text until one of these things changes. BTW, isn't this a HUGE and OBVIOUS hole that should have been fixed decades ago?! If a major provider like the Dovecot.org team added a way to update passwords to the IMAP protocol, all the rest of the folks would follow along for sure! OR, "is that a thing" and I'm just ignorant of it? So, again, plain-text, in cram, of course. What else? Coach me on "the right way" if you want, but if users can't change it themselves, they'd rather I can retrieve it for them if needed... I'm sure the corporate world doesn't do it this way, but their code isn't open source, or am I wrong?... --- In closing I don't actually anticipate ANY help. My father, an even earlier computer user than me, once observed, "you can ask for information until you're blue in the face, and nobody will say a thing, but post the WRONG thing and a hundred people will post to point out you're wrong!" GIVEN how EASY it is to have your email system become an instant open relay at the hands of the spammers out there, how the hell Dovecot can advertise the way it is WITHOUT a serious guide about this is just frustrating and laughable. But I'd love to be shown where they DO help with this! Thanks for any and all help, Richard ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to
Re: No-novice with Dovecot, but need novice-like advice (was Dovecot cracked?!)
On Fri, 9 Jun 2023, Sean Gallagher wrote: It feels like you are conflating Dovecot with Postfix. Dovecot doesn't actually "relay" anything. (ignoring sieve and submission proxy). Relaying is the job of the "Mail Transfer Agent" or MTA. This is often Postfix but Dovecot could probably work with just about any standards-compliant mailer. If your system is acting as an open relay, you need to look at your MTA configuration. You should probably try the Postfix mailing list. Try the "postfix-users" list. https://www.postfix.org/lists.html Thanks Sean, The relaying only started and stopped when Dovecot was turned on or off. Isn't it true that Dovecot performs an authentication function for inbound connect requests, the successful of which then may use the submission mechanism from what Postfix takes to be an internal connection to send emails? Is this mistaken? However, I get your point and I've spent a lot of work on that area. And, you may well be right that that's where I need to turn - that is, to Postfix. Thanks for the link. Richard ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: No-novice with Dovecot, but need novice-like advice (was Dovecot cracked?!)
On Thu, 8 Jun 2023, Antonio Leding wrote: Just curious - the first thing the hit me was “27 or so year-old…” Fedora was released 19 years ago and Dovecot 20 — what am I missing? And are you saying this box has been unchanged since ’03? Hi Antonio, I had a lot of that in the eamil and the on a proof-read realized it was FAR too long, so I cut out what you're asking about! -ugh- But since you seem to be a historian, I'll indulge a little: ...We really started with a couple of old Sun SPARC "pizza boxes", a DEC Alpha, and a few also-rans of the early '90s. ... I could get "into the weeds" about the OS choices of the day, but as soon as it was available we installed the very first version of Red Hat - paid for the disk! ... It was 10-BaseT, DSL / T1 networking - And getting a domain name? PAIN IN THE ASS! ... We transitioned from Red Hat to Fedora as just "inertia." I barely noticed the difference - marketing / packaging in my view. The site has undergone continuous maintenance, of course. Hardware ages out, software too, sometimes, etc. (and even people) Today we're mostly on Fedora Server with a mix of SuperMicro and oth but I digress... As for pre-Dovecot? I seem to recall that from mid '99 or so we were on Courier, but most of us didn't use it because we had accounts on the "local" boxes and could just login and who needs IMAP? But, we had some need for it, mostly due to people who were less sophisticated - at least that's my view. I suppose there were other motivations. I honestly don't recall exactly why we switched to Dovecot, but I suspect it was due to an early adopter who was helping with our systems at the time. I've got some leftover config files dating from '04 so it goes back at least that far. We traded off hosting hardware with the guy I'm talking about - he had hardware at our site and we had one or more boxes at his site, which helps reliability, etc... Anyway, thanks for the trip down Memory Lane. But can you lend ANY advice here? Thanks, Richard___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: No-novice with Dovecot, but need novice-like advice (was Dovecot cracked?!)
It feels like you are conflating Dovecot with Postfix. Dovecot doesn't actually "relay" anything. (ignoring sieve and submission proxy). Relaying is the job of the "Mail Transfer Agent" or MTA. This is often Postfix but Dovecot could probably work with just about any standards-compliant mailer. If your system is acting as an open relay, you need to look at your MTA configuration. You should probably try the Postfix mailing list. Try the "postfix-users" list. https://www.postfix.org/lists.html On 9/06/2023 8:36 am, Richard Troy wrote: Hi All, This is my first posting here, and maybe I should have found this WAY back in January, '23, if not LONG before. I want to be but I find it difficult here to be brief. ... Surely background will surely help: A 27 or so year old Fedora / Postfix / Dovecot site I built had a major disaster in January and I've not yet been able to fully recover because Dovecot has let the damned spammers in again and again and again and again! OH, sure, I got it down to a trickle, but these few Russian sites always managed to get their spam through and I just had to shut Dovecot down entirely. I never found out how they got in, etc. And I've STRONGLY suspected Dovecot got cracked - at least the modern version in the youngest version for the youngest Fedora we had back in January - uh, Fedora Server 37 - I've forgotten the matching Dovecot version. In the disaster, we lost /var but not /etc, so I figured recovery would be easy and for nearly everything, it was. But NOT Dovecot (and insofar as it matters, Postfix), and in these 5+ months I've tried so many things, I'm sure I've forgotten most of them and I don't know that a retroactive look is worth doing. ...I kept some notes that might be useful if anyone wants to see the evidence of the cracking, but in short, I kept a constant watch on the logs and when ANY relay happened that shouldn't, I'd instantly know it and shut things off entirely. However, that became untenable as I couldn't find the problem and had to just shut it off, pissing off users, etc, but I've had to do things like spend a month and a half traveling, and so forth and, well... Life goes on, as the saying goes. --- NOW I want to try again. It's my perception that it's a waste of time to even LOOK at the old Dovecot configuration stuff. I feel I need to REMOVE it ALL, and I could use some help being SURE to get it all gone. And then I think I need to do a FULL new installation. Overkill? IDK. I could use some advice about SAFE ways to make changes and test to ensure we do NOT become an open mail relay EVER AGAIN. ALSO WORTH SAYING is that if Dovecot were all that damned safe and secure I wouldn't so easily be able to propose a new feature that would make a HUGE difference to sites like mine: Give me a white-list of the ONLY accounts that can relay; NOTHING ELSE can relay. ... THAT would do it! But no! Neither in Postfix nor dovecot is there such a thing! Combine that with a greylist type function where the usual IP addresses for particular users were let through, and new ones delayed, THAT would be awesome, too! And this isn't even all that hard to do - I could do it if I didn't already have a thousand obligations in life! And if someone tells me I'm wrong and points me at how to do these things, I'll fall out of my damned chair! And after picking myself up, I'll find a way to send that person some sort of gift. THIS WOULD HAVE SOLVED ALL MY PROBLEMS. And I'm sure MANY others could use this, too! --- THIS configuration: I'd like to find a way to have both virtual and our existing "unix accounts" users. IF we had an IMAP supported password CHANGING scheme, we'd gladly run encrypted passwords, but there isn't, and we haven't invented (finished inventing!) our own web-way to change 'em and so we're stuck with plain text until one of these things changes. BTW, isn't this a HUGE and OBVIOUS hole that should have been fixed decades ago?! If a major provider like the Dovecot.org team added a way to update passwords to the IMAP protocol, all the rest of the folks would follow along for sure! OR, "is that a thing" and I'm just ignorant of it? So, again, plain-text, in cram, of course. What else? Coach me on "the right way" if you want, but if users can't change it themselves, they'd rather I can retrieve it for them if needed... I'm sure the corporate world doesn't do it this way, but their code isn't open source, or am I wrong?... --- In closing I don't actually anticipate ANY help. My father, an even earlier computer user than me, once observed, "you can ask for information until you're blue in the face, and nobody will say a thing, but post the WRONG thing and a hundred people will post to point out you're wrong!" GIVEN how EASY it is to have your email system become an instant open relay at the hands of the spammers out there, how the hell Dovecot can advertise the way it is
Re: No-novice with Dovecot, but need novice-like advice (was Dovecot cracked?!)
Just curious - the first thing the hit me was “27 or so year-old…” Fedora was released 19 years ago and Dovecot 20 — what am I missing? And are you saying this box has been unchanged since ’03? - - - On 8 Jun 2023, at 15:36, Richard Troy wrote: Hi All, This is my first posting here, and maybe I should have found this WAY back in January, '23, if not LONG before. I want to be but I find it difficult here to be brief. ... Surely background will surely help: A 27 or so year old Fedora / Postfix / Dovecot site I built had a major disaster in January and I've not yet been able to fully recover because Dovecot has let the damned spammers in again and again and again and again! OH, sure, I got it down to a trickle, but these few Russian sites always managed to get their spam through and I just had to shut Dovecot down entirely. I never found out how they got in, etc. And I've STRONGLY suspected Dovecot got cracked - at least the modern version in the youngest version for the youngest Fedora we had back in January - uh, Fedora Server 37 - I've forgotten the matching Dovecot version. In the disaster, we lost /var but not /etc, so I figured recovery would be easy and for nearly everything, it was. But NOT Dovecot (and insofar as it matters, Postfix), and in these 5+ months I've tried so many things, I'm sure I've forgotten most of them and I don't know that a retroactive look is worth doing. ...I kept some notes that might be useful if anyone wants to see the evidence of the cracking, but in short, I kept a constant watch on the logs and when ANY relay happened that shouldn't, I'd instantly know it and shut things off entirely. However, that became untenable as I couldn't find the problem and had to just shut it off, pissing off users, etc, but I've had to do things like spend a month and a half traveling, and so forth and, well... Life goes on, as the saying goes. --- NOW I want to try again. It's my perception that it's a waste of time to even LOOK at the old Dovecot configuration stuff. I feel I need to REMOVE it ALL, and I could use some help being SURE to get it all gone. And then I think I need to do a FULL new installation. Overkill? IDK. I could use some advice about SAFE ways to make changes and test to ensure we do NOT become an open mail relay EVER AGAIN. ALSO WORTH SAYING is that if Dovecot were all that damned safe and secure I wouldn't so easily be able to propose a new feature that would make a HUGE difference to sites like mine: Give me a white-list of the ONLY accounts that can relay; NOTHING ELSE can relay. ... THAT would do it! But no! Neither in Postfix nor dovecot is there such a thing! Combine that with a greylist type function where the usual IP addresses for particular users were let through, and new ones delayed, THAT would be awesome, too! And this isn't even all that hard to do - I could do it if I didn't already have a thousand obligations in life! And if someone tells me I'm wrong and points me at how to do these things, I'll fall out of my damned chair! And after picking myself up, I'll find a way to send that person some sort of gift. THIS WOULD HAVE SOLVED ALL MY PROBLEMS. And I'm sure MANY others could use this, too! --- THIS configuration: I'd like to find a way to have both virtual and our existing "unix accounts" users. IF we had an IMAP supported password CHANGING scheme, we'd gladly run encrypted passwords, but there isn't, and we haven't invented (finished inventing!) our own web-way to change 'em and so we're stuck with plain text until one of these things changes. BTW, isn't this a HUGE and OBVIOUS hole that should have been fixed decades ago?! If a major provider like the Dovecot.org team added a way to update passwords to the IMAP protocol, all the rest of the folks would follow along for sure! OR, "is that a thing" and I'm just ignorant of it? So, again, plain-text, in cram, of course. What else? Coach me on "the right way" if you want, but if users can't change it themselves, they'd rather I can retrieve it for them if needed... I'm sure the corporate world doesn't do it this way, but their code isn't open source, or am I wrong?... --- In closing I don't actually anticipate ANY help. My father, an even earlier computer user than me, once observed, "you can ask for information until you're blue in the face, and nobody will say a thing, but post the WRONG thing and a hundred people will post to point out you're wrong!" GIVEN how EASY it is to have your email system become an instant open relay at the hands of the spammers out there, how the hell Dovecot can advertise the way it is WITHOUT a serious guide about this is just frustrating and laughable. But I'd love to be shown where they DO help with this! Thanks for any and all help, Richard ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to
No-novice with Dovecot, but need novice-like advice (was Dovecot cracked?!)
Hi All, This is my first posting here, and maybe I should have found this WAY back in January, '23, if not LONG before. I want to be but I find it difficult here to be brief. ... Surely background will surely help: A 27 or so year old Fedora / Postfix / Dovecot site I built had a major disaster in January and I've not yet been able to fully recover because Dovecot has let the damned spammers in again and again and again and again! OH, sure, I got it down to a trickle, but these few Russian sites always managed to get their spam through and I just had to shut Dovecot down entirely. I never found out how they got in, etc. And I've STRONGLY suspected Dovecot got cracked - at least the modern version in the youngest version for the youngest Fedora we had back in January - uh, Fedora Server 37 - I've forgotten the matching Dovecot version. In the disaster, we lost /var but not /etc, so I figured recovery would be easy and for nearly everything, it was. But NOT Dovecot (and insofar as it matters, Postfix), and in these 5+ months I've tried so many things, I'm sure I've forgotten most of them and I don't know that a retroactive look is worth doing. ...I kept some notes that might be useful if anyone wants to see the evidence of the cracking, but in short, I kept a constant watch on the logs and when ANY relay happened that shouldn't, I'd instantly know it and shut things off entirely. However, that became untenable as I couldn't find the problem and had to just shut it off, pissing off users, etc, but I've had to do things like spend a month and a half traveling, and so forth and, well... Life goes on, as the saying goes. --- NOW I want to try again. It's my perception that it's a waste of time to even LOOK at the old Dovecot configuration stuff. I feel I need to REMOVE it ALL, and I could use some help being SURE to get it all gone. And then I think I need to do a FULL new installation. Overkill? IDK. I could use some advice about SAFE ways to make changes and test to ensure we do NOT become an open mail relay EVER AGAIN. ALSO WORTH SAYING is that if Dovecot were all that damned safe and secure I wouldn't so easily be able to propose a new feature that would make a HUGE difference to sites like mine: Give me a white-list of the ONLY accounts that can relay; NOTHING ELSE can relay. ... THAT would do it! But no! Neither in Postfix nor dovecot is there such a thing! Combine that with a greylist type function where the usual IP addresses for particular users were let through, and new ones delayed, THAT would be awesome, too! And this isn't even all that hard to do - I could do it if I didn't already have a thousand obligations in life! And if someone tells me I'm wrong and points me at how to do these things, I'll fall out of my damned chair! And after picking myself up, I'll find a way to send that person some sort of gift. THIS WOULD HAVE SOLVED ALL MY PROBLEMS. And I'm sure MANY others could use this, too! --- THIS configuration: I'd like to find a way to have both virtual and our existing "unix accounts" users. IF we had an IMAP supported password CHANGING scheme, we'd gladly run encrypted passwords, but there isn't, and we haven't invented (finished inventing!) our own web-way to change 'em and so we're stuck with plain text until one of these things changes. BTW, isn't this a HUGE and OBVIOUS hole that should have been fixed decades ago?! If a major provider like the Dovecot.org team added a way to update passwords to the IMAP protocol, all the rest of the folks would follow along for sure! OR, "is that a thing" and I'm just ignorant of it? So, again, plain-text, in cram, of course. What else? Coach me on "the right way" if you want, but if users can't change it themselves, they'd rather I can retrieve it for them if needed... I'm sure the corporate world doesn't do it this way, but their code isn't open source, or am I wrong?... --- In closing I don't actually anticipate ANY help. My father, an even earlier computer user than me, once observed, "you can ask for information until you're blue in the face, and nobody will say a thing, but post the WRONG thing and a hundred people will post to point out you're wrong!" GIVEN how EASY it is to have your email system become an instant open relay at the hands of the spammers out there, how the hell Dovecot can advertise the way it is WITHOUT a serious guide about this is just frustrating and laughable. But I'd love to be shown where they DO help with this! Thanks for any and all help, Richard ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
RE: Migration dovecot server with local users to dovecot with virtual mailboxes
Please see https://doc.dovecot.org/admin_manual/migrating_mailboxes/Aki
Original message From: tseeger...@gmail.com Date: 6/8/23
16:10 (GMT+02:00) To: dovecot@dovecot.org Subject: Migration dovecot server
with local users to dovecot with virtual
mailboxes Hello, we are using a dovecot server with NIS, we want to
transfer it to a new setup. As backend a mysql server will be used in the
future. My problem is, if I just copy the maildir or use "doveadm import" all
mails are flagged as "unseen". How can i preserve the flags?This is how I have
tried it so far.root@mail / $ doveadm import -s -u testuser@testdomain.local
maildir:/tmp/testuser-maildir-230608/Maildir/:INDEX=MEMORY "" "All"As a
"workaround" I tried to change the flags.root@mail / $ doveadm -v flags add -u
testuser@testdomain.local "Seen" "ALL"This led partially to the desired
success, the mails are shown as "seen", but the folders (e.g. Roundcube) still
show unread mails.dovecot -n#
2.3.13 (89f716dc2): /etc/dovecot/dovecot.conf# Pigeonhole version 0.5.13
(cdd19fe3)# OS: Linux 5.10.0-23-cloud-amd64 x86_64 Debian 11.7 # Hostname:
mail.testdomain.localauth_mechanisms = plain loginmail_fsync = alwaysmail_gid =
vmailmail_home = /var/vmail/mailboxes/%d/%nmail_location =
maildir:~/mail:LAYOUT=fs:INDEX=MEMORYmail_privileged_group = vmailmail_uid =
vmailmanagesieve_notify_capability = mailtomanagesieve_sieve_capability =
fileinto reject envelope encoded-character vacation subaddress
comparator-i;ascii-numeric relational regex imap4flags copy include variables
body enotify environment mailbox date index ihave duplicate mime foreverypart
extracttext imapsieve vnd.dovecot.imapsievemmap_disable = yesnamespace inbox {
inbox = yes location = mailbox Drafts { auto = subscribe special_use =
\Drafts } mailbox Sent { auto = subscribe special_use = \Sent }
mailbox Spam { auto = subscribe special_use = \Junk } mailbox Trash {
auto = subscribe special_use = \Trash } prefix = }passdb { args =
/etc/dovecot/dovecot-sql.conf driver = sql}plugin { imapsieve_mailbox1_before
= file:/var/vmail/sieve/global/learn-spam.sieve imapsieve_mailbox1_causes =
COPY imapsieve_mailbox1_name = Spam imapsieve_mailbox2_before =
file:/var/vmail/sieve/global/learn-ham.sieve imapsieve_mailbox2_causes = COPY
imapsieve_mailbox2_from = Spam imapsieve_mailbox2_name = * quota =
maildir:User quota quota_exceeded_message = User %u has exhausted allowed
storage space. sieve =
file:/var/vmail/sieve/%d/%n/scripts;active=/var/vmail/sieve/%d/%n/active-script.sieve
sieve_before = /var/vmail/sieve/global/spam-global.sieve
sieve_global_extensions = +vnd.dovecot.pipe sieve_pipe_bin_dir = /usr/bin
sieve_plugins = sieve_imapsieve sieve_extprograms}protocols = imap lmtp
sieveservice auth { unix_listener /var/spool/postfix/private/auth { group =
postfix mode = 0660 user = postfix } unix_listener auth-userdb {
group = vmail mode = 0660 user = vmail }}service imap-login {
inet_listener imap { port = 143 } process_min_avail = 1 service_count =
1}service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix mode = 0660 user = postfix } user = vmail}service
managesieve-login { inet_listener sieve { port = 4190 }}ssl =
requiredssl_ca =
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Migration dovecot server with local users to dovecot with virtual mailboxes
Hello,
we are using a dovecot server with NIS, we want to transfer it to a new setup.
As backend a mysql server will be used in the future.
My problem is, if I just copy the maildir or use "doveadm import" all mails are
flagged as "unseen". How can i preserve the flags?
This is how I have tried it so far.
root@mail / $ doveadm import -s -u testuser@testdomain.local
maildir:/tmp/testuser-maildir-230608/Maildir/:INDEX=MEMORY "" "All"
As a "workaround" I tried to change the flags.
root@mail / $ doveadm -v flags add -u testuser@testdomain.local "Seen" "ALL"
This led partially to the desired success, the mails are shown as "seen", but
the folders (e.g. Roundcube) still show unread mails.
dovecot -n
# 2.3.13 (89f716dc2): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.13 (cdd19fe3)
# OS: Linux 5.10.0-23-cloud-amd64 x86_64 Debian 11.7
# Hostname: mail.testdomain.local
auth_mechanisms = plain login
mail_fsync = always
mail_gid = vmail
mail_home = /var/vmail/mailboxes/%d/%n
mail_location = maildir:~/mail:LAYOUT=fs:INDEX=MEMORY
mail_privileged_group = vmail
mail_uid = vmail
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy
include variables body enotify environment mailbox date index ihave duplicate
mime foreverypart extracttext imapsieve vnd.dovecot.imapsieve
mmap_disable = yes
namespace inbox {
inbox = yes
location =
mailbox Drafts {
auto = subscribe
special_use = \Drafts
}
mailbox Sent {
auto = subscribe
special_use = \Sent
}
mailbox Spam {
auto = subscribe
special_use = \Junk
}
mailbox Trash {
auto = subscribe
special_use = \Trash
}
prefix =
}
passdb {
args = /etc/dovecot/dovecot-sql.conf
driver = sql
}
plugin {
imapsieve_mailbox1_before = file:/var/vmail/sieve/global/learn-spam.sieve
imapsieve_mailbox1_causes = COPY
imapsieve_mailbox1_name = Spam
imapsieve_mailbox2_before = file:/var/vmail/sieve/global/learn-ham.sieve
imapsieve_mailbox2_causes = COPY
imapsieve_mailbox2_from = Spam
imapsieve_mailbox2_name = *
quota = maildir:User quota
quota_exceeded_message = User %u has exhausted allowed storage space.
sieve =
file:/var/vmail/sieve/%d/%n/scripts;active=/var/vmail/sieve/%d/%n/active-script.sieve
sieve_before = /var/vmail/sieve/global/spam-global.sieve
sieve_global_extensions = +vnd.dovecot.pipe
sieve_pipe_bin_dir = /usr/bin
sieve_plugins = sieve_imapsieve sieve_extprograms
}
protocols = imap lmtp sieve
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
unix_listener auth-userdb {
group = vmail
mode = 0660
user = vmail
}
}
service imap-login {
inet_listener imap {
port = 143
}
process_min_avail = 1
service_count = 1
}
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0660
user = postfix
}
user = vmail
}
service managesieve-login {
inet_listener sieve {
port = 4190
}
}
ssl = required
ssl_ca =
Re: Remove attachments
On 2023-06-03, John Stoffel wrote: >> "Oliver" == Oliver Glas writes: > >> I am looking for a way to remove attachments, based on a condition. >> Like attachments starting with "TimeReport" shall be removed, and >> then the mail should be delivered, with all other attachments. > > This is not a solution that dovecat can work with. You need to use a > milter in your mailserver (like postfix) which can strip out mime > attachements or do other modifications to an email before it's > delivered to the mailbox. > >> I did so far not find a solution to remove attachments. Do I need a >> plugin / extension ? If so, how to implement and use that ? > > milters are what you want. MIMEdefang is one. You can also do this by calling altermime from sieve with the vnd.dovecot.filter extension from https://doc.dovecot.org/configuration_manual/sieve/plugins/extprograms/ ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
