date:20200611


Am 12.06.2020 um 04:43 schrieb Ralph Seichter:

* Andreas Born:


I meant the different stages when receiving mails over SMTP [...]


I am well aware of the technical details of SMTP. Your comment is
unclear to me because the OP did not make any limitations on when he
wants to counter spam, so why would we artificially limit ourselves in
this discussion? 


THe OP wanted to send an additional mail back to possible unwanted 
senders. That's even worse than a DSN in my opinion. You suggested to 
reject mail directly during the smtp process.


Full ack!

I just talked about problems that existed in the past, that caused 
additional problems when trying to reject a mail after the SMTP DATA 
command. So my response was not about any limitation denoted by the OP, 
but about your suggestion that a prequeue-milter can even scan mail 
header and body as well before "hard rejecting" the mail.


This had some conflicts in earlier times, but it turnes out, that this 
problem is out-dated and no more existent.



SMTP allows rejecting messages even after the whole
body has been received (end of DATA phase in SMTP, EOM phase in the
milter protocol).


Yes. And it always has been. But i knew that this was not always 
respected by MTAs, even by some large email providers I had contact to.



for many years it was code of practice to send error/rejection codes
latest after the RCPT TO command [...]


Can you name examples? 


postfix.org itself had some information in its postconf section. There 
ist still an information about smtpd_relay_reject, that some clients 
mis-behave on error codes before RCTP TO (the other way around), and in 
the past there (somewhere) has been an info about issues sending them 
after DATA, too, because of mis-behaving clients. That was discussed in 
many postfix-setup-tutorials also. Reject on RCPT TO.


But okay, many years ago. I thought few thing don't change, some others 
do. But i never heard that this issue was ever solved.


So my fault. Friends? ;-)


I have never used a milter so restricted, nor
have I seen one being used.


Might be. But default configurations and most old tutorials have no 
smtpd_data_restrictions set up. And smtpd_data_end_restrictions did not 
even exist last time I changed my config. :)



Rejecting a mail AFTER the DATA command (when the content becomes
available) was discouraged because of incorrect behaving
MTAs. (e.g. generating backscatter, or even treating the mail as
successfully sent)


Again I am stumped by what you write. SMTP rejection does not generate
backscatter. 


Indeed; not, when Client (MTA) and Server (MX) behave correctly. But 
some MTAs did not. Maybe they do NOW, so everything is fine.


Mis-Behaving MTAs did generate DSNs on rejections after DATA, they sent 
it (under special circumstances like forwarding mails or multiple 
recipients) to their forged envelope-sender, so this is backscatter in 
my opinion. But they should not, because the mail was immediately rejected.


Other mail-providers did not respect these recjections as permanent as 
they should do, because they didn't really evaluate error responses 
after DATA, the treated it as underlying transmission Problem, therefore 
trying to resend...


And other providers did never generate an info to the user, that their 
mail did not arrive. A legal problem, when the recipient was a 
corporation and the mail a false positive etc..



Frankly, I see no use in discussing broken MTAs or milters,
real or imagined. Using milter-regex and other milters with Postfix
works fine as I described it. What you wrote therefore makes little
sense to me.


I agree, there is really no use in discussing broken Software; at least 
as long, as the resulting problems do not restrict/limit your 
configuration possibilities or otherwise causing additional Spam, e.g.


It was not about broken Milters, not at all.
It was about broken MTAs. And about correctly working MX-Server like 
postfix, which had to be configured in such a way, that different 
problems were circumvented. Like broken MTAs generating spam because of 
your MX Server behaving correctly by sending 5xx after DATA. You can do 
anything right, and at the same time a bad client can make things bad.


These problems really existed in the past, and I apologize if i'm 
completed out-of-date regarding these issues.



/ Andreas

Re: Doveadm Backup (other) issues

2020-06-11 Thread Gingko


Hello,

Sorry for the reply delay, I had to worry about something else …

Here is my *doveconf -n*:

# 2.3.4.1 (f79e8e7e4): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.4 ()
# OS: Linux 4.19.0-6-amd64 x86_64 Debian 10.4
# Hostname: /[my-host-name]/
auth_debug = yes
auth_debug_passwords = yes
auth_verbose = yes
auth_verbose_passwords = yes
imapc_features = rfc822.size fetch-headers
imapc_host = /[remote-imap-host]/
imapc_password = # hidden, use -P to show it
imapc_user = /[my-remote-user-name]/@/[with-domain]/
log_path = /var/log/dovecot.log
mail_debug = yes
mail_location = mbox:~/mail:INBOX=/var/mail/%u
mail_prefetch_count = 20
mail_privileged_group = mail
namespace compat1 {
  alias_for =
  hidden = yes
  list = no
  location =
  prefix = mail/
  separator = /
}
namespace compat2 {
  alias_for =
  hidden = yes
  list = no
  location =
  prefix = Mail/
  separator = /
}
namespace inbox {
  inbox = yes
  location =
  mailbox "&AMk-l&AOk-ments envoy&AOk-s" {
    special_use = \Sent
  }
  mailbox "&AMk-l&AOk-ments supprim&AOk-s" {
    special_use = \Trash
  }
  mailbox Brouillons {
    special_use = \Drafts
  }
  mailbox "Courrier ind&AOk-sirable" {
    special_use = \Junk
  }
  prefix =
}
passdb {
  driver = pam
}
passdb {
  args = scheme=MD5-CRYPT username_format=%u /etc/dovecot/users
  driver = passwd-file
}
plugin {
  sieve = file:~/sieve;active=~/.dovecot.sieve
}

ssl_ca = There is certainly something trivial there, but I'm not very used to 
advanced usage of Dovecot.


Regards,

Gingko

Le 08/06/2020 à 10:32, Sami Ketola a écrit :
On 7. Jun 2020, at 16.13, Gingko > wrote:


Hello,

I also have issues using Dovecot Backup.

I am trying to Backup (or possibly Sync - one way) a single user IMAP 
account from a remote server, unknown type, to my own server.


For that purpose, I defined the following parameters :

imapc_host = 
imapc_user =
imapc_password = 
imapc_features = rfc822.size

( has format: n...@example.com , 
and  is the name of the imap remote server that I use for 
getting mails)


… and then  I issued the following command:

doveadm backup -R -u > imapc:


... but doing this, I get the following answer:

dsync(): Info: imapc(:143): Connected to IP address>:143 (local 192.168.1.2:52940)
dsync(): Error: Failed to initialize user: namespace 
configuration error: Namespace mail/ can't have alias_for= to a 
different storage (different root dirs)


How can I solve this?

If there is something not matching between servers, I may eventually 
change configuration on my side, but I think I would first have to 
know which feature(s) I have to know from the remote server in order 
to create the matching one on my server.


Is there a way to list all relevant data coming from the remote server?

Also:

Doing this, is it necessary that the source user name be the same as 
the destination user name? Is it possible to backup an IMAP account 
to a user account having a completely different name?




Nope. Source and destination usernames can be different. Please post 
your doveconf -n as this is probably an error on your local config.


Sami

Re: handling spam from gmail.


Am 12.06.2020 um 04:43 schrieb Adi Pircalabu:

First thing first, this isn't necessary a Dovecot related thread and 


yeah, and i'm sorry for that. Just thought to give some information on 
an issue that actually turns out to be completely out-dated.


using a challenge-response system like the one suggested by the 
initiator ("click here if you're not yet another bloody SEO guru") is 
plain wrong for several reasons, 


full ack


