Re: No-novice with Dovecot, but need novice-like advice (was Dovecot cracked?!)
On 09.06.23 00:36, Richard Troy wrote:
OH, sure, I got it down to a trickle, but these few Russian sites always managed to get their spam through and
(FWIW, if you can characterize the offenders by country, trying a GeoIP filter as a stop-gap measure sounds rather promising.)
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!
I'm afraid that that's not *entirely* true ... :
/etc/postfix# grep senderauth main.cf smtpd_sender_login_maps = hash:/etc/postfix/senderauth
/etc/postfix# head -2 senderauth ; grep bern senderauth | sed -e 's/[-a-z\.]*'"$DOMAIN/DOMAIN/g" # Envelope Sender: Requires SMTP AUTH as one of: # actual.address@dom.ain user.1@dom.ain, another@else.where jochen.bern@DOMAIN.pawisda.de jochen.bern@DOMAIN.de
(Also works with unspecified local part, i.e., "@some.dom.ain" for the left-hand side.)
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!
Please define "delayed". The kind where you tell the client to retry later and then close the connection is available for postfix under the name of postgrey, but is probably quite disruptive when used with an M*S*A port; same caveat for mechanisms that prevent the connection altogether, like one could build with iptables. The search keyword for the kind where "the server is just deeaaaaaaadddd slllooooowwwww" would be "Teergrube".
[Yes, I'm German, so I capitalize German nouns like German does. :-> ]
None of those are *built right into* postfix or dovecot, likely because it's too much complexity to maintain for a huge user base that doesn't use the functionality all too often.
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!
[promptly invents the sport of Comfy Cushion Curling]
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.
Your server is Linux and SSH client software has become quite available (PuTTY on Windows). For OS-based users who don't need *shell* access to the server, I've had some success just setting the "passwd" command as their login "shell" (in /etc/passwd . Plus adding it to /etc/shells if necessary.) Dunno how readily you could find an equivalent for the *virtual* accounts' password backend ...
(Yes, it'd be better to have it seamlessly integrated into the IMAP protocol, but don't forget that you'd need the *MUAs* to start supporting it as well before the general public will ever even learn about the new feature ...)
Kind regards,
Jochen Bern Systemingenieur
Binect GmbH
On Fri, 9 Jun 2023, Jochen Bern wrote:
OH, sure, I got it down to a trickle, but these few Russian sites always managed to get their spam through and
(FWIW, if you can characterize the offenders by country, trying a GeoIP filter as a stop-gap measure sounds rather promising.)
Yes, it would; is that "a thing?" I mean, someone else has already written it and I just have to find and configure it?
...And THEN you get to the most interesting post I've yet gotten on this as I had COMPLETLY OVERLOOKED smtpd_sender_login_maps! You write:
Give me a white-list of the ONLY accounts that can relay
I'm afraid that that's not *entirely* true [that it doesn't exist] :
/etc/postfix# grep senderauth main.cf smtpd_sender_login_maps = hash:/etc/postfix/senderauth
/etc/postfix# head -2 senderauth ; grep bern senderauth | sed -e 's/[-a-z\.]*'"$DOMAIN/DOMAIN/g" # Envelope Sender: Requires SMTP AUTH as one of: # actual.address@dom.ain user.1@dom.ain, another@else.where jochen.bern@DOMAIN.pawisda.de jochen.bern@DOMAIN.de
(Also works with unspecified local part, i.e., "@some.dom.ain" for the left-hand side.)
Unfortunately, the correct file format is quite unclear. In my view neither your description nor the documentation are fully useful because they seem to presume a level of familiarity with lookup tables I don't happen to have - and/or the time to read ALL the documentation (and time is a scarce commodity). And, I could find no examples. ... Your excerpt was confusing because the head -2 should produce two lines but my email shows three! Further, the last line appears to have two entries, implying multiple entries per line are OK.
Would a plain-text file of simple one line per user entry of either user@domain, user, or @domain work?
BTW, I can tell right away this will eventually get "sticky" when I get to implementing virtual email users. However, I DO have Postgres (worked with the original development team at UC Berkeley in the mid '90s and continuously used it ever since - OH, and it's marketing name is PostgreSQL, by the way), and already have a vested interest in using it for this purpose, so I wouldn't mind too much just implementing there, but it seems smart to just get something simple up and working now and then add to the config. over time.
...Further, does the "type:name" reference in the docs mean, as in your example of hash:filename that I could use SQL:<file> and point it at some script that fetches entries from the database?
I'll try my own suggestions shortly, but a pointer to already-written information would be great - or your comments, too, of course!
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!
Please define "delayed".
I already have postgray (or is it postgrey?) and it does fine, but it's for reception and not sending. ...AFTER knowing someone is a valid user of the system and they want to send a relayed mail, but they're sending from an unusual IP address, THEN it'd be nice to introduce a delay that would make spammers not bother. How long that is? IDK... Rate-limited to one every 3 minutes? five minutes? Configurable? ...It's just a concept.
I get your point about the MSA port, so maybe it's more work to implement than it's worth. And, if the authorized-senders only issue were resolved, it might not be needed.
That said, a sender-based sending rate limiter wouldn't be a bad feature for Postfix in my view.
[Yes, I'm German, so I capitalize German nouns like German does. :-> ]
So, a 1 paragraph digression on that:
I often do that too - I've spent close to 5 years in Germany, and for a citizen of the USA, that's unusual. ;-) Had a German girlfriend for nearly 10 years, so I've picked up plenty along the way. Plus, around 20% of English is straight German, but then you surely know that! Heck, even the seemingly awkward German syntax is identical to that used in old-English! People fluent in old-English instantly understand Germany syntax, but we're not accustomed to using it, mostly just hearing it. ...And I am sometimes misunderstood for just using older English forms because if any group struggles with knowing it's own first language, it's ... Oh, nevermind!
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!
[promptly invents the sport of Comfy Cushion Curling]
-chuckle-
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.
Your server is Linux and SSH client software has become quite available (PuTTY on Windows).
It's not an issue of possibility or ease but willingness to learn or desire to bother, I suppose.
I'm more than half-way through development of a simple but safe password changing mechanism that can run on a firewall / gateway machine and get the information picked up on an internal server system... The architecture was designed to be VERY easily be adapted to deal with pretty much any password scheme. Maybe I'll just finish it. Time is my issue!
(Yes, it'd be better to have it seamlessly integrated into the IMAP protocol, but don't forget that you'd need the *MUAs* to start supporting it as well before the general public will ever even learn about the new feature ...)
Yes, agreed, but if Dovecot and Postfix did their part, the rest would SURELY follow.
Thanks Jochen, Richard
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
participants (2)
-
Jochen Bern
-
Richard Troy