RE: smtpd wish list: ability to control error messages

[Peter Fraser]

I just went through https://www.opensmtpd.org/

there is nothing I can find linked to the page 
https://www.opensmtpd.org/report.html
which I found knowing it was there from your message.

The only comment directly linked to https://www.opensmtpd.org/
I could find about bugs is in https://www.opensmtpd.org/list.html
which refers to emailing b...@opensmtpd.org

I don’t mind following instructions but it would be nice to be able to find the 
instructions.

As for the ability to control error messages. I did look, I also relooked after 
I install the 2.9.5
and I looked in https://github.com/OpenSMTPD/OpenSMTPD/labels/feature%20request
and found nothing similar.






From: Gilles Chehade [mailto:gil...@poolp.org]
Sent: Thursday, May 26, 2016 2:37 PM
To: Peter Fraser 
Cc: misc 
Subject: Re: smtpd wish list: ability to control error messages


This is not how feature requests work.

First you want to make sure the feature does not exist. Hint: you didn't do 
that.

Then you open a ticket on our bug tracker and tag it with "feature request".

Gilles

Re: smtpd wish list: filer-regex

[Gilles Chehade]

See reply to previous mail. 

Re: smtpd wish list: ability to control error messages

[Gilles Chehade]

This is not how feature requests work.
First you want to make sure the feature does not exist. Hint: you didn't do that.
Then you open a ticket on our bug tracker and tag it with "feature request". 
Gilles 

smtpd wish list: filer-regex

[Peter Fraser]

with send mail I used milter-regex which had the ability to do 'and' test which 
I miss in filter-regex