$ telnet server 25
Trying x.x.x.x...
Connected to server
Escape character is '^]'.
220-server ESMTP Postfix <=== Postscreen trap here ;)
220 server ESMTP Postfix
HELO client.domain.com
250 server
MAIL FROM:<>
250 2.1.0 Ok
RCPT TO:
250 2.1.5 Ok
DATA
354 End data with .
From: Me
To: You
Subject: Test

SA GTube string here
.
550 5.7.1 Blocked, see you later.
QUIT
221 2.0.0 Bye
Connection closed by foreign host.

In this case the rejection comes after DATA, a content filter should be 
able to return either 4xx or 5xx *after* swallowing the entire email.


I know and I already tried out such a filtering long before. With lots 
of problems and long discussions to mailadmins of large providers. The 
result: specifications and reality do not always match. :-)



Maybe, and I really hope so, this problem no longer exists. I will
immediately reconfigure my mail system, if rejecting mails after DATA
will be safe and reliable nowadays.


Rejecting or deferring after DATA is perfectly fine these days. If the 
sending MTA, acting as a client in the SMTP conversation, doesn't behave 
properly to 5xx after DATA, it's not the recipient's MTA problem, the 
sender is broken and there's nothing the receiving MTA can do about it. 
Make it their problem, not yours.


Okay, makes sense!


/ Andreas

Re: handling spam from gmail.


Am 12.06.2020 um 04:28 schrieb Joseph Tam:


On Fri, 12 Jun 2020, Andreas Born wrote:

Maybe, and I really hope so, this problem no longer exists. I will 
immediately reconfigure my mail system, if rejecting mails after DATA 
will be safe and reliable nowadays.


In particular, bots don't hang around for the DATA response.

Any MTA that ignores SMTP responses for the DATA step would also ignore
common conditions like full mailbox.  Such brokeness and failure to
follow RFC is by itself grounds to reject the mail until the MTA software
is fixed.


Ok, that really makes sense.


One blacklist operator actually uses this as a criteria for blacklisting

 (Section: Tracking use of QUIT)
 http://wiki.junkemailfilter.com/index.php/Spam_DNS_Lists


That's helpful, thanks!


I issue post-DATA return codes, and I have yet, in decades of use, had
problems with legitimate senders.


I too had never problems with legitimate senders. (of course, they don't 
get rejected)


But I had -long ago- problems with large providers like gmx, hotmail or 
yahoo. E.g., sending rejected mails again and again, even sending DSNs 
to their (forged and forwarded) senders. But as said, long ago.


So times have changed, that's great.


/ Andreas

Re: handling spam from gmail.

* Andreas Born:

> I meant the different stages when receiving mails over SMTP [...]

I am well aware of the technical details of SMTP. Your comment is
unclear to me because the OP did not make any limitations on when he
wants to counter spam, so why would we artificially limit ourselves in
this discussion? SMTP allows rejecting messages even after the whole
body has been received (end of DATA phase in SMTP, EOM phase in the
milter protocol).

> for many years it was code of practice to send error/rejection codes
> latest after the RCPT TO command [...]

Can you name examples? I have never used a milter so restricted, nor
have I seen one being used.

> Rejecting a mail AFTER the DATA command (when the content becomes
> available) was discouraged because of incorrect behaving
> MTAs. (e.g. generating backscatter, or even treating the mail as
> successfully sent)

Again I am stumped by what you write. SMTP rejection does not generate
backscatter. Frankly, I see no use in discussing broken MTAs or milters,
real or imagined. Using milter-regex and other milters with Postfix
works fine as I described it. What you wrote therefore makes little
sense to me.

-Ralph

Re: handling spam from gmail.

2020-06-11 Thread Joseph Tam


On Fri, 12 Jun 2020, Andreas Born wrote:

Maybe, and I really hope so, this problem no longer exists. I will 
immediately reconfigure my mail system, if rejecting mails after DATA will be 
safe and reliable nowadays.


In particular, bots don't hang around for the DATA response.

Any MTA that ignores SMTP responses for the DATA step would also ignore
common conditions like full mailbox.  Such brokeness and failure to
follow RFC is by itself grounds to reject the mail until the MTA software
is fixed.

One blacklist operator actually uses this as a criteria for blacklisting

(Section: Tracking use of QUIT)
http://wiki.junkemailfilter.com/index.php/Spam_DNS_Lists

I issue post-DATA return codes, and I have yet, in decades of use, had
problems with legitimate senders.

Joseph Tam

Re: handling spam from gmail.


Am 12.06.2020 um 02:03 schrieb Ralph Seichter:

* Andreas Born:


There exists one problem: at this stage of mail reception you have no
body content nor header information on which a milter may perform
deeper analysis, only envelope data.


I am not sure what you mean by "this stage of mail reception", or what


I meant the different stages when receiving mails over SMTP:
(very short and incomplete,  I know):

1. MTA is connecting via SMTP, TLS, etc.
2. Identification (EHLO), Authentication, Protocol Extensions etc.
3. MTA send envelope information (MAIL TO, RCPT TO)
4. MTA sends message header and body (DATA, .)
5. Connection close (QUIT) or repeat from 3. for another mail
6. enqueuing mail(s)
7. Local Delivery

I was referring to what you wrote with:

>>> "Better to reject the offending message with a 5xx status code [...]"

You surely refer to the 5xx status codes from SMTP, and to reject the 
mail while receiving it via SMTP, instead of sending a DSN later on? So 
the sender knows that the mail was not accepted, and that it MUST NOT 
try to resend the mail again (as with 4xx status codes).


You further write:

> For example: Postfix supports both before-queue filters and 
after-queue filters. Milter-regex[1] supports both multi-header and body 
checks.


Of course, and there is nothing wrong with it. It just runs into the 
issue I tried to describe: incomplete SMTP implementations from MTAs.


Pre-queue filtering happens, before the mail was accepted to be queued. 
So a before-queue milter can trigger an 5xx status code to reject the 
mail. This code can be sent in response to steps 2, 3 or 4. According to 
the smtp specs. But for many years it was code of practice to send 
error/rejection codes latest after the RCPT TO command, and at this time 
the milter, independent of what software you use, has no information 
about email header or content. Rejecting a mail AFTER the DATA command 
(when the content becomes available) was discouraged because of 
incorrect behaving MTAs. (e.g. generating backscatter, or even treating 
the mail as successfully sent)


Maybe, and I really hope so, this problem no longer exists. I will 
immediately reconfigure my mail system, if rejecting mails after DATA 
will be safe and reliable nowadays.



/andreas

Re: executing script on mail arrival from sieve

2020-06-11 Thread Voytek Eymont

On Fri, June 12, 2020 3:53 am, @lbutlr wrote:
> On 11 Jun 2020, at 05:24, Voytek Eymont  wrote:

>> looking at wiki2, 'Pigeonhole Sieve Extprograms Plugin', is this what
>> would allow to execute my script on new mail arrival?
>
> Yes.
>
>
> This is what I have to auto=mark spam when it is moved too the Spam
> folder and to mark messages as seen when they are archived:

thanks very much for sharing this, much appreciated!
I'll try to follow through and, see how I manage

V

Re: SV: handling spam from gmail.

2020-06-11 Thread Joseph Tam


On Thu, 11 Jun 2020, lists wrote:


I get two or three of these a day.  They are not from Gmail but have a
"reply to" address that is a Gmail account.  The messages cone from an
email account that passes SPF and DKIM.  So the sender and reply
domains differ, but that isn't unique.  I have email that I need that
arrives like that.


This entire thread belongs on an anti-spam forum, but you might want to
check out

http://msbl.org/ebl.html

Joseph Tam

Re: handling spam from gmail.

* Andreas Born:

