Re: your mail

2020-11-17 Thread Chris Bennett
On Tue, Nov 17, 2020 at 05:29:36PM +0100, Matthieu C wrote:
>  Hi,
> 
> I am new to mail servers, and I ran into a nice tutorial from a French NGO.
> However, I'd like to tweak a bit my configuration, and I cannot find a
> proper way to achieve my goal: I want to discard mails whose recipient is
> the address my_system_u...@my-domain.net (and r...@my-domain.net and so
> on), while accepting mails to be routed to my_system_user, through a list
> of aliases or virtual users. In fact, I want all the mails to go through
> this system user, and to be read by a unique dovecot account (hence, I'd
> say the simplest way to do is to have an unique Maildir?).

You don't have to use virtual users, but if you want separate Maildir's,
then virtual users through dovecot works nice.
I use usernames as chris@bennettconstruction instead of just chris.
But this is mostly a matter of preference. I have multiple domains, so
that is pretty necessary for me to avoid confusion. Dovecot explains
this moderately well and has a mailing list that's active.

> 
> I created a thread on Stack Overflow for that matter:
> https://stackoverflow.com/questions/64715521/prevent-mailing-to-my-username-in-opensmtp-config
> ; its content is below:
> 
> > I just set up my own mail server at home with OpenSMTP and Dovecot (I used 
> > this
> > tutorial
> > 
> > from Framasoft). I don't like the idea that people can mail to 
> > *my_system_u...@my-domain.net
> > * or *r...@my-domain.net
> > * (or any other system user), although I'll use this
> > only *my_system_user* account to receive my mails.
> >
> > That's why I added root: /dev/null and my_system_u...@my-domain.net:
> > /dev/null to my /home/my_system_user/.myaliases file (+ makemap -t
> > aliases ~/.myaliases). But I still receive the mails for 
> > *my_system_u...@my-domain.net
> > *. Maybe I shouldn't go through the hassle
> > of preventing this?

Probably not easily, but my-domain.net is the server's domain. That's
tacked on by default. Someone probably has a fix for this.


> >
> > table aliases file:/etc/aliases
> > table own_aliases file:/home/my_system_user/.myaliases
> >
> > pki mail.my-domain.net key 
> > "/etc/letsencrypt/live/mail.my-domain.net/privkey.pem"
> > pki mail.my-domain.net certificate 
> > "/etc/letsencrypt/live/mail.my-domain.net/cert.pem"
> >
> > # Deliver
> > listen on lo
> > listen on lo port 10029 tag DKIM
> > listen on lo port 10036 tag ANTISPAM
> > listen on eth0 port 25  hostname mail.my-domain.net tls pki 
> > mail.my-domain.net
> > listen on eth0 port 587 hostname mail.my-domain.net tls-require pki 
> > mail.my-domain.net auth
> >
> > accept tagged ANTISPAM for any alias  deliver to maildir 
> > "~/Maildir"
> > accept from local for local alias  deliver to maildir "~/Maildir"
> > #accept from any for domain "my-domain.net" alias  deliver to 
> > maildir "~/Maildir"
> >
> > # antispam
> > accept from any for domain "my-domain.net" relay via smtp://127.0.0.1:10035
> >
> > # Relay
> > # dkim tagged can be sent
> > accept tagged DKIM for any relay hostname mail.my-domain.net
> > # if not dkim tagged, send it to dkimproxy
> > accept from local for any relay via smtp://127.0.0.1:10028 hostname 
> > mail.my-domain.net
> >
> > In my search, I found out that virtual users could be a solution (source)
> > ,
> > but it seems overkill to me (setting up a new *vmail* user, new password
> > table, new services...): I have only one repicient account with multiple
> > (~10) aliases.

I use neomutt. It's a bit confusing, but it's very easy to setup account
and folder hooks to let you put all 10 aliases into one .neomuttrc
I have 5 in one .neomuttrc.
Other email clients should be able to do the same.
neomutt-users mailing list is also active and helpful.

I thought using vmail was weird myself at first, but it works like a
charm. I use /home/vmail, others /var/vmail. It doesn't really matter
where as long as you set HOME for it right.