for example (checking if a mail message actually came from bank it said it did.

reject "Looks like you are phishing"
connect /rbc\.com$/ni /./ and envfrom /@rbc\.com/i

I also used it when someone working here a stalker

reject "cannot accept email from you"
envfrom /stalker@gmail\.com/i  & envrcpt /stal...@thinkage.ca/



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

Re: filter-spamassassin fails under heavy load (may 23 extras snapshot)

[Joerg Jung]

On Thu, May 26, 2016 at 01:51:20PM -0400, Andrew Ruscica wrote:
> On Thu, May 26, 2016 at 10:50 AM, Joerg Jung  wrote:
> 
> >
> >
> > Am 26.05.2016 um 14:11 schrieb Andrew Ruscica :
> >
> > On Wed, May 25, 2016 at 4:39 PM, Joerg Jung  wrote:
> >
> >> Can you provide smtpctl show stats and fstat -u _smtpd output?
> >>
> >
> > If the event happens again, I will provide output before restarting the
> > daemon. Here it is now.. had to restart it a short while ago;
> >
> >
> > # smtpctl show stats
> > control.session=1
> > mta.connector=1
> > mta.domain=1
> > mta.envelope=0
> > mta.host=1
> > mta.relay=1
> > mta.route=1
> > mta.session=1
> > mta.source=1
> > mta.task=0
> > mta.task.running=0
> > queue.evpcache.load.hit=680
> > queue.evpcache.size=20
> > scheduler.delivery.ok=340
> > scheduler.envelope=0
> > scheduler.envelope.incoming=20
> > scheduler.envelope.inflight=0
> > scheduler.ramqueue.envelope=20
> > scheduler.ramqueue.message=9
> > scheduler.ramqueue.update=9
> > smtp.session=21
> > smtp.session.inet4=278
> >
> >
> > Out of 278 total sessions in 11min
> > you have 21 current active ones, guess most
> > of them are hanging...
> >
> > This looks like #698 to me.
> >
> > Have you applied the smtpd errata?
> >
> >
> Hmm,
> 
> # smtpd -h
> version: OpenSMTPD 5.9.2
> also present before installing 5.9.2 from the tarball:
> 
> # pkg_info | grep smtpd
> binpatch59-amd64-smtpd-1.0 Binary Patch for 006_smtpd
> 
> 
> If I don't limit states at pf (currently at 30), my maximum connections
> always reach the 500 (493) limit, and all relaying stalls.

I guess, you also have increased limits in login.conf?

> I know filter-spamassassin is expensive, and I've pre-forked (now 30)
> children (currently the box has 8 cores and 8GB RAM, both apparently
> underutilized), but the only way I can ensure the system doesn't get
> bottlenecked is to throttle the connections at pf.

What do you see from spamassassin spamd in the logs (maybe enable debug),
are the sessions finished by spamd? Have you tried the limit option of
filter-spamassassin?

Your fstat output also shows connections to clamav, so maybe not
spamassassin the culprit here?
 
> Also, limits are present:
> 
> limit session max-mails 40
> limit scheduler max-inflight 30
> but it doesn't appear to change the behaviour - the queue is never full,
> just a ton of connections..

I assume hanging and dead, but hard to debug without logs, so:

Please add your exact versions as mentioned above, full config
(including spamassassin spamd and clamd tweaks), logs from
smtpd -dv -Tall and fstat as well as smtpctl show stats output to #698,
thanks!

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

smtpd wish list: ability to control error messages

[Peter Fraser]

In sendmail's virtualusertable you could use the following 

bob.sm...@charity.org   error:5.1.1:553 " Bob Smith has retired if you wish to 
contact Bob personally please mail bob.sm...@gmail.com, otherwise please mail 
donati...@charity.org"

or

@thinkage.on.ca error:5.1.1:553 " Please use thinkage.ca not thinkage.on.ca"

I found this a useful feature when people move or organizations changed their 
names.

It would be nice if smtpd had a similar functionality.

If it is added a I suggest that it should be added option to the reject command 
so you can

reject from any for domain thinkage.on.ca error " Please use thinkage.ca not 
thinkage.on.ca"

or 

reject from any for any error 

where  is a table mapping rcpt email addresses to an error message, 
and would only reject if it found a match in the 

The sendmail's virtualusertable allowed you to specify the error number, but I 
don't know when you would want to change it from invalid recipient

Note: also such a mapping would also make sense on the receive side in that 
case the from address matched,  for example:

reject from any error  to any



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

Re: filter-spamassassin fails under heavy load (may 23 extras snapshot)

[Andrew Ruscica]

On Thu, May 26, 2016 at 10:50 AM, Joerg Jung  wrote:

>
>
> Am 26.05.2016 um 14:11 schrieb Andrew Ruscica :
>
> On Wed, May 25, 2016 at 4:39 PM, Joerg Jung  wrote:
>
>> Can you provide smtpctl show stats and fstat -u _smtpd output?
>>
>
> If the event happens again, I will provide output before restarting the
> daemon. Here it is now.. had to restart it a short while ago;
>
>
> # smtpctl show stats
> control.session=1
> mta.connector=1
> mta.domain=1
> mta.envelope=0
> mta.host=1
> mta.relay=1
> mta.route=1
> mta.session=1
> mta.source=1
> mta.task=0
> mta.task.running=0
> queue.evpcache.load.hit=680
> queue.evpcache.size=20
> scheduler.delivery.ok=340
> scheduler.envelope=0
> scheduler.envelope.incoming=20
> scheduler.envelope.inflight=0
> scheduler.ramqueue.envelope=20
> scheduler.ramqueue.message=9
> scheduler.ramqueue.update=9
> smtp.session=21
> smtp.session.inet4=278
>
>
> Out of 278 total sessions in 11min
> you have 21 current active ones, guess most
> of them are hanging...
>
> This looks like #698 to me.
>
> Have you applied the smtpd errata?
>
>
Hmm,

# smtpd -h
version: OpenSMTPD 5.9.2
also present before installing 5.9.2 from the tarball:

# pkg_info | grep smtpd
binpatch59-amd64-smtpd-1.0 Binary Patch for 006_smtpd


If I don't limit states at pf (currently at 30), my maximum connections
always reach the 500 (493) limit, and all relaying stalls.
I know filter-spamassassin is expensive, and I've pre-forked (now 30)
children (currently the box has 8 cores and 8GB RAM, both apparently
underutilized), but the only way I can ensure the system doesn't get
bottlenecked is to throttle the connections at pf.


Also, limits are present:

limit session max-mails 40
limit scheduler max-inflight 30
but it doesn't appear to change the behaviour - the queue is never full,
just a ton of connections..

Re: smptd stops listing to external interfaces.

[Joerg Jung]

Have you guys both applied the 5.9 smtpd errata?

There is a known FD leak bug with filters, which 
leads to dying smtpd once FD limit is reached, see 
#698.

That is why I asked for fstat/stats output to verify
if your current smtp.session have increased
and hit the openfiles limit.

Would be nice if you can verify if you hit #698 or 
if this is a different issue. In case of the latter, please
open another issue with full config and 
smtpd -dv -Tall output.


> Am 26.05.2016 um 14:23 schrieb Andrew Ruscica :
> 
>> On Wed, May 25, 2016 at 2:21 PM, Peter Fraser  wrote:
>> whoops I mistyped OpenBSD 5.9
>> 
>> -Original Message-
>> From: Peter Fraser [mailto:p...@thinkage.ca]
>> Sent: Wednesday, May 25, 2016 2:16 PM
>> To: misc@opensmtpd.org
>> Subject: smptd stops listing to external interfaces.
>> 
>> OpenBSD 5.8 i386
>> 
>> smtpd with smtpd.conf as shown below
>> will run quite happy for several days at times, or just several hours, the 
>> it seems to stop listening on the external interfaces. Message can still be 
>> sent using the local interfaces. Even if the daemon is left for several 
>> hours it does not  fix it self.
>> 
>> Stopping the daemon and restarting clears the problem.
>> 
>> Restarting the Microsoft exchange servers that the mail is being relayed to 
>> seems to increase the likelihood that the problem will occur.
>> 
>> Any hint on how to track down what is causing the problem and how to fix it?
> 
>  
> 
> I can confirm similar or identical behaviour - occurred sometime overnight 
> during light load. Once I restarted the daemon it started accepting 
> connections again.  I can provide smtpd.conf if desired.  OpenBSD 5.9/amd64 
> and the May 23 extras snapshot.  This configuration is my first full day of 
> production so I don't have a comparison against older snapshots.  
> 
> I'm going through the log to determine when it started.  What's throwing me 
> off is that throughout the 'down' period there are still a trickle of 
> connections coming in. So I wouldn't rule out my pf configuration which has a 
> max rule to limit the number of incoming connections.  Thinking of this now, 
> it would have been smarter to check pf states before restarting the daemon.
> 
> The difference from Peter's design is that I have only an internal interface 
> and smtp is NAT'd in from an external firewall- however the firewall 
> configuration hasn't changed from the previous gateway which was OpenBSD 5.3 
> + postfix which remained mostly unchanged for three years.
> 
> 

Re: filter-spamassassin fails under heavy load (may 23 extras snapshot)

[Joerg Jung]

> Am 26.05.2016 um 14:11 schrieb Andrew Ruscica :
> 
>> On Wed, May 25, 2016 at 4:39 PM, Joerg Jung  wrote:
>> Can you provide smtpctl show stats and fstat -u _smtpd output?
> 
> If the event happens again, I will provide output before restarting the 
> daemon. Here it is now.. had to restart it a short while ago;
> 
> 
> # smtpctl show stats
> control.session=1
> mta.connector=1
> mta.domain=1
> mta.envelope=0
> mta.host=1
> mta.relay=1
> mta.route=1
> mta.session=1
> mta.source=1
> mta.task=0
> mta.task.running=0
> queue.evpcache.load.hit=680
> queue.evpcache.size=20
> scheduler.delivery.ok=340
> scheduler.envelope=0
> scheduler.envelope.incoming=20
> scheduler.envelope.inflight=0
> scheduler.ramqueue.envelope=20
> scheduler.ramqueue.message=9
> scheduler.ramqueue.update=9
> smtp.session=21
> smtp.session.inet4=278

Out of 278 total sessions in 11min
you have 21 current active ones, guess most
of them are hanging...

This looks like #698 to me.

Have you applied the smtpd errata?

> smtp.tls=14
> uptime=684
> uptime.human=11m24s
> 
> 
> fstat output at the bottom of this email.
> 
>  
>> 
>> 
>> You can try the latest -extras snapshot and especially the limit option.
> 
> 
> I'm on the may 23 snapshot and will look at the limit option now.
> 
> Thanks,
> Andrew
> 
> 
> 
> 
> # fstat -u _smtpd
> 
> USER CMD  PID   FD MOUNTINUM MODE   R/WSZ|DV
> _smtpd   filter-spamassas 31978   wd /var  1429120 drwxr-xr-x   r  512
> _smtpd   filter-spamassas 31978 root /var  1429120 drwxr-xr-x   r  512
> _smtpd   filter-spamassas 319780* unix stream 0x81575200 <-> 
> 0x80a7ac80
> _smtpd   filter-spamassas 319781 /   27142 crw-rw-rw-  rw null
> _smtpd   filter-spamassas 319782 /   27142 crw-rw-rw-  rw null
> _smtpd   filter-spamassas 319783 kqueue 0xff0200e1c3c0 0 state:
> _smtpd   filter-spamassas 319784* internet stream tcp 0x80ceab40 
> 127.0.0.1:33104 --> 127.0.0.1:783
> _smtpd   filter-spamassas 319785* unix stream 0x814b7b00 <-> 
> 0x8149bc00
> _smtpd   filter-spamassas 319787* unix stream 0x80af6980 <-> 
> 0x80f6f800
> _smtpd   filter-spamassas 319788* unix stream 0x80bae000 <-> 
> 0x814fa000
> _smtpd   filter-spamassas 319789* unix stream 0x80ec7480 <-> 
> 0x814ae000
> _smtpd   filter-spamassas 31978   10* unix stream 0x80f92b80 <-> 
> 0x80ecd400
> _smtpd   filter-spamassas 31978   11* unix stream 0x80be8100 <-> 
> 0x80bfdf80
> _smtpd   filter-spamassas 31978   12* unix stream 0x8155ff80 <-> 
> 0x81461100
> _smtpd   filter-spamassas 31978   13* internet stream tcp 0x80fdedf0 
> 127.0.0.1:27127 --> 127.0.0.1:783
> _smtpd   filter-spamassas 31978   14* internet stream tcp 0x81605188 
> 127.0.0.1:25541 --> 127.0.0.1:783
> _smtpd   filter-spamassas 31978   15* unix stream 0x8140c180 <-> 
> 0x81489f80
> _smtpd   filter-spamassas 31978   16* internet stream tcp 0x80fde990 
> 127.0.0.1:39347 --> 127.0.0.1:783
> _smtpd   filter-spamassas 31978   18* unix stream 0x80aec500 <-> 
> 0x80a9e300
> _smtpd   filter-regex  3752   wd /var  1429120 drwxr-xr-x   r  512
> _smtpd   filter-regex  3752 root /var  1429120 drwxr-xr-x   r  512
> _smtpd   filter-regex  37520* unix stream 0x80ce2380 <-> 
> 0x80be9580
> _smtpd   filter-regex  37521 /   27142 crw-rw-rw-  rw null
> _smtpd   filter-regex  37522 /   27142 crw-rw-rw-  rw null
> _smtpd   filter-regex  37523 kqueue 0xff0200e1cb40 4 state:
> _smtpd   filter-regex  37526* unix stream 0x80bfdf80 <-> 
> 0x80be8100
> _smtpd   filter-regex  37527* unix stream 0x80c75d80 <-> 
> 0x80c1a380
> _smtpd   filter-regex  37528* unix stream 0x81461100 <-> 
> 0x8155ff80
> _smtpd   filter-regex  37529* unix stream 0x814c7e00 <-> 
> 0x8160fe00
> _smtpd   filter-regex  3752   10* unix stream 0x81489f80 <-> 
> 0x8140c180
> _smtpd   filter-regex  3752   11* unix stream 0x814cc500 <-> 
> 0x814ad200
> _smtpd   filter-regex  3752   12* unix stream 0x813c8700 <-> 
> 0x80f48c00
> _smtpd   filter-regex  3752   13* unix stream 0x814fa000 <-> 
> 0x80bae000
> _smtpd   filter-pause  3600   wd /var  1429120 drwxr-xr-x   r  512
> _smtpd   filter-pause  3600 root /var  1429120 drwxr-xr-x   r  512
> _smtpd   filter-pause  36000* unix stream 0x813c0d00 <-> 
> 0x80c75900
> _smtpd   filter-pause  36001 /   27142 crw-rw-rw-  rw null
> _smtpd   filter-pause  36002 /   27142 crw-rw-rw-  rw null
> _smtpd   filter-pause  36003 kqueue 0xff0200e1cc80 0 state: W
> _smtpd   filter-dnsbl 23238   wd /var  

Re: FW: smptd stops listing to external interfaces.

[Andrew Ruscica]

On Wed, May 25, 2016 at 2:21 PM, Peter Fraser  wrote:

> whoops I mistyped OpenBSD 5.9
>
> -Original Message-
> From: Peter Fraser [mailto:p...@thinkage.ca]
> Sent: Wednesday, May 25, 2016 2:16 PM
> To: misc@opensmtpd.org
> Subject: smptd stops listing to external interfaces.
>
> OpenBSD 5.8 i386
>
> smtpd with smtpd.conf as shown below
> will run quite happy for several days at times, or just several hours, the
> it seems to stop listening on the external interfaces. Message can still be
> sent using the local interfaces. Even if the daemon is left for several
> hours it does not  fix it self.
>
> Stopping the daemon and restarting clears the problem.
>
> Restarting the Microsoft exchange servers that the mail is being relayed
> to seems to increase the likelihood that the problem will occur.
>
> Any hint on how to track down what is causing the problem and how to fix
> it?
>



I can confirm similar or identical behaviour - occurred sometime overnight
during light load. Once I restarted the daemon it started accepting
connections again.  I can provide smtpd.conf if desired.  OpenBSD 5.9/amd64
and the May 23 extras snapshot.  This configuration is my first full day of
production so I don't have a comparison against older snapshots.

I'm going through the log to determine when it started.  What's throwing me
off is that throughout the 'down' period there are still a trickle of
connections coming in. So I wouldn't rule out my pf configuration which has
a max rule to limit the number of incoming connections.  Thinking of this
now, it would have been smarter to check pf states before restarting the
daemon.

The difference from Peter's design is that I have only an internal
interface and smtp is NAT'd in from an external firewall- however the
firewall configuration hasn't changed from the previous gateway which was
OpenBSD 5.3 + postfix which remained mostly unchanged for three years.

Re: filter-spamassassin fails under heavy load (may 23 extras snapshot)

[Andrew Ruscica]

On Wed, May 25, 2016 at 4:39 PM, Joerg Jung  wrote:

> Can you provide smtpctl show stats and fstat -u _smtpd output?
>

If the event happens again, I will provide output before restarting the
daemon. Here it is now.. had to restart it a short while ago;


# smtpctl show stats
control.session=1
mta.connector=1
mta.domain=1
mta.envelope=0
mta.host=1
mta.relay=1
mta.route=1
mta.session=1
mta.source=1
mta.task=0
mta.task.running=0
queue.evpcache.load.hit=680
queue.evpcache.size=20
scheduler.delivery.ok=340
scheduler.envelope=0
scheduler.envelope.incoming=20
scheduler.envelope.inflight=0
scheduler.ramqueue.envelope=20
scheduler.ramqueue.message=9
scheduler.ramqueue.update=9
smtp.session=21
smtp.session.inet4=278
smtp.tls=14
uptime=684
uptime.human=11m24s


fstat output at the bottom of this email.



>
>
> You can try the latest -extras snapshot and especially the limit option.
>
>

I'm on the may 23 snapshot and will look at the limit option now.

Thanks,
Andrew




# fstat -u _smtpd
USER CMD  PID   FD MOUNTINUM MODE   R/WSZ|DV
_smtpd   filter-spamassas 31978   wd /var  1429120 drwxr-xr-x   r
512
_smtpd   filter-spamassas 31978 root /var  1429120 drwxr-xr-x   r
512
_smtpd   filter-spamassas 319780* unix stream 0x81575200 <->
0x80a7ac80
_smtpd   filter-spamassas 319781 /   27142 crw-rw-rw-  rw
 null
_smtpd   filter-spamassas 319782 /   27142 crw-rw-rw-  rw
 null
_smtpd   filter-spamassas 319783 kqueue 0xff0200e1c3c0 0 state:
_smtpd   filter-spamassas 319784* internet stream tcp
0x80ceab40 127.0.0.1:33104 --> 127.0.0.1:783
_smtpd   filter-spamassas 319785* unix stream 0x814b7b00 <->
0x8149bc00
_smtpd   filter-spamassas 319787* unix stream 0x80af6980 <->
0x80f6f800
_smtpd   filter-spamassas 319788* unix stream 0x80bae000 <->
0x814fa000
_smtpd   filter-spamassas 319789* unix stream 0x80ec7480 <->
0x814ae000
_smtpd   filter-spamassas 31978   10* unix stream 0x80f92b80 <->
0x80ecd400
_smtpd   filter-spamassas 31978   11* unix stream 0x80be8100 <->
0x80bfdf80
_smtpd   filter-spamassas 31978   12* unix stream 0x8155ff80 <->
0x81461100
_smtpd   filter-spamassas 31978   13* internet stream tcp
0x80fdedf0 127.0.0.1:27127 --> 127.0.0.1:783
_smtpd   filter-spamassas 31978   14* internet stream tcp
0x81605188 127.0.0.1:25541 --> 127.0.0.1:783
_smtpd   filter-spamassas 31978   15* unix stream 0x8140c180 <->
0x81489f80
_smtpd   filter-spamassas 31978   16* internet stream tcp
0x80fde990 127.0.0.1:39347 --> 127.0.0.1:783
_smtpd   filter-spamassas 31978   18* unix stream 0x80aec500 <->
0x80a9e300
_smtpd   filter-regex  3752   wd /var  1429120 drwxr-xr-x   r  512
_smtpd   filter-regex  3752 root /var  1429120 drwxr-xr-x   r  512
_smtpd   filter-regex  37520* unix stream 0x80ce2380 <->
0x80be9580
_smtpd   filter-regex  37521 /   27142 crw-rw-rw-  rw null
_smtpd   filter-regex  37522 /   27142 crw-rw-rw-  rw null
_smtpd   filter-regex  37523 kqueue 0xff0200e1cb40 4 state:
_smtpd   filter-regex  37526* unix stream 0x80bfdf80 <->
0x80be8100
_smtpd   filter-regex  37527* unix stream 0x80c75d80 <->
0x80c1a380
_smtpd   filter-regex  37528* unix stream 0x81461100 <->
0x8155ff80
_smtpd   filter-regex  37529* unix stream 0x814c7e00 <->
0x8160fe00
_smtpd   filter-regex  3752   10* unix stream 0x81489f80 <->
0x8140c180
_smtpd   filter-regex  3752   11* unix stream 0x814cc500 <->
0x814ad200
_smtpd   filter-regex  3752   12* unix stream 0x813c8700 <->
0x80f48c00
_smtpd   filter-regex  3752   13* unix stream 0x814fa000 <->
0x80bae000
_smtpd   filter-pause  3600   wd /var  1429120 drwxr-xr-x   r  512
_smtpd   filter-pause  3600 root /var  1429120 drwxr-xr-x   r  512
_smtpd   filter-pause  36000* unix stream 0x813c0d00 <->
0x80c75900
_smtpd   filter-pause  36001 /   27142 crw-rw-rw-  rw null
_smtpd   filter-pause  36002 /   27142 crw-rw-rw-  rw null
_smtpd   filter-pause  36003 kqueue 0xff0200e1cc80 0 state: W
_smtpd   filter-dnsbl 23238   wd /var  1429120 drwxr-xr-x   r  512
_smtpd   filter-dnsbl 23238 root /var  1429120 drwxr-xr-x   r  512
_smtpd   filter-dnsbl 232380* unix stream 0x813c4000 <->
0x80f68e00
_smtpd   filter-dnsbl 232381 /   27142 crw-rw-rw-  rw null
_smtpd   filter-dnsbl 232382 /   27142 crw-rw-rw-  rw null
_smtpd   filter-dnsbl 232383 kqueue 0xff0200e1ca00 0 state: W
_smtpd   filter-dnsbl 232384* unix stream 0x80f31580 <->
0x8052e500
_smtpd