> There exists one problem: at this stage of mail reception you have no
> body content nor header information on which a milter may perform
> deeper analysis, only envelope data.

I am not sure what you mean by "this stage of mail reception", or what
software you are using that may be limited in such a particular manner,
but generally speaking you are wrong.

For example: Postfix supports both before-queue filters and after-queue
filters. Milter-regex[1] supports both multi-header and body checks. The
milter protocol itself allows for both header and body manipulation.

[1] http://www.benzedrine.ch/milter-regex.html

-Ralph

Re: handling spam from gmail.


Am 11.06.2020 um 19:15 schrieb Ralph Seichter:

Generating backscatter is definitely not a good move, and it is even
prone to punish yourself. Better to reject the offending message with
a 5xx status code and some explanatory text or the URL.

The various tests required to come to a decision about accepting or
rejecting the message can be executed in a milter. Milter-regex, for
example, is lightweight but still powerful enough to perform tests on
combinations of various headers and the body content. Beyond that, a
custom milter is always an option.


...and the body content...

There exists one problem: at this stage of mail reception you have no 
body content nor header information on which a milter may perform deeper 
analysis, only envelope data. The SMTP specs itself allow failure codes 
after any command, even a 5xx after the DATA command. Hoever, many MTAs 
still ignore error response codes after DATA and take the mail as sent, 
so that most mail servers will perform any error indication before DATA, 
at latest after RCPT TO. So the server has to accept mail first before 
it can scan its header and/or body, and would send out DSNs on rejection 
at this stage, probably causing backscatter as well.


I don't understand why this problem of ignoring data response codes even 
exists. It would be so much more practible to reject spam immediately 
after the body was scanned, i.e. after the DATA command, than to send 
out these DSNs.


Or does this issue no longer exist these days?

/andreas

Re: handling spam from gmail.

2020-06-11 Thread Benny Pedersen


On 2020-06-11 16:58, Richard Siddall wrote:


This seems similar to the long-dead Active Spam Killer
(https://directory.fsf.org/wiki/Active_Spam_Killer) with updates for
GDPR.


http://www.paganini.net/ask/

dead projects

Re: Doveadm Backup (other) issues

2020-06-11 Thread Gingko


Hello,

Sorry for the reply delay, I had to worry about something else â€¦

Here is my *doveconf -n*:

  # 2.3.4.1 (f79e8e7e4): /etc/dovecot/dovecot.conf
  # Pigeonhole version 0.5.4 ()
  # OS: Linux 4.19.0-6-amd64 x86_64 Debian 10.4
  # Hostname:/[my-host-name]/
  auth_debug = yes
  auth_debug_passwords = yes
  auth_verbose = yes
  auth_verbose_passwords = yes
  imapc_features = rfc822.size fetch-headers
  imapc_host =/[remote-imap-host]/
  imapc_password = # hidden, use -P to show it
  imapc_user =/[my-remote-user-name]/@/[with-domain]/
  log_path = /var/log/dovecot.log
  mail_debug = yes
  mail_location = mbox:~/mail:INBOX=/var/mail/%u
  mail_prefetch_count = 20
  mail_privileged_group = mail
  namespace compat1 {
alias_for =
hidden = yes
list = no
location =
prefix = mail/
separator = /
  }
  namespace compat2 {
alias_for =
hidden = yes
list = no
location =
prefix = Mail/
separator = /
  }
  namespace inbox {
inbox = yes
location =
mailbox "&AMk-l&AOk-ments envoy&AOk-s" {
  special_use = \Sent
}
mailbox "&AMk-l&AOk-ments supprim&AOk-s" {
  special_use = \Trash
}
mailbox Brouillons {
  special_use = \Drafts
}
mailbox "Courrier ind&AOk-sirable" {
  special_use = \Junk
}
prefix =
  }
  passdb {
driver = pam
  }
  passdb {
args = scheme=MD5-CRYPT username_format=%u /etc/dovecot/users
driver = passwd-file
  }
  plugin {
sieve =file:~/sieve;active=~/.dovecot.sieve
  }
  
  ssl_ca = 
  ssl_cert = There is certainly something trivial there, but I'm not very used to 
advanced usage of Dovecot.


Regards,

Gingko

Le 08/06/2020 Ã 10:32, Sami Ketola a Ã©crit :
On 7. Jun 2020, at 16.13, Gingko > wrote:


Hello,

I also have issues using Dovecot Backup.

I am trying to Backup (or possibly Sync - one way) a single user IMAP 
account from a remote server, unknown type, to my own server.


For that purpose, I defined the following parameters :

imapc_host = 
imapc_user =
imapc_password = 
imapc_features = rfc822.size

( has format: n...@example.com , 
and  is the name of the imap remote server that I use for 
getting mails)


â€¦ and then I issued the following command:

doveadm backup -R -u > imapc:


... but doing this, I get the following answer:

dsync(): Info: imapc(:143): Connected to IP address>:143 (local 192.168.1.2:52940)
dsync(): Error: Failed to initialize user: namespace 
configuration error: Namespace mail/ can't have alias_for= to a 
different storage (different root dirs)


How can I solve this?

If there is something not matching between servers, I may eventually 
change configuration on my side, but I think I would first have to 
know which feature(s) I have to know from the remote server in order 
to create the matching one on my server.


Is there a way to list all relevant data coming from the remote server?

Also:

Doing this, is it necessary that the source user name be the same as 
the destination user name? Is it possible to backup an IMAP account 
to a user account having a completely different name?




Nope. Source and destination usernames can be different. Please post 
your doveconf -n as this is probably an error on your local config.


Sami

RE: handling spam from gmail.

 


 > Wrong mailing list.  You need to ask on the list for the MTA you are 
 > using (Sendmail, Postfix, &c).

Yes will ask soon at sendmail.

 > Actually, this sounds like a job for a custom milter, which would 
look 
 > at the domain name of the sending system, and reject the mail with 
your 
 > message.  Dunno if there is one that works exactly like this.
 > 

I think also, I should have some contact coding milters. I think this 
could
be ok for things like this spamhaus bad tld list or so.

Re: Dovecot /VMWare Boxer

2020-06-11 Thread Sami Ketola




> On 11. Jun 2020, at 20.22, Ralph Seichter  wrote:
> 
> * Sami Ketola:
> 
>> They do not rely on Date header. Date header is not mandatory and also
>> it's not written on server side. It is written by the sender.
> 
> Could you please elaborate on "Date header is not mandatory"? As far as
> the message format goes, "Date" and "From" are actually the two required
> headers in every message (see RFC 5322), so I am not quite sure what you
> mean?


You are right. It seems to be mandated by RFC 5322. However you can't trust 
that it is present as there is quite many messages being sent that don't have 
it. 

Sami

Re: executing script on mail arrival from sieve

On 11 Jun 2020, at 05:24, Voytek Eymont  wrote:
> 
> looking at wiki2, 'Pigeonhole Sieve Extprograms Plugin', is this what
> would allow to execute my script on new mail arrival?

Yes.

This is what I have to auto=mark spam when it is moved too the Spam folder and 
to mark messages as seen when they are archived:

plugin {
  sieve_plugins = sieve_imapsieve sieve_extprograms
  #sieve_global = /usr/lib/dovecot/sieve/global/
  sieve_default = /usr/lib/dovecot/sieve/default.sieve
  sieve_default_name = spamassassin

  sieve_duplicate_default_period = 1h
  sieve_duplicate_max_period = 12d

  # From elsewhere to Spam folder
  imapsieve_mailbox1_name = Junk
  imapsieve_mailbox1_causes = COPY
  imapsieve_mailbox1_before = file:/usr/lib/dovecot/sieve/report-spam.sieve

  # From Spam folder to elsewhere
  imapsieve_mailbox2_name = *
  imapsieve_mailbox2_from = Junk
  imapsieve_mailbox2_causes = COPY
  imapsieve_mailbox2_before = file:/usr/lib/dovecot/sieve/report-ham.sieve

  sieve_pipe_bin_dir = /usr/lib/dovecot/sieve

  sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.environment
  sieve_extensions = +editheader

  sieve = file:~/.sieve;active=~/.active_sieve
  sieve_user_log = ~/sieve.log

  imapsieve_mailbox3_name = Archive
  imapsieve_mailbox3_causes = COPY
  imapsieve_mailbox3_before = file:/usr/lib/dovecot/sieve/mark-read.sieve

}

# cat /usr/lib/dovecot/sieve/report-spam.sieve  
[11:51] [/etc/dovecot]
require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "variables"];

if environment :matches "imap.user" "*" {
  set "username" "${1}";
}

pipe :copy "sa-learn-spam.sh" [ "${username}" ];

"sa-learn-spam.sh" is the name of the script:

# cat /usr/lib/dovecot/sieve/sa-learn-spam.sh
#!/bin/sh
exec /usr/local/bin/sa-learn -u ${1} --spam

# cat /usr/lib/dovecot/sieve/mark-read.sieve
require ["imap4flags"];
setflag "\\seen";



-- 
If you write the word "monkey" a million times, do you start to think
you're Shakespeare? -- Steven Wright

Re: handling spam from gmail.

On 11 Jun 2020, at 03:54, Marc Roos  wrote:
> Yes tell that to the people that create rhel6, rhel7 and rhel8 and give 
> lts support. 

Please post only properly quoted messages and do not top post.

> SpamAssassin 3.3.1 is also not very smart in 2020

Also, do not run old versions of Spamassasin. Especially not that old. SA 3.4 
was lrealsed SIX YEARS ago. 3.3.1 was released more than TEN years ago.

Ten.

Years.

-- 
"Are you pondering what I'm pondering?"
"I think so, Brain, but, the Rockettes? I mean, it's mostly girls,
isn't it?"

Re: handling spam from gmail.

On 11 Jun 2020, at 04:05, Hendrik Boom  wrote:
> I use greylisting with my postfix.  On Debian and Devuan th package is 
> called 'postgrey'.

As was recently discussed on the postfix list, this WILL result in lost mail, 
and it WILL screw with "enter this validation code" emails sent to users who 
will probably be quite annoyed at having to wait (possible longer than the 
token is valid) to login.

Greylisting sounds like a good idea, but like many things that sound good, it 
is not.

-- 
Hard work pays off in the future. Laziness pays off now.

Re: Dovecot /VMWare Boxer

* Sami Ketola:

> They do not rely on Date header. Date header is not mandatory and also
> it's not written on server side. It is written by the sender.

Could you please elaborate on "Date header is not mandatory"? As far as
the message format goes, "Date" and "From" are actually the two required
headers in every message (see RFC 5322), so I am not quite sure what you
mean?

-Ralph

Re: handling spam from gmail.

* Marc Roos:

> 3. system recognizes as this email never been seen before
> 4. auto reply with something like (maybe with a wait time of x hours):
>Your message did not receive the final recipient. You are sending 
>from a known spam provider

Generating backscatter is definitely not a good move, and it is even
prone to punish yourself. Better to reject the offending message with
a 5xx status code and some explanatory text or the URL.

The various tests required to come to a decision about accepting or
rejecting the message can be executed in a milter. Milter-regex, for
example, is lightweight but still powerful enough to perform tests on
combinations of various headers and the body content. Beyond that, a
custom milter is always an option.

-Ralph

Re: handling spam from gmail.

* Hendrik Boom:

> I use greylisting with my postfix. On Debian and Devuan th package is
> called 'postgrey'.

Classical, time-based greylisting like Postgrey is problematic in this
age of 2FA and other email-based confirmation codes. Besides, Postfix
has its own, superior mechanism called "Postscreen" built in.

This has recently been discussed once again, in-depth, on the Postfix
mailing list, so I suggest interested parties to check the ML archives.

-Ralph

Re: Read-flag of mails don't update

On 10 Jun 2020, at 23:19, @lbutlr  wrote:
> On 10 Jun 2020, at 23:18, @lbutlr  wrote:
>> IF it’s not permissions you need to provide doveconf -n output. Bloglines 
>> for any fall, panic, or error level events at a minimum.
> 
> Apologies, I did not see the attachments. Will look on a real screen later.

Looks like your main problem has ben solved, but I have a couple of comments on 
your doveconf:


>   args = scheme=CRYPT 

CRYPT is a poor choice. SHA256-CRYPT is a decent choice. SHA512-CRYPT too. I 
din't go with ARGON because at the time my toolchain didn't support libsodium 
and my machine doesn't have the memory for it.

> ssl_cipher_list = 
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA


Why are you doing this?



-- 
When this kiss is over it will start again But not be any different
could be exactly the same It's hard to imagine that nothing at
all Could be so exciting, could be this much fun

Re: Pigeonhole-sieve auto-reply

On 11 Jun 2020, at 02:03, Marc Roos  wrote:
> A vaction message does not need to be sending text about a leave of 
> absense. It is just a rule with criteria being executed. Change the rule 
> to whatever you want,

Ah, I had no idea. I've never used a vacation program and never would, so I did 
not even look.

> get to know the sieve 'language'.
> I asked once here something about executing rules on dragging messages 
> to mailboxes/folders, they refered me to imapsieve or sieveimap. Maybe 
> this could help you also.

Yeah, I already do that I just didn't see any way to reply to an email in 
anything I looked at, so I will go look at vacation.

-- 
You came in that thing? You're braver than I thought!

Re: handling spam from gmail.

2020-06-11 Thread Alexander Dalloz


Am 11.06.2020 um 16:58 schrieb Richard Siddall:

Marc Roos wrote:



I am sick of this gmail spam. Does anyone know a solution where I can do
something like this:

1. received email from adcpni...@gmail.com
2. system recognizes this email address has been 'whitelisted', continue
with 7.
3. system recognizes as this email never been seen before
4. auto reply with something like (maybe with a wait time of x hours):
    Your message did not receive the final recipient. You are sending
from a known spam provider
    network that is why we blocked your message. Please confirm that:
    - you are not a spammer and
    - you have permission to use the mail adress you send your message to
    - you and your provider agree to uphold GDPR legislation
    - you and your provider are liable for damages when breaching any of
the above.

    Click link to confirm and you agree with the above
    https://www.domainwithoutletsencryptcertificate.com/asdfasdfadsfaf

5. sender clicks confirm url
6. email address is added to some white list.
7. email is delivered to recipient.



This seems similar to the long-dead Active Spam Killer 
(https://directory.fsf.org/wiki/Active_Spam_Killer) with updates for GDPR.


The general name for such a system is challenge-response system.

https://en.wikipedia.org/wiki/Challenge%E2%80%93response_spam_filtering

There are enough reasons to discourage something like that.

Alexander

Re: handling spam from gmail.

2020-06-11 Thread Richard Siddall


Marc Roos wrote:



I am sick of this gmail spam. Does anyone know a solution where I can do
something like this:

1. received email from adcpni...@gmail.com
2. system recognizes this email address has been 'whitelisted', continue
with 7.
3. system recognizes as this email never been seen before
4. auto reply with something like (maybe with a wait time of x hours):
Your message did not receive the final recipient. You are sending
from a known spam provider
network that is why we blocked your message. Please confirm that:
- you are not a spammer and
- you have permission to use the mail adress you send your message to
- you and your provider agree to uphold GDPR legislation
- you and your provider are liable for damages when breaching any of
the above.



Click link to confirm and you agree with the above
https://www.domainwithoutletsencryptcertificate.com/asdfasdfadsfaf

5. sender clicks confirm url
6. email address is added to some white list.
7. email is delivered to recipient.



This seems similar to the long-dead Active Spam Killer 
(https://directory.fsf.org/wiki/Active_Spam_Killer) with updates for GDPR.

Re: Dovecot /VMWare Boxer

2020-06-11 Thread Sami Ketola



> On 11. Jun 2020, at 16.46, Djule Djukic  wrote:
> 
> 
> Hello all,
> 
> My name is Djule Djukic and I am working for Hipotekarna Banka from 
> Montenegro.
> We are using IMAP email server Dovecot version 2.1.17. As a email clients on 
> our corporate workstations we are using Thunderbird or WebMail and everything 
> is working fine.

This dovecot version is 7 years old already. Can you upgrade?

> 
> We decided to introduce MDM solution in our environment and we installed 
> VMWare WorkspaceOne (former Airwatch) which use Boxer as a mail client in App 
> per VPN scenario.
> When we syncronise email with  Boxer  we have found that the time and date 
> displayed for some messages  have been changed to the time at which the file 
> was synchronized.

I have no idea how does this "Boxer mail client app" fetch message date.

Can you record some imap rawlogs to find out if it uses IMAP FETCH to get the 
message INTERNALDATE or does it really try to parse it from mail headers?

https://wiki.dovecot.org/Debugging/Rawlog 


> Problem with some email clients is that they not look always for "Date:" from 
> email message header. The "Date:" header is usually the date the message was 
> written or sent the first time, at the writer side.
> This "Date:" header line is never changed by any transfer or copy.


They do not rely on Date header. Date header is not mandatory and also it's not 
written on server side. It is written by the sender.

Sami

Dovecot /VMWare Boxer

2020-06-11 Thread Djule Djukic

Hello all,

My name is Djule Djukic and I am working for Hipotekarna Banka from
Montenegro.
We are using IMAP email server Dovecot version 2.1.17. As a email
clients on our corporate workstations we are using Thunderbird or
WebMail and everything is working fine.

We decided to introduce MDM solution in our environment and we installed
VMWare WorkspaceOne (former Airwatch) which use Boxer as a mail client
in App per VPN scenario.
When we syncronise email with Boxer we have found that the time and
date displayed for some messages have been changed to the time at which
the file was synchronized.

This is not hapening with all messages. It is happening only with
messages in subfolders, never with Inbox.
It seems when messages is moved by some rule from WebMail or Thunderbird
from Inbox to some subfolder, Boxer is not able to read dates correctly,

By seraching on Internet we found couple of explanation what might be
possibel cause of this behaviour.

https://imapsync.lamiral.info/FAQ.d/FAQ.Dates.txt
https://serverfault.com/questions/588618/maintain-email-timestamp-when-transferring-between-email-servers-using-an-email
https://dovecot.org/pipermail/dovecot/2008-July/032165.html

Problem with some email clients is that they not look always for "Date:"
from email message header. The "Date:" header is usually the date the
message was written or sent the first time, at the writer side.

This "Date:" header line is never changed by any transfer or copy.
If an email client uses the "Date:" header for displaying the date of a
message then no problem in synchronization with wrong date should arise.
Obviously this is not a case with a Boxer email application.

We tried GMail and everything is working fine.

We are wondering if someone can explain what APPEND command could have
done in our case? Is it relevant at all for our case? Is it used somehow
by thunderbird or webmail clients?
Also we would like to hear from someone if there are some improvemnents
in further release of dovecot or some configuration that we can
implement in order to fix this?

Thank you in advanced for your suggestions and contribution,

Đule Đukić

Specijalista za informacionu bezbjednost / ISO

ĐuleĐukić

Specijalistaza informacionu bezbjednost / ISO

http://www.hipotekarnabanka.com/hb-content/uploads/2014/06/slika1.jpg

Re: Read-flag of mails don't update

2020-06-11 Thread Marius Rasch


Thank you alot! I'll wait for v2.3.11 to check if the problem is solved!

Am 11.06.20 um 15:04 schrieb Timo Sirainen:
On 10. Jun 2020, at 10.42, Marius Rasch > wrote:


Hi,

since one or two month I have a problem with Dovecot not updating the 
read-flag on mails using IMAP. I receive new mails, but when reading, 
they still unread on other devices (but shown as read on the first 
device).


When I remember correct, this problem doesn't come with an update of 
dovecot, but just occured at some time. But I've updated dovecot since 
then a few times.


Whenever a client connects to dovecot I get an panic in the log. I 
therefore added a log file and my dovecot configuration (is this fine 
or does it need to be in the mail body?). There are system information 
in the output of dovecot -n; the filesystem dovecot is running on is ext4.


Thanks! This crash is another v2.3.10 regression in the COPY/MOVE code. 
Fix will be in v2.3.11 and here also: 
https://github.com/dovecot/core/commit/203b2b709b0477be8753ea4ae7830bedbfebb268


If the read-flag problem happened before v2.3.10 also, it's probably not 
related to the crash but something to do with virtual folders not 
syncing flags correctly. There aren't any known problems with it right 
now though, so I'm not sure about it.

Re: Read-flag of mails don't update

2020-06-11 Thread Timo Sirainen

On 10. Jun 2020, at 10.42, Marius Rasch  wrote:
> 
> Hi,
> 
> since one or two month I have a problem with Dovecot not updating the 
> read-flag on mails using IMAP. I receive new mails, but when reading, they 
> still unread on other devices (but shown as read on the first device).
> 
> When I remember correct, this problem doesn't come with an update of dovecot, 
> but just occured at some time. But I've updated dovecot since then a few 
> times.
> 
> Whenever a client connects to dovecot I get an panic in the log. I therefore 
> added a log file and my dovecot configuration (is this fine or does it need 
> to be in the mail body?). There are system information in the output of 
> dovecot -n; the filesystem dovecot is running on is ext4.

Thanks! This crash is another v2.3.10 regression in the COPY/MOVE code. Fix 
will be in v2.3.11 and here also: 
https://github.com/dovecot/core/commit/203b2b709b0477be8753ea4ae7830bedbfebb268 

If the read-flag problem happened before v2.3.10 also, it's probably not 
related to the crash but something to do with virtual folders not syncing flags 
correctly. There aren't any known problems with it right now though, so I'm not 
sure about it.

Re: multiple logins that use the samemailbox

2020-06-11 Thread alex


Update:

One should be able to create actual aliases as show here:
https://dovecot.org/list/dovecot/2018-September/113082.html

Sorry for the noise.
Alex.

On 2020-06-08 13:45, alex wrote:

Version: 2.2.27 (c0f36b0)

Hi,

I inhertited a mailsetup that allow users to login to pop/imap with up 
to three different user names for the same mailbox. We use SQL and I 
think I can manage that with just pointing to the same mailbox with 
the same userid.


But I also use the quota plugin. And the quota plugin users the 
username (full e-mail address) to identify a mailbox. That can 
probably be solved to use the count: option in the quota plugin to 
store the quota-data in the dovcot index files.


But I was wondering if perhaps there is a better / alternative way to 
'alias' different logins to the same mailbox?


Thanks for any tips!

Alex.

Re: handling spam from gmail.

2020-06-11 Thread Stephen Satchell

Wrong mailing list.  You need to ask on the list for the MTA you are 
using (Sendmail, Postfix, &c).


Actually, this sounds like a job for a custom milter, which would look 
at the domain name of the sending system, and reject the mail with your 
message.  Dunno if there is one that works exactly like this.


On 6/11/20 1:19 AM, Marc Roos wrote:



I am sick of this gmail spam. Does anyone know a solution where I can do
something like this:

1. received email from adcpni...@gmail.com
2. system recognizes this email address has been 'whitelisted', continue
with 7.
3. system recognizes as this email never been seen before
4. auto reply with something like (maybe with a wait time of x hours):
Your message did not receive the final recipient. You are sending
from a known spam provider
network that is why we blocked your message. Please confirm that:
- you are not a spammer and
- you have permission to use the mail adress you send your message to
- you and your provider agree to uphold GDPR legislation
- you and your provider are liable for damages when breaching any of
the above.



Click link to confirm and you agree with the above
https://www.domainwithoutletsencryptcertificate.com/asdfasdfadsfaf

5. sender clicks confirm url
6. email address is added to some white list.
7. email is delivered to recipient.

executing script on mail arrival from sieve

2020-06-11 Thread Voytek Eymont

I currently have a basic script to process some mails, it runs from cron
every 10 minutes, basically, sieve copies some mails to subfolder on mail
arrival, script fetches mails if any from this subfolder then processes
these mail, get maybe 1 or 2 or often none
but cron runs the script every 10 minutes, most times not needed as
nothing is retrieved
it's pretty crude - but works

getmail fetches mails to local folder, deletes in subfolder
munpack mailfile to unMIME
links dumps HTML to txt

looking at wiki2, 'Pigeonhole Sieve Extprograms Plugin', is this what
would allow to execute my script on new mail arrival?

I can't quite figure out how to.. if anyone has any sample, I might try to
adapt to my need.. thanks (probably I should just leave like it is till I
understand the docs...)

thanks, V

RE: handling spam from gmail.



 >> Yes tell that to the people that create rhel6, rhel7 and rhel8 and 
give 
 >> lts support. 
 >
 >as said that has nothing to do with your wrong training and RHEL has
 >always the same problem: you can't package the latest and greatest 
shit
 >over 10 years because it requrires newer versions of dependencies
 >
 >so what you get with your lazyness by using a LTS distribution is a
 >"never change a running system, just fix the worst bugs and don't 
touch
 >anything else"
 >
 >upstream developers don't hold development for 10 years
 >
 >written from a Fedora workstation with kernel 5.6.18-200.fc31.x86_64
 >from last night realyed over a datacenter firewall and a mailserver
 >using the same kernel
 >
 >> Unless google pays you to train your software to mark their messages 
as 
 >> spam, you might want to consider yourself not to smart as well ;)
 >
 >unless i make good money from customers paying for a  nearly 100%
 >hitrate of spam combine with a zero-false-positive policy i am likely
 >smarter than you

I would argue it is quite difficult to identify intelligence. I am 
pretty
sure I would not start with your reasoning. I have a favourite German 
saying I like to quote in matters like these
 "gegen Dummheit kämpfen Götter selbst vergebens"

 >> My solution would solve the problem others create (see the other 
mail). 
 >> Your solution wastes your time and will always be carrying water to 
the 
 >> sea. I think if 50% of providers in the world would do this, it 
would 
 >> quickly be end of story for the spam originating from the networks 
like 
 >> google and amazon. 
 >
 >they won't give a shit and when i get such idiotic mails as you 
propose
 >i take the phone, call the sender and suggest to fire his mailadmin
 >better sooner than later
 >
 >> If there is a McDonalds build next to your home, and their clients 
throw 
 >> waste into your garden. You hold McDonalds liable for cleaning this 
up 
 >> not? Or are you also going to cleanup their mess indefinitely.
 >
 >what a nonsense

RE: handling spam from gmail.

 

Yes thanks, I know, however the criteria for putting emails into this 
procedure is a different subject. Just wondered what people are doing.


-Original Message-
To: dovecot@dovecot.org
Subject: Re: handling spam from gmail.

On Thu, Jun 11, 2020 at 10:19:50AM +0200, Marc Roos wrote:
> 
> 
> I am sick of this gmail spam. Does anyone know a solution where I can 
> do something like this:
> 
> 1. received email from adcpni...@gmail.com 2. system recognizes this 
> email address has been 'whitelisted', continue with 7.
> 3. system recognizes as this email never been seen before 4. auto 
> reply with something like (maybe with a wait time of x hours):
>Your message did not receive the final recipient. You are sending 
> from a known spam provider
>network that is why we blocked your message. Please confirm that:
>- you are not a spammer and
>- you have permission to use the mail adress you send your message 
to
>- you and your provider agree to uphold GDPR legislation
>- you and your provider are liable for damages when breaching any 
> of the above.
>
> 
>Click link to confirm and you agree with the above
>https://www.domainwithoutletsencryptcertificate.com/asdfasdfadsfaf
> 
> 5. sender clicks confirm url
> 6. email address is added to some white list.
> 7. email is delivered to recipient.

If you do this rgularly enough, sending these messages to what are 
likely forged return addresses, you might just end up being classified 
as a spam sender yourself.

-- hendrik

> 
> 
> 
> 
>

Re: handling spam from gmail.

2020-06-11 Thread Hendrik Boom

On Thu, Jun 11, 2020 at 10:19:50AM +0200, Marc Roos wrote:
> 
> 
> I am sick of this gmail spam. Does anyone know a solution where I can do 
> something like this:
> 
> 1. received email from adcpni...@gmail.com
> 2. system recognizes this email address has been 'whitelisted', continue 
> with 7.
> 3. system recognizes as this email never been seen before
> 4. auto reply with something like (maybe with a wait time of x hours):
>Your message did not receive the final recipient. You are sending 
> from a known spam provider
>network that is why we blocked your message. Please confirm that:
>- you are not a spammer and
>- you have permission to use the mail adress you send your message to
>- you and your provider agree to uphold GDPR legislation
>- you and your provider are liable for damages when breaching any of 
> the above.
>
> 
>Click link to confirm and you agree with the above
>https://www.domainwithoutletsencryptcertificate.com/asdfasdfadsfaf
> 
> 5. sender clicks confirm url
> 6. email address is added to some white list.
> 7. email is delivered to recipient.

If you do this rgularly enough, sending these messages to what are 
likely forged return addresses, you might just end up being classified 
as a spam sender yourself.

-- hendrik

> 
> 
> 
> 
>

Re: SV: handling spam from gmail.

2020-06-11 Thread Hendrik Boom

On Thu, Jun 11, 2020 at 05:02:03PM +0800, Plutocrat wrote:
> On 11/06/2020 16.26, Marc Roos wrote:
> > I know it is not dovecot who should fix this. But anyone using dovecot 
> > is using an MTA, and receiving spam ;) I know how to look at email 
> > headers. Spf and dkim is not solving anything here.
> 
> You can configure this sort of thing in postfix, exim etc. The part of the 
> mail system to do with RECEIVING emails. Not really a dovecot function. 
> 
> Look at greylisting as an option. That's basically delaying email from 
> unknown senders. 

I use greylisting with my postfix.  On Debian and Devuan th package is 
called 'postgrey'.

What it does is, opon receiving mail from a new sender, reply with a 
protocol code that indicates "service temporarily unavailable; try again 
later".  Real email senders will try again later.  Most, but not all, 
spammers don't bother.

It does mean that the email services of some legitimate senders will 
take that protocol code and tell the user that the email was 
undeliverable.  (so the senders tell me) But those services still 
do try later, and I do get the message.

Of course you can still whitelist, and this spamfighting won't happen 
for those sites.

-- hendrik

> Also blocklists
> Also consider setting up rules in spamassassin / rspamd
>

RE: handling spam from gmail.



Yes tell that to the people that create rhel6, rhel7 and rhel8 and give 
lts support. 

Unless google pays you to train your software to mark their messages as 
spam, you might want to consider yourself not to smart as well ;)

My solution would solve the problem others create (see the other mail). 
Your solution wastes your time and will always be carrying water to the 
sea. I think if 50% of providers in the world would do this, it would 
quickly be end of story for the spam originating from the networks like 
google and amazon. 

If there is a McDonalds build next to your home, and their clients throw 
waste into your garden. You hold McDonalds liable for cleaning this up 
not? Or are you also going to cleanup their mess indefinitely.






-Original Message-
From: Reindl Harald [mailto:h.rei...@thelounge.net] 
Sent: donderdag 11 juni 2020 11:09
To: Marc Roos; dominic; dovecot; lists; users
Subject: Re: handling spam from gmail.



