A problem I'm not sure how best to solve

2018-10-08 Thread Phil Stracchino
I have a perplexing puzzle thrust upon me.

Consider the following:

Oct  8 15:55:33 minbar postfix/smtpd[7422]: NOQUEUE: reject: RCPT from
rs230.mailgun.us[209.61.151.230]: 551 5.1.8 :
Sender address rejected: Domain not found;
from=
to= proto=ESMTP helo=


mailgun.us is connecting with a good HELO, and appears to be authorized
to send mail on behalf of pluspora.com, but the mail has a sender
address that is bad because mg.pluspora.com does not resolve in DNS, and
so the mail is rejected.

I want to TEMPORARILY (I hope) whitelist redac...@mg.pluspora.com as a
sender address as long as the mail is being sent by mailgun.us.

How would you do it?



-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958


Re: Forcing local users to use submission for all outbound email

2018-10-08 Thread Ignacio Garcia
El lun., 8 oct. 2018 a las 17:58, Christos Chatzaras ()
escribió:

>
>
> Κeep in mind that depending on your setup using authorized_submit_users
> maybe doesn't allow to send system messages, for example if you use "quota
> warning" with dovecot.
>
> If you only do PHP hosting try to disable mail() from php.ini and use a
> firewall to not allow direct outgoing connections to port 25 for users but
> only for root, postfix, and maybe some other system accounts.
>
> This will take care most of spam sent from hacked hosting accounts.
>

Hmm, you're right. However, some of my servers host many shell accounts,
and for us it's more convenient to whitelist all system users rather than
blacklisting all shell users one after another. Nevertheless this is
something I still have to investigate and test in more depth. Thanks so
much for your feedback

Best regards,

Ignacio


Re: Forcing local users to use submission for all outbound email

2018-10-08 Thread Christos Chatzaras

> On 8 Oct 2018, at 18:23, Ignacio Garcia  wrote:
> 
> El lun., 8 oct. 2018 a las 16:51, Noel Jones ( >) escribió:
> On 10/8/2018 6:17 AM, Ignacio Garcia wrote:
> > Hi there!
> > 
> > I've been reading the documentacion as well as googling around but
> > I've been unable to figure this out:
> > 
> > I have several hosting servers. I'd like all web sites hosted in
> > those servers not to be able to send outbound mail without
> > authenticating first. Same thing for shell users.  What I'm really
> > trying to achieve is that everybody (local accounts and php scripts
> > running under www-data) will be forced to use the submission service
> > (smtp-auth, tls activated) for all outbound emails, keeping
> > non-authenticated connections just for internal emails (usually from
> > services to the system administrator)
> > 
> > Any guru willing to point me into the right direction? TIA!!
> > 
> > Ignacio
> 
> http://www.postfix.org/postconf.5.html#authorized_submit_users 
> 
> 
> Probably something like
> 
> # main.cf 
> authorized_submit_users = root, cron
> (add any other service owners that need to send mail)
> 
> and also remove "permit_mynetworks" from
> smtpd_recipient_restrictions and from smtpd_relay_restrictions.
> 
> 
> 
> 
>   -- Noel Jones
> 
> Noel, thank you so much. You saved my day! This is more restrictive than I 
> wanted but it'll do. Initial testings show it works ok. Now I have to find 
> out all service accounts that send email periodically
> 
> For those of you who might be running ispconfig and want to restrict the use 
> of sendmail to created email accounts in ispconfig and service users only:
> 
> authorized_submit_users = root, cron, serviceuser1, serviceuser2, ... , 
> proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf 
> 
> 
> Again, thanks so much
> 
> Ignacio


Κeep in mind that depending on your setup using authorized_submit_users maybe 
doesn't allow to send system messages, for example if you use "quota warning" 
with dovecot.

If you only do PHP hosting try to disable mail() from php.ini and use a 
firewall to not allow direct outgoing connections to port 25 for users but only 
for root, postfix, and maybe some other system accounts.

This will take care most of spam sent from hacked hosting accounts.

Re: Could you please explain a warning message

2018-10-08 Thread Allen Coates
Thanks for your reply - I am reassured.

My server is a slow machine with limited memory - not much better than a 
Raspberry Pi, but designed to run 24/7 - so it
is not surprising that processes will conflict from time to time.

One warning in eight months is more than acceptable :-)

Thanks again

Allen C