I actually decided to use postgresql with dovecot for passwords and
users, etc. BSD auth is scheduled to be removed at some point in the
future, so consider not using it for dovecot or you *might* have to
change it later.

Good luck,
Chris Bennett


> Any help is appreciated!
> Best regards,
> 
> choumat



Re: Sample Procedure and commands for clearing Spam from your mail queues

2016-07-20 Thread Craig Skinner
On Tue, 19 Jul 2016 16:03:42 +0200 Christian Kellermann wrote:
> Using a blacklist in smtpd.conf and updating that list would spare you
> the troubles of touching the packet filter rules.
> 
> Or am I missing something?

# spamdb -t -a ip.ad.dr.ess

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org



Re: Sample Procedure and commands for clearing Spam from your mail queues

2016-07-19 Thread Christian Kellermann
Hi!

* Tom Smyth  [160719 15:48]:
> 1)#  Turn off MTA ... this will let our mail server accept mail but it wont
>forward it ...
> smtpctl pause mta
> 2) less /var/log/maillog   # this will let you look for the offending
>Source IP ...
> 3) edit /etc/pf.conf and replace SPAM_SRC_IP with ip of spammer
> block in quick on egress proto tcp from SPAM_SRC_IP
> 4) pfctl -nf /etc/pf.conf# check the syntax of the firewall rule
>   set  (no output is good)
> 5) pfctl -f /etc/pf.conf  # load the rule set
> 6) pfctl -sr   # show firewall rule set

Using a blacklist in smtpd.conf and updating that list would spare you
the troubles of touching the packet filter rules.

Or am I missing something?

Kind regards,

Christian

--
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org



Sample Procedure and commands for clearing Spam from your mail queues

2015-09-01 Thread Tom Smyth
Hi Lads,

I have had the unfortunate experience of having a client of my ISP fill my
server queues with spam... I know I will have to increase my spam
prevention measures, but for those of you who may experience the same I
have a rough procedure for clearing down the spam in the mail queueus,

this procedure shows an admin how to quarantine the offending client,
search for spam messages in the queue and remove the spam messages,


on that note it would be useful to have a way to remove all mails in a mail
queue based on sender email address,  / source Ip address  I have listed a
clunky approach for "'closing the barn door after the horse has bolted"

1)#  Turn off MTA ... this will let our mail server accept mail but it wont
   forward it ...
smtpctl pause mta
2) less /var/log/maillog   # this will let you look for the offending
   Source IP ...
3) edit /etc/pf.conf and replace SPAM_SRC_IP with ip of spammer
block in quick on egress proto tcp from SPAM_SRC_IP
4) pfctl -nf /etc/pf.conf# check the syntax of the firewall rule
  set  (no output is good)
5) pfctl -f /etc/pf.conf  # load the rule set
6) pfctl -sr   # show firewall rule set


Repeat this process on all the mail servers,

now there can be 1000s of mails that could result in further blacklisting
so it is best to delete the spam from the mail servers do this on both
servers
 in parallel to speed up resolution

7) smtpctl show queue   # shows mails in the queue and look for
patterns
  from or to a particular spam address  eg
sources...@address.com

8) smtpctl show queue |grep sourcespam@address >list_of_spam_In_queue

9)  cut -d \| -f1 list_of_spam_In_queue >spamenvelopenumbers
# the above line puts the spam envelope numbers in a single colum text file

10) vi spamenvelopenumbers# edit the envelope numbers file and
#insert smtpctl remove at the start of each line  to do this open the file
in vi ,
a) hit esc then paste the following line
:%s/^/smtpctl remove  /

d) hit enter
11) save the file  by hiting esc and paste the following line
:wq
12) chmod +x spamenvelopenumbers

13) ./spamenvelopenumbers  >/dev/null  # removes spam from queue but this
can take a
#while
14) smtpctl show queue   # check for more spam and repeat process 8 -13
as
#required
15) once the queue only has legitimate mail you are ready to de-list your
#server IP  from spam lists
16) smtcptl resume mta  #once you have removed the ips from the spam
lists
#you can restart the MTA...


I hope this helps

-- 
Kindest regards,
Tom Smyth