Re: On mailbox full, retry for 4 days or similar instead of reject
Am 07.02.22 um 23:41 schrieb Jorge Bastos: > I want postfix not to discard the message imediatly when a mailbox is > full, i mean when postfix tries to deliver it to dovecot lmtp. > Is it possible to change the behavior to something like what postfix > does when he tries to deliver a message to an external server and the > server is unaccessible for 4 days (the default i guess), and if in that > period discard it. if you set "quota_full_tempfail" to "yes" in dovecots lda.conf, it should answer with a temporary failure-code 422 instead of permanent 522. (at least the code of lmtp_local_rcpt_reply_overquota() says so) as lmtp is similar to smtp, postfix or any other MTA should honor this and keep the message in queue until the temporary failure goeas away or the queue-timeout (in Postfix!) is reached. d.
Re: banning
Am 08.01.22 um 17:22 schrieb Dave McGuire: > I wasn't asking for a critique of my configuration; I explained my > approach to a new user who came here looking for help. huh? well, I don't think that anyone wanted to say anything about _your_ configuration, but wanted to supplement, that your configuration is maybe good for _your_ systems, but other systems may need other approaches. especially if answering to someone, who experiences new things and asking for help, it should be normal, that someone even pick answers from others and supplement things from their own view. this has nothing to do with blaming the author of the answer, but should show the asking person, that the answer given maybe incomplete (not wrong!) for the concrete situation, because it only shows a single view to a problem. > Which is the last time I'll do THAT on this list, by the way. this would be bad in my opinion. we're all doing something within our own world and if we have the possibility to look at other worlds and how people solve problems there, the knowlegde gets better and even if then someone asks us in a private situation with no additonal listeners, we can refer to solutions, which are different from our own one. at least newbies should see: there's nearly nowhere one answer. d.
Re: Non-user logins?
Am 08.01.22 um 05:27 schrieb Dave McGuire: > trying to mess with other peoples' stuff. I run fail2ban to catch those > log entries and block the source IP address for a month on the first > failed login. At any one time I have between 12,000 and 15,000 well, I don't know how _your_ users are connected to the internet, but in germany most people has at least daily changing IPs out of larger pools (when connected via xDSL) or even sometimes shares ip-addresses with others (when connected via tv-cable or mobile - having a private network-address, which is natted), so it's possible to get/use an IP, which was used before by some script-kiddies... so everyone, who's blocking such requests for more than some minutes/hours should be aware of maybe blocking legitimate user-logins... btw.: setting up a new mail-client and making any mistake by reading it from old install or writing it into new install also leads to a months-blocking with above restrictive handling... (any may drive this user mad) so anyone, who has no experience with blocking should be really careful with it. d.
Re: GDPR/sender-ip
Am 05.01.22 um 18:00 schrieb John Fawcett: > my understanding of the GDPR legislation is that it defines what is > considered lawful processing. One of those items that makes the > processing lawful is consent. If I send an email to a public mailing > list I think it's fair to say that I am providing consent. I was not sorry, you're wrong. have a look at the given link to the EUGH-judgement. it's irrelevant if someone acts in private or public area. peoples privacy rights always exists and may only violated, if there's really no other possibility to fulfil higher rights and: think about whistleblowers or dissidents in autotcratic regimes: maybe they send mails from the same place, where they do their important work for society. Even if they change their IP between, their location may be traced in detail. and don't forget: no one here will force you, to change your handling with your users privacy-data. but some of us want to have the possibility to change it. So why you're aguing here, what's your aim? if there are technical issues with the patch - ok if it brings more complexity in the further development (which I don't think due its simplicity) - ok but I think that interpretation of the GDPR is neither on-topic here, nor may lead to any kind of consensus, since even in Europe there're still enough people, who think, that's not useful. d.
Re: patch: make received-header on submission optional or optionally drop the from-part in it
Am 05.01.22 um 17:23 schrieb Michael Kliewe: > In Postfix many privacy-friendly submission servers do the following: [...] nice feature, unfortunately we're currently not using postfix, because none here has enough experience with it. maybe later... but: > The Received-Header is still there, so you can see the receiving server for this the patch offers the option to simply drop the "by X.X.X.X" but not the whole header itself. Because for lmtp there already was an option to remove the complete header, this was also implemented for submission. (we know that information about the accepting system/software might be useful for debugging problems) d.
GDPR/sender-ip (was: make received-header on submission optional or at least drop the ip in it)
Am 04.01.22 um 08:39 schrieb Aki Tuomi: > We'll take a look at your patch. Can you please point out to some legal > information about the Received header's GDPR incompliance, I would be > interested to see it. thanks for doing so. the GDPR says about personal data: - that only really needed data has to be stored - that this data has to be used only for that declared needs - that any other usage has to be prevented, especially by third-parties the EuGH has judged in 2016 (Patrick Breyer vs. Germany, C-582/14), that an IP-addresses can be personal data, because the person may be identified via this IP, so they have to be handled as such. http://curia.europa.eu/juris/documents.jsf?num=C-582/14 therefore the possibility, that others may for example see when a person was at a place (connected to an IP) has to be prevented at least in europe. if such information is published for people with high email-activity, then it would be possible for everyone, who has access to this email (which might be really everyone on earth for example in archived mailing-lists) to track these people over the whole time. for security-reasons we're logging any submission-request together with the origin-IP in our logs for at least seven days. so any mis-use of our service may be prosecuted even without storing this information in every email. In germany some courts judged, that if the police asks us for the IP, we've to store the log-entry at least as long, as a court needs to judge, that we have to give it to the police. (I think this is a reasonable balance between protection of personal data and legitimate public interest) if there are further questions to this topic I'll try to reply, but you should know, that my english isn't that good, especially to explain juridicial things... regards d.
patch: make received-header on submission optional or optionally drop the from-part in it
> @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. okay, perhaps I've a solution for this. because we're using standard-distribution-pkgs, we're checked it with that version (devuan chimaera/debian bullseye) and it works as expected. The port to the currently available version 2.3.17.1 was simple, because only the Macro "DEF(SET_BOOL, ..." has changed to "DEF(BOOL, ..." between that versions, but we only have tested the compilation of this version. because until now I've never really worked with git, I've no possibility to follow that way for integration. Independently from this maybe you won't like the changes and won't integrate them at all. == 1. added an corresponding option to "lmtp_add_received_header" named "submission_add_received_header" 2. added options "lmtp_add_rcvd_from" and "submission_add_rcvd_from" 3. added another arg to smtp_server_transaction_write_trace_record() to handle the "*rcvd_from"-flags 4. beautified the header-construction within smtp_server_transaction_write_trace_record() a little bit 5. added the options to default-config. (unset default is always keeping old behaviour) == 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. regards d. dovecot-2.3.17.1-rcvd_from-patch.xz Description: application/xz
Re: feature-request: make received-header on submission optional or at least drop the ip in it
Am 03.01.22 um 15:47 schrieb Michael Peddemors: > Using your email system IS the reason, simply make sure that you inform no, it's not. and: > (SLA, Terms and Conditions etc) and it has a valid use, eg for security > purposes. for security_reasons it's completly ok, to store this information *locally* on the server for some time, but not to push this information together with date+time towards the world. sorry, if you don't have an idea of privacy-needs, you should not post about this topic and then say something about "no flames please"... > Oh, but no flames please, this is almost getting off topic as it is. well, then let's come back to the origin topic. There's an need for it (as I noticed meanwhile at least back to 2019: https://dovecot.org/pipermail/dovecot/2019-August/116865.html ) and until it breaks no existing thing (which is expected due to *optional* settings ), there's no reason to discuss about that need itself. ( You won't be forced to enable it for Your mail-server ) @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. d.
feature-request: make received-header on submission optional or at least drop the ip in it
hi. we're just trying to re-structure a system and want to use dovcots submission-ability. because the github-repository have no entry for any issues at all, we're sending this feature-fequest to this ML. unfortunately there doesn't seem to be any option to drop the received-header at all or at least hide the IP of the user. because the client-ip is covered by GDPR as personal data and so it should never shown to others without a certain reason, we want to hide it, but there's no "submission_add_received_header"-option like for lmtp and it doesn't seem to be any other option to hide this information. maybe this is possible to implement in near future? thanks a lot. best regards d.