On 08/10/18 12:03, Ralf Hildebrandt wrote:
> * Allen Coates :
>> Yesterday I saw the following warning message in my logs:-
>>
>> 2018-10-06T14:11:19+01:00 geronimo postfix/postscreen[8194]: warning: 
>> psc_cache_update: btree:/var/lib/postfix/postscreen_cache update average 
>> delay is 151 ms
> 
> Oct  2 02:01:40 mail-cbf postfix/postscreen[23257]: warning: 
> psc_cache_update: btree:/var/lib/postfix/postscreen_cache update average 
> delay is 343 ms
> Oct  2 02:03:16 mail-cbf postfix/postscreen[23257]: warning: 
> psc_cache_update: btree:/var/lib/postfix/postscreen_cache update average 
> delay is 155 ms
> Oct  3 18:34:07 mail-cbf postfix/postscreen[23257]: warning: 
> psc_cache_update: btree:/var/lib/postfix/postscreen_cache update average 
> delay is 137 ms
> Oct  8 11:21:19 mail-cbf postfix/postscreen[65199]: warning: 
> psc_cache_update: btree:/var/lib/postfix/postscreen_cache update average 
> delay is 112 ms
> 
> Quoting from 
> http://postfix.1071664.n5.nabble.com/psc-cache-update-td10059.html
> 
> "It is a bit sluggish. The warning threshold is 100ms. It should not 
> take this long to insert one key/pair into the database. Perhaps your 
> system's disk is very busy, or you're on a VM slice, or your clock is 
> not stable. If this happens frequently you need to find out why."
> 
> and
> 
> "If this happens often, this means that postscreen cannot handle 
> more than 10 SMTP connections per second, or that your system clock 
> is jumping (as in: running inside a VM). 
> 
> I see the warning once a day on my lightly-loaded server with a 
> single 15kRPM disk under an ancient CPU; the timing suggests that 
> this happens while some cron job is doing house cleaning. 
> 
> I added this check because someone insisted on running postscreen 
> on top of an SQL database, and complained that postscreen performance 
> was erratic. After I added the warning he stopped complaining."
> 


Re: Forcing local users to use submission for all outbound email

2018-10-08 Thread Ignacio Garcia
El lun., 8 oct. 2018 a las 16:51, Noel Jones ()
escribió:

> On 10/8/2018 6:17 AM, Ignacio Garcia wrote:
> > Hi there!
> >
> > I've been reading the documentacion as well as googling around but
> > I've been unable to figure this out:
> >
> > I have several hosting servers. I'd like all web sites hosted in
> > those servers not to be able to send outbound mail without
> > authenticating first. Same thing for shell users.  What I'm really
> > trying to achieve is that everybody (local accounts and php scripts
> > running under www-data) will be forced to use the submission service
> > (smtp-auth, tls activated) for all outbound emails, keeping
> > non-authenticated connections just for internal emails (usually from
> > services to the system administrator)
> >
> > Any guru willing to point me into the right direction? TIA!!
> >
> > Ignacio
>
> http://www.postfix.org/postconf.5.html#authorized_submit_users
>
> Probably something like
>
> # main.cf
> authorized_submit_users = root, cron
> (add any other service owners that need to send mail)
>
> and also remove "permit_mynetworks" from
> smtpd_recipient_restrictions and from smtpd_relay_restrictions.
>
>
>
>
>   -- Noel Jones
>

Noel, thank you so much. You saved my day! This is more restrictive than I
wanted but it'll do. Initial testings show it works ok. Now I have to find
out all service accounts that send email periodically

For those of you who might be running ispconfig and want to restrict the
use of sendmail to created email accounts in ispconfig and service users
only:

authorized_submit_users = root, cron, serviceuser1, serviceuser2, ... ,
proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf

Again, thanks so much

Ignacio


Re: Forcing local users to use submission for all outbound email

2018-10-08 Thread Noel Jones
On 10/8/2018 6:17 AM, Ignacio Garcia wrote:
> Hi there!
> 
> I've been reading the documentacion as well as googling around but
> I've been unable to figure this out:
> 
> I have several hosting servers. I'd like all web sites hosted in
> those servers not to be able to send outbound mail without
> authenticating first. Same thing for shell users.  What I'm really
> trying to achieve is that everybody (local accounts and php scripts
> running under www-data) will be forced to use the submission service
> (smtp-auth, tls activated) for all outbound emails, keeping
> non-authenticated connections just for internal emails (usually from
> services to the system administrator)
> 
> Any guru willing to point me into the right direction? TIA!!
> 
> Ignacio

