Re: Permission denied
On Thu, 2021-12-30 at 00:20 +0100, Christian Kivalo wrote: > The override.conf goes to /etc/systemd/system/dovecot.service.d/ to > be included. > Issue systemctl daemon-reload before restarting dovecot. > systemctl cat dovecot.service shows you the content of the involved > conf files Tried this, then tried logging in. Got the following message in /var/log/mail.err: Jan 2 01:19:50 grace dovecot: imap-login: Error: read(anvil) failed: EOF Does this help anyone? Ken >
Re: spf helo pass
On 1/01/22 9:57 pm, Benny Pedersen wrote: its basicly just statistik you say above You seem to think you can just ARC sign the message and everything will be rosy. This is not the case, ARC needs to be implemented on the receiver side or it will be completely ignored. It will takes yeras for it to be widely adopted. 1. Check the inbound SPF, DKIM and DMARC and reject the mail if it doesn't pass. check spf helo, spf mfrom, check dkim, check arc in that order, but do not reject, current its only meta data collected to dmarc policy with can reject if sender wants it rejected, but this should relly not be rejected if its arc-signed / arc-sealed, this indicate a maillist where reject is not best way to solve spamming Sure check for ARC as well. The point is to reject anything that might be SPAM because you are going to be DKIM signing it yourself and you don't want to be forwarding SPAM. 2. Other anti-spam measures to try to absolutely minimize the amount of SPAM that you end up forwarding. its possible to unsubscribe So you expect a spammer to unsubscribe? makes things worse makes things worse And yet as I said, it's the only way to guarantee that the message will pass on the recipient side. ARC won't do that. I didn't say it was a great solution, I said it's the *only* solution. 5. Do any other alterations, such as adding list-* headers modifying the Subject: header, etc. does not break dkim when adding new headers, but change signed headers does Wrong. Adding headers *can* break dkim. This is because the lack of headers or NULL headers can be signed. 6. DKIM sign the message from the domain you rewrote the From: header to. perfect forged mail can be tested in dkim adsp Which is why you check the original signature and reject if it doesn't pass. 7. Rewrite the envelope sender to your domain name. normal for maillists, does not break spf specs It's something that you have to explicitly tell your MTA to do, and it certainly wasn't "normal" before SPF was a thing. 8. Send out the message. and hope for no spf helo, spf pass if its spam :) Again, why you try to reject SPAM to begin with. The above assumes properly implemented SPF, DKIM and DMARC records for your domain. define properly I'm not going to go into that level of detail here. There are many many resources on the internet which can tell you how to set up these thigns properly. That is the *only* way you can be fully certain that the forwarded message will pass SPF, DKIM and DMARC checks and therefore have the best chances of being received by the recipient. Anything else relies on implementation specifics of the sender and/or the recipient MTAs which may or may not make that possible. you need more meta data on diffrent maillists if you write this above Nope, this has nothing to do with the mail list. This has to do with different practices of the sending MTA and recipient MTA. The mail list sits in-between the two and must reconcile with various different policies of the sender (which can be determined) and how the recipient will check those policies (which generally cannot be determined). we are OFF Topic, take debate offline from maillist By all means. Just stop trying to claim that ARC will solve all the problems, it won't. I realize that mailing lists likely do not want to implement all of the above steps, but ARC is not a magic bullet that can fix the issues shown, there is no magic bullet and so you either accept that a number of messages will, depending on circumstances, not make it to the recipient, or you take drastic measures to resign everything so that the recipient MTA is happy. Peter
auth crashes when oauth2 passdb is enabled
I've enabled both sql and oauth2 passdb,
regardless of the method used by the client, I get the following error:
Jan 1 15:38:56 mail dovecot[52828]: auth: Panic: file http-client.c: line
646 (http_client_context_close): assertion failed: (cctx->clients_list ==
NULL)
Jan 1 15:38:56 mail dovecot[52826]: master: Error: service(auth): command
startup failed, throttling for 2.000 secs
Jan 1 15:38:56 mail dovecot[52828]: auth: Fatal: master: service(auth):
child 52840 killed with signal 6 (core dumped)
Jan 1 15:38:56 mail dovecot[52828]: imap-login: Disconnected: Auth process
broken (disconnected before auth was ready, waited 0 secs): user=<>,
rip=192.168.1.104, lip=192.168.1.101, TLS, session=
If I remove the oauth2 passdb, there are no problems.
This is the output of dovecot -n:
# 2.3.17 (e2aa53df5b): /usr/local/etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.17 (054dddfa)
# OS: FreeBSD 13.0-RELEASE-p4 amd64 nullfs
# Hostname: localhost
auth_mechanisms = plain login oauthbearer xoauth2
default_internal_user = vmail
first_valid_uid = 0
hostname = ***DELETED***
mail_location = maildir:/data/mailboxes/%d/%n
mail_plugins = " fts fts_solr"
mail_privileged_group = 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
namespace inbox {
inbox = yes
location =
mailbox Archive {
auto = subscribe
special_use = \Archive
}
mailbox Drafts {
auto = subscribe
special_use = \Drafts
}
mailbox Junk {
auto = subscribe
special_use = \Junk
}
mailbox Sent {
auto = subscribe
special_use = \Sent
}
mailbox Trash {
auto = subscribe
special_use = \Trash
}
prefix =
}
passdb {
args = /usr/local/etc/dovecot/dovecot-sql.conf.ext
driver = sql
}
passdb {
args = /usr/local/etc/dovecot/dovecot-oauth2.conf.ext
driver = oauth2
mechanisms = xoauth2 oauthbearer
}
plugin {
antispam_backend = pipe
antispam_mail_notspam = learn_ham
antispam_mail_sendmail = /usr/bin/rspamc
antispam_mail_sendmail_args = -h;localhost:11334
antispam_mail_spam = learn_spam
antispam_spam = Junk
antispam_trash = Trash
fts = solr
fts_solr = url=http://localhost:8983/solr/dovecot
sieve = ~/.dovecot.sieve
sieve_before = /etc/dovecot/sieve/before.d
sieve_dir = ~/sieve
}
postmaster_address = ***DELETED***
protocols = imap lmtp sieve pop3
service auth-worker {
unix_listener auth-worker {
user = vmail
}
}
service auth {
inet_listener {
port = 1666
}
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0666
user = postfix
}
unix_listener auth-userdb {
group = vmail
mode = 0660
user = vmail
}
user = vmail
}
service imap-login {
inet_listener imap {
port = 0
}
}
service lmtp {
inet_listener lmtp {
port = 24
}
unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0666
user = postfix
}
user = vmail
}
service pop3-login {
inet_listener pop3 {
port = 0
}
}
ssl = required
ssl_cert =
Add arm64 support to docker image
I think the issue is here: ADD https://github.com/krallin/tini/releases/download/v0.19.0/tini /sbin/tini # buildkit tini has arm64 (and others) version. So it should be easy to make the container work with arm.
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.
Re: spf helo pass
On 2022-01-01 09:14, Peter wrote: On 1/01/22 12:56 am, Benny Pedersen wrote: if maillist all did the arc seal/ arc sign, before thay break dkim, then its still possible to verify orginal sender trust, bingo its just sad nearly all make it worse by dkim sign all forwarded mails, thay miss the dkim private key mostly to do this, no ? :=) The problem is there is a not insignificant number of recipient MTAs that check SPF/DKIM/DMARC but do not recognize ARC yet. If you rely on ARC signing then these MTAs will likely reject your mail. This means that the only reliable way to pass SPF, DKIM and DMARC if you're forwarding mail is: its basicly just statistik you say above 1. Check the inbound SPF, DKIM and DMARC and reject the mail if it doesn't pass. check spf helo, spf mfrom, check dkim, check arc in that order, but do not reject, current its only meta data collected to dmarc policy with can reject if sender wants it rejected, but this should relly not be rejected if its arc-signed / arc-sealed, this indicate a maillist where reject is not best way to solve spamming 2. Other anti-spam measures to try to absolutely minimize the amount of SPAM that you end up forwarding. its possible to unsubscribe 3. Remove any existing DKIM signature that includes the From: or Reply-To: headers or any other header or content that you will be modifying in the message. makes things worse 4. Rewrite the From: header to your domain name, add a Reply-To header with the original From: header's content. makes things worse 5. Do any other alterations, such as adding list-* headers modifying the Subject: header, etc. does not break dkim when adding new headers, but change signed headers does 6. DKIM sign the message from the domain you rewrote the From: header to. perfect forged mail can be tested in dkim adsp 7. Rewrite the envelope sender to your domain name. normal for maillists, does not break spf specs 8. Send out the message. and hope for no spf helo, spf pass if its spam :) The above assumes properly implemented SPF, DKIM and DMARC records for your domain. define properly That is the *only* way you can be fully certain that the forwarded message will pass SPF, DKIM and DMARC checks and therefore have the best chances of being received by the recipient. Anything else relies on implementation specifics of the sender and/or the recipient MTAs which may or may not make that possible. you need more meta data on diffrent maillists if you write this above we are OFF Topic, take debate offline from maillist
Re: spf helo pass
On 1/01/22 12:56 am, Benny Pedersen wrote: if maillist all did the arc seal/ arc sign, before thay break dkim, then its still possible to verify orginal sender trust, bingo its just sad nearly all make it worse by dkim sign all forwarded mails, thay miss the dkim private key mostly to do this, no ? :=) The problem is there is a not insignificant number of recipient MTAs that check SPF/DKIM/DMARC but do not recognize ARC yet. If you rely on ARC signing then these MTAs will likely reject your mail. This means that the only reliable way to pass SPF, DKIM and DMARC if you're forwarding mail is: 1. Check the inbound SPF, DKIM and DMARC and reject the mail if it doesn't pass. 2. Other anti-spam measures to try to absolutely minimize the amount of SPAM that you end up forwarding. 3. Remove any existing DKIM signature that includes the From: or Reply-To: headers or any other header or content that you will be modifying in the message. 4. Rewrite the From: header to your domain name, add a Reply-To header with the original From: header's content. 5. Do any other alterations, such as adding list-* headers modifying the Subject: header, etc. 6. DKIM sign the message from the domain you rewrote the From: header to. 7. Rewrite the envelope sender to your domain name. 8. Send out the message. The above assumes properly implemented SPF, DKIM and DMARC records for your domain. That is the *only* way you can be fully certain that the forwarded message will pass SPF, DKIM and DMARC checks and therefore have the best chances of being received by the recipient. Anything else relies on implementation specifics of the sender and/or the recipient MTAs which may or may not make that possible. Peter