Am 11.06.20 um 11:04 schrieb Marc Roos:
> I have got lots of shit coming from *.google.com like these:
> 
> X-Spam-Status: No, score=2.1 required=3.0 tests=BAYES_00

because you are too dumb to train your bayes

give me one such message and i am pretty sure it will fire BAYES_80 or
BAYES_99 which will burn it with fire and lead to a milter reject here

SpamAssassin 3.3.1 is also not very smart in 2020

so instead ask for dumb solutions which making you part of a bigger 
problem better do your homework

RE: SV: handling spam from gmail.

2020-06-11 Thread KOCIK Fabien (Acoss)

Hello,

> Also consider setting up rules in spamassassin / rspamd

Agree with that : for my own usage, I use spamassassin as content-filter (very 
simple to install) : 
https://www.vultr.com/docs/how-to-configure-spamassassin-with-postfix-on-ubuntu-16-04

My local.cf file is very simple :
rewrite_header Subject ***SPAM***
required_score 5.0
use_bayes 1
report_safe 0
trusted_networks 

add_header all X-Spam-AutoLearnStatus _AUTOLEARN_

You will still receive mails but with ***SPAM*** in subject and additional 
Header field X-Spam-Flag: YES
In Dovecot, simply configure a sieve script to put them in \Junk and mark as 
read (just to allow recovery possible if it was a real mail).
You can then regularly trash them using un croned doveadm expunge.

Regards
Fabien

RE: handling spam from gmail.



Your logics sucks. There is a difference between how email works and how 
spamassassin works. You are assuming that everyone in the world is using 
spamassassin by including it in 'how email works'.

Maybe you like to post a link to your bayes files


Am 11.06.20 um 11:13 schrieb Marc Roos:
> You do not understand how mail works. Google mail is only getting 
> through when spf checks and the likes are being passed.

unless you don't manage to get rid of BAYES_00 in case of clear spam 
messages don't tell me you understand how email works

RE: handling spam from gmail.

You do not understand how mail works. Google mail is only getting 
through when spf checks and the likes are being passed.

I am not creating any problems with this, I am just bouncing them back. 
Google has enough billions to handle these issues. If everyone would 
apply this procedures, people with legitimate email accounts would move 
from a  spam network to some other provider. People joining these 
providers are the problem, because it allows these networks to mix spam 
with legitimate email.

When clients start moving out, spam networks are becoming easier to hard 
block and these providers start thinking about their infrastructure and 
their bussines model. 
If everyone would be doing this, it is solving the spam problem.

My below procedure should be applicable for any network generating a lot 
of spam. 


-Original Message-
From: Reindl Harald [mailto:h.rei...@thelounge.net] 
Sent: donderdag 11 juni 2020 10:25
To: Marc Roos; dovecot; users
Subject: Re: handling spam from gmail.



Am 11.06.20 um 10:19 schrieb Marc Roos:
> I am sick of this gmail spam. Does anyone know a solution where I can 
> do something like this:
> 
> 1. received email from adcpni...@gmail.com 2. system recognizes this 
> email address has been 'whitelisted', continue with 7.
> 3. system recognizes as this email never been seen before 4. auto 
> reply with something like (maybe with a wait time of x hours):
>Your message did not receive the final recipient. You are sending 
> from a known spam provider
>network that is why we blocked your message. Please confirm that:
>- you are not a spammer and
>- you have permission to use the mail adress you send your message 
to
>- you and your provider agree to uphold GDPR legislation
>- you and your provider are liable for damages when breaching any 
> of the above.
>
> 
>Click link to confirm and you agree with the above
>https://www.domainwithoutletsencryptcertificate.com/asdfasdfadsfaf
> 
> 5. sender clicks confirm url
> 6. email address is added to some white list.
> 7. email is delivered to recipient.

and i am sick of people not understanding how email works! you don't 
send unasked mail to a in the most cases forged sender unless you want 
to be part of the problem

backscatters and brainless autoreplies have to be burnt with fire

Dovecot fs quota reports quota as byte

2020-06-11 Thread Kazim Koybasi

Hello,

My dovecot configuration is like below. My filesystem quota is reported as
kb and dovecot quota reported as bytes so dovecot quota becomes wrongly
greater than filesystem quota. How can I solve this issue? Any help
apretiated.

Quota name Type   Value   Limit
%
user   STORAGE 10428416 3242880
  321


# 2.2.36 (1f10bfa63): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.24 (124e06aa)
# OS: Linux 4.18.0-147.8.1.el8_1.x86_64 x86_64 CentOS Linux release
8.1.1911 (Core)
# Hostname: suretired
auth_mechanisms = plain login
auth_username_format = %Ln
debug_log_path = /var/log/dovecot.log
first_valid_uid = 1000
lda_mailbox_autocreate = yes
lda_mailbox_autosubscribe = yes
listen = *
mail_debug = yes
mail_location =
maildir:~/Maildir:INDEX=/var/no-quotas/index/%u:CONTROL=/var/no-quotas/control/%u
mail_plugins = quota
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 spamtest spamtestplus
mbox_write_locks = fcntl
namespace inbox {
  inbox = yes
  location =
  mailbox Drafts {
special_use = \Drafts
  }
  mailbox Junk {
auto = subscribe
special_use = \Junk
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox "Sent Messages" {
special_use = \Sent
  }
  mailbox Trash {
special_use = \Trash
  }
  prefix =
}
passdb {
  driver = pam
}
plugin {
  quota = fs:user
  sieve = file:~/sieve;active=~/.dovecot.sieve
  sieve_before = /etc/dovecot/sieve/default.sieve
  sieve_extensions = +spamtest +spamtestplus
  sieve_spamtest_max_value = 15
  sieve_spamtest_status_header = X-Spam-Score:
(-?[[:digit:]]+\.[[:digit:]]).*
  sieve_spamtest_status_type = score
}
protocols = imap pop3 lmtp sieve
service auth {
  unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0600
user = postfix
  }
  unix_listener auth-userdb {
group = postfix
mode = 0600
user = dovecot
  }
}
service lmtp {
  executable = lmtp -L
  inet_listener lmtp {
address = 127.0.0.1
port = 2424
  }
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0600
user = postfix
  }
}
service managesieve-login {
  inet_listener sieve {
port = 4190
  }
}
service managesieve {
  process_limit = 1024
}
service quota-warning {
  executable = script /usr/bin/quota-warning.sh
  unix_listener quota-warning {
group = dovecot
mode = 0600
user = dovecot
  }
  user = dovecot
}
ssl_cert =

Re: SV: handling spam from gmail.

2020-06-11 Thread Plutocrat

On 11/06/2020 16.26, Marc Roos wrote:
> I know it is not dovecot who should fix this. But anyone using dovecot 
> is using an MTA, and receiving spam ;) I know how to look at email 
> headers. Spf and dkim is not solving anything here.

You can configure this sort of thing in postfix, exim etc. The part of the mail 
system to do with RECEIVING emails. Not really a dovecot function. 

Look at greylisting as an option. That's basically delaying email from unknown 
senders. 
Also blocklists
Also consider setting up rules in spamassassin / rspamd

Re: SV: handling spam from gmail.

2020-06-11 Thread lists

I get two or three of these a day. They are not from Gmail but have a "reply 
to" address that is a Gmail account. The messages cone from an email account 
that passes SPF and DKIM. So the sender and reply domains differ, but that 
isn't unique. I have email that I need that arrives like that.

I am on the Postfix list where this does belong, but I looked at the problem 
and decided it isn't worth fixing. I suppose I could whitelist the senders who 
have sender and reply to domain differences, but then I would have to deal with 
the people I bounce the first time because they aren't white listed.

I suspect these spammers do have Gmail accounts but you can't report that 
address because technically no spam came from that account. You could report 
the sender account. However some days I get spam with the same reply to Gmail 
account but different sender account. 





  Original Message  


From: m.r...@f1-outsourcing.eu
Sent: June 11, 2020 1:26 AM
To: dovecot@dovecot.org; sebast...@sebbe.eu
Subject: RE: SV: handling spam from gmail.



I know it is not dovecot who should fix this. But anyone using dovecot
is using an MTA, and receiving spam ;) I know how to look at email
headers. Spf and dkim is not solving anything here.



-Original Message-
From: Sebastian Nielsen [mailto:sebast...@sebbe.eu]
Sent: donderdag 11 juni 2020 10:23
To: Marc Roos; 'dovecot'; 'users'
Subject: SV: handling spam from gmail.

This is not a job for dovecot. You should look into whatever is your MTA
(exim, postfix etc) and implement the solution there.

But my initial suggestion is to check SPF and DKIM of the email. Because
I know that gmail does terminate spammers quick, but if you don't
validate SPF or DKIM, you might be a victim of spoofed Gmail email.

Best regards, Sebastian Nielsen

-Ursprungligt meddelande-
Från: dovecot-boun...@dovecot.org  För Marc
Roos
Skickat: den 11 juni 2020 10:21
Till: dovecot ; users

Ämne: handling spam from gmail.



I am sick of this gmail spam. Does anyone know a solution where I can do
something like this:

1. received email from adcpni...@gmail.com 2. system recognizes this
email address has been 'whitelisted', continue with 7.
3. system recognizes as this email never been seen before 4. auto reply
with something like (maybe with a wait time of x hours):
   Your message did not receive the final recipient. You are sending
from a known spam provider
   network that is why we blocked your message. Please confirm that:
   - you are not a spammer and
   - you have permission to use the mail adress you send your message to
   - you and your provider agree to uphold GDPR legislation
   - you and your provider are liable for damages when breaching any of
the above.
  

   Click link to confirm and you agree with the above
   https://www.domainwithoutletsencryptcertificate.com/asdfasdfadsfaf

5. sender clicks confirm url
6. email address is added to some white list.
7. email is delivered to recipient.

RE: SV: handling spam from gmail.



I know it is not dovecot who should fix this. But anyone using dovecot 
is using an MTA, and receiving spam ;) I know how to look at email 
headers. Spf and dkim is not solving anything here.



-Original Message-
From: Sebastian Nielsen [mailto:sebast...@sebbe.eu] 
Sent: donderdag 11 juni 2020 10:23
To: Marc Roos; 'dovecot'; 'users'
Subject: SV: handling spam from gmail.

This is not a job for dovecot. You should look into whatever is your MTA 
(exim, postfix etc) and implement the solution there.

But my initial suggestion is to check SPF and DKIM of the email. Because 
I know that gmail does terminate spammers quick, but if you don't 
validate SPF or DKIM, you might be a victim of spoofed Gmail email.

Best regards, Sebastian Nielsen

-Ursprungligt meddelande-
Från: dovecot-boun...@dovecot.org  För Marc 
Roos
Skickat: den 11 juni 2020 10:21
Till: dovecot ; users 

Ämne: handling spam from gmail.



I am sick of this gmail spam. Does anyone know a solution where I can do 
something like this:

1. received email from adcpni...@gmail.com 2. system recognizes this 
email address has been 'whitelisted', continue with 7.
3. system recognizes as this email never been seen before 4. auto reply 
with something like (maybe with a wait time of x hours):
   Your message did not receive the final recipient. You are sending 
from a known spam provider
   network that is why we blocked your message. Please confirm that:
   - you are not a spammer and
   - you have permission to use the mail adress you send your message to
   - you and your provider agree to uphold GDPR legislation
   - you and your provider are liable for damages when breaching any of 
the above.
   

   Click link to confirm and you agree with the above
   https://www.domainwithoutletsencryptcertificate.com/asdfasdfadsfaf

5. sender clicks confirm url
6. email address is added to some white list.
7. email is delivered to recipient.

SV: handling spam from gmail.

2020-06-11 Thread Sebastian Nielsen

This is not a job for dovecot. You should look into whatever is your MTA
(exim, postfix etc) and implement the solution there.

But my initial suggestion is to check SPF and DKIM of the email. Because I
know that gmail does terminate spammers quick, but if you don't validate SPF
or DKIM, you might be a victim of spoofed Gmail email.

Best regards, Sebastian Nielsen

-Ursprungligt meddelande-
Från: dovecot-boun...@dovecot.org  För Marc
Roos
Skickat: den 11 juni 2020 10:21
Till: dovecot ; users 
Ämne: handling spam from gmail.



I am sick of this gmail spam. Does anyone know a solution where I can do 
something like this:

1. received email from adcpni...@gmail.com
2. system recognizes this email address has been 'whitelisted', continue 
with 7.
3. system recognizes as this email never been seen before
4. auto reply with something like (maybe with a wait time of x hours):
   Your message did not receive the final recipient. You are sending 
from a known spam provider
   network that is why we blocked your message. Please confirm that:
   - you are not a spammer and
   - you have permission to use the mail adress you send your message to
   - you and your provider agree to uphold GDPR legislation
   - you and your provider are liable for damages when breaching any of 
the above.
   

   Click link to confirm and you agree with the above
   https://www.domainwithoutletsencryptcertificate.com/asdfasdfadsfaf

5. sender clicks confirm url
6. email address is added to some white list.
7. email is delivered to recipient.








smime.p7s
Description: S/MIME Cryptographic Signature

handling spam from gmail.




I am sick of this gmail spam. Does anyone know a solution where I can do 
something like this:

1. received email from adcpni...@gmail.com
2. system recognizes this email address has been 'whitelisted', continue 
with 7.
3. system recognizes as this email never been seen before
4. auto reply with something like (maybe with a wait time of x hours):
   Your message did not receive the final recipient. You are sending 
from a known spam provider
   network that is why we blocked your message. Please confirm that:
   - you are not a spammer and
   - you have permission to use the mail adress you send your message to
   - you and your provider agree to uphold GDPR legislation
   - you and your provider are liable for damages when breaching any of 
the above.
   

   Click link to confirm and you agree with the above
   https://www.domainwithoutletsencryptcertificate.com/asdfasdfadsfaf

5. sender clicks confirm url
6. email address is added to some white list.
7. email is delivered to recipient.

RE: Pigeonhole-sieve auto-reply