http://www.postfix.org/postconf.5.html#authorized_submit_users

Probably something like

# main.cf
authorized_submit_users = root, cron
(add any other service owners that need to send mail)

and also remove "permit_mynetworks" from
smtpd_recipient_restrictions and from smtpd_relay_restrictions.




  -- Noel Jones


Re: about mysql query and input keys

2018-10-08 Thread Phil Stracchino
On 10/8/18 6:42 AM, Manuel Mely wrote:
> Well the tables look basically like this:
> 
> domain: id (binary), name (string), ... other fields
> external_domain: id (binary), name (string)
> domain_external_domain_association: id(binary), domain__id(binary),
> external_domain(binary), receive (int), send (int)
> 
> So, the idea is that virtual domains (domain table) can be configured to
> send or receive from the internet or from/to allowed external domains.
> Therefore the domain_external_domain_association table.
> So i can ask something like, for the virtual domain X, is there any
> association to external_domain entries.
> 
> query= SELECT [OK OR REJECT GOES
> HERE] FROM domain_external_domain_association  AS deda
> JOIN domain as d ON deda.domain_id = d.id 
> JOIN external_domain as ed ON deda.external_domain_id = ed.id
>  WHERE d.name  = 'HERE MY VDOMAIN' AND
> deda.receive = 1 AND ed.name  = '%d'
> 
> d.name  => should be recipient domain.
> ed.name  => is the sender domain, which works fine with
> %d, as I have another check before with a similar query.

OK, so %d gets substituted with domain name?


> The problem is, I want to use in a check_sender_access information about
> the recipient (for the joins in the query), which i think does not work.

Yeah, I don't see anything wrong with the query itself, but whether
it'll work in a check_sender_access rule is another question, which I
can't answer because I've never tried to do that.


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958


Forcing local users to use submission for all outbound email

2018-10-08 Thread Ignacio Garcia
Hi there!

I've been reading the documentacion as well as googling around but I've
been unable to figure this out:

I have several hosting servers. I'd like all web sites hosted in those
servers not to be able to send outbound mail without authenticating first.
Same thing for shell users.  What I'm really trying to achieve is that
everybody (local accounts and php scripts running under www-data) will be
forced to use the submission service (smtp-auth, tls activated) for all
outbound emails, keeping non-authenticated connections just for internal
emails (usually from services to the system administrator)

Any guru willing to point me into the right direction? TIA!!

Ignacio


Re: Could you please explain a warning message

2018-10-08 Thread Ralf Hildebrandt
* Allen Coates :
> Yesterday I saw the following warning message in my logs:-
> 
> 2018-10-06T14:11:19+01:00 geronimo postfix/postscreen[8194]: warning: 
> psc_cache_update: btree:/var/lib/postfix/postscreen_cache update average 
> delay is 151 ms

Oct  2 02:01:40 mail-cbf postfix/postscreen[23257]: warning: psc_cache_update: 
btree:/var/lib/postfix/postscreen_cache update average delay is 343 ms
Oct  2 02:03:16 mail-cbf postfix/postscreen[23257]: warning: psc_cache_update: 
btree:/var/lib/postfix/postscreen_cache update average delay is 155 ms
Oct  3 18:34:07 mail-cbf postfix/postscreen[23257]: warning: psc_cache_update: 
btree:/var/lib/postfix/postscreen_cache update average delay is 137 ms
Oct  8 11:21:19 mail-cbf postfix/postscreen[65199]: warning: psc_cache_update: 
btree:/var/lib/postfix/postscreen_cache update average delay is 112 ms

Quoting from http://postfix.1071664.n5.nabble.com/psc-cache-update-td10059.html

"It is a bit sluggish. The warning threshold is 100ms. It should not 
take this long to insert one key/pair into the database. Perhaps your 
system's disk is very busy, or you're on a VM slice, or your clock is 
not stable. If this happens frequently you need to find out why."

and

"If this happens often, this means that postscreen cannot handle 
more than 10 SMTP connections per second, or that your system clock 
is jumping (as in: running inside a VM). 

I see the warning once a day on my lightly-loaded server with a 
single 15kRPM disk under an ancient CPU; the timing suggests that 
this happens while some cron job is doing house cleaning. 

