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
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 dovecot-leave@dovecot.org
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
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 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-leave@dovecot.org
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
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.
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.
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:
https://sciencetools.com/email.html
To save your looking, it's port 587 with "STARTTLS", and 993 with "SSL/TLS".
If the 587 is going to Dovecot and not Postfix, doesn't that make my case for me that this is a Dovecot issue because, as you state, "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).
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.
Dovecot can be configured as a "Front-End" proxy to the MSA to handle the authentication part of the transaction.
I figured that's what was happening, thanks - presuming you mean Dovecot IS the MSA for Postfix in this instance.
Thanks, Richard
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.
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
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
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
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
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-leave@dovecot.org
participants (5)
-
Antonio Leding
-
dovecot＠x9p.org
-
jeremy ardley
-
Richard Troy
-
Sean Gallagher