I added this check because someone insisted on running postscreen 
on top of an SQL database, and complained that postscreen performance 
was erratic. After I added the warning he stopped complaining."

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein


Could you please explain a warning message

2018-10-08 Thread Allen Coates
Yesterday I saw the following warning message in my logs:-

2018-10-06T14:11:19+01:00 geronimo postfix/postscreen[8194]: warning: 
psc_cache_update:
btree:/var/lib/postfix/postscreen_cache update average delay is 151 ms

A tenth of a second is an ENORMOUS delay for an SSD, and my immediate thought 
was/is an incipient disc failure, but
the monthly disc tests say 95 percent of the life expectancy remains.

I have swept my logs since February and this is the only instance of the 
message.

I am operating a domestic server (50 messages a day), running on a Synology NAS 
device, with things in the background
I can't turn off.

Could someone please explain what this message implies.

Many thanks

Allen C

Perhaps I should get some back-ups done :-)


Re: about mysql query and input keys

2018-10-08 Thread Manuel Mely
Well the tables look basically like this:

domain: id (binary), name (string), ... other fields
external_domain: id (binary), name (string)
domain_external_domain_association: id(binary), domain__id(binary),
external_domain(binary), receive (int), send (int)

So, the idea is that virtual domains (domain table) can be configured to
send or receive from the internet or from/to allowed external domains.
Therefore the domain_external_domain_association table.
So i can ask something like, for the virtual domain X, is there any
association to external_domain entries.

query= SELECT [OK OR REJECT GOES
HERE] FROM domain_external_domain_association  AS deda
JOIN domain as d ON deda.domain_id = d.id
JOIN external_domain as ed ON deda.external_domain_id = ed.id WHERE
d.name = 'HERE
MY VDOMAIN' AND deda.receive = 1 AND ed.name = '%d'

d.name => should be recipient domain.
ed.name => is the sender domain, which works fine with %d, as I have
another check before with a similar query.

The problem is, I want to use in a check_sender_access information about
the recipient (for the joins in the query), which i think does not work.

[OK OR REJECT GOES HERE] , it is just a place holder for this e-mail :)

On Mon, Oct 8, 2018 at 3:55 AM Phil Stracchino  wrote:

> On 10/7/18 7:45 PM, Manuel Mely wrote:
> > Hi there,
> >
> > I'm designing a mail system with virtual domains and have the following
> > requirement:
> >
> > A virtual domain is able to send/receive mails to/from the Internet or
> > to/from custom "external domains".
> >
> > For that i'm using a MySQL table called
> > "domain_external_domain_association"  which connects my virtual domains
> > table and another external_domain table.
> >
> > Somewhere in my set of smtpd_restrictions_classes there is one class
> > that uses a check_sender_access where i need to check if the sender
> > domain (external domain) is in this "domain_external_domain_association"
> > when the recipient domain is X (my virtual domain)
> >
> > So the query looks like this:
> >
> > query= SELECT [OK OR REJECT GOES
> HERE] FROM domain_external_domain_association  AS deda
> > JOIN domain as d ON deda.domain_id = d.id
> > JOIN external_domain as ed ON deda.external_domain_id = ed.id
> > WHERE d.name = 'HERE MY VDOMAIN' AND deda.receive = 1 AND ed.name = '%d'
> >
> > Also, the sql query explains the problem by itself :)
>
>
> Actually, no, it doesn't, entirely.  That isn't very clear at all.
>
> What do the tables look like?
> Is that '%d' a formatting placeholder intended to be replaced before the
> query is evaluated, or are you trying to match ed.name against a string
> containing a wildcard?  (If so, you need to be using ed.name LIKE '%d',
> not ed.name = '%d'.)
> Is ed.name an integer or s string?  If it's a string, you probably want
> %s there, not %d.  %d is the formatting code for an integer.
> And what do you mean by [OK OR REJECT GOES HERE]?  Are you trying to
> SELECT a column, a string value, a string literal...?
>
>
> > I think this is not possible to do, at least in the way i want to do it,
> > because i'm trying to use in the query some information that the
> > check_sender_access is not aware of.
>
> Since you haven't provided enough information to make sense of your
> query, it's rather difficult to tell that.
>
>
>
> --
>   Phil Stracchino
>   Babylon Communications
>   ph...@caerllewys.net
>   p...@co.ordinate.org
>   Landline: +1.603.293.8485
>   Mobile:   +1.603.998.6958
>