On 2013-08-06 10:29 AM, wie...@porcupine.org (Wietse Venema)
wrote:
Did the provier actually promise that they were going to send no
more than 100 VRFY requests per session?
All I recall was an incorrect claim that (soft error limit > hard
error limit) would cause Postfix to accept unlimited nu
Charles Marcus:
> What I was expecting was that the 'too many errors' issue would be
> resolved by these changes, but alas, I had one about an hour after
> making the change (and to be sure I did fully restart postfix):
>
> > 2013-08-06T07:33:25-04:00 myhost postfix-25/smtpd[12873]: too many err
On 2013-08-05 9:21 AM, Noel Jones wrote:
Set those three limits to 100 or higher. Those controls are
intended to prevent random clients from wasting your time. Since
you don't allow connections from random clients, it's safe to
increase them.
# main.cf
smtpd_hard_error_limit = 100
smtpd_soft_
On 2013-08-05 11:33 PM, Stan Hoeppner wrote:
I'm sure you've already covered this Charles but just in case you
haven't I'll mention it anyway.
No matter what you do here with this outsourced service, I'd suggest you
document all Postfix config changes you're making, or save a copy of
your main/
On 8/5/2013 9:09 AM, Charles Marcus wrote:
> On 2013-08-05 9:21 AM, Noel Jones wrote:
>> Set those three limits to 100 or higher. Those controls are
>> intended to prevent random clients from wasting your time. Since
>> you don't allow connections from random clients, it's safe to
>> increase th
Noel Jones:
> On 8/5/2013 10:30 AM, Charles Marcus wrote:
> > On 2013-08-05 10:53 AM, Noel Jones wrote:
> >> I don't suppose an open idle connection from an somewhat authorized
> >> client will bother anything, so just go with it.
> >
> > Ok - and by 'go with it', you mean just adjust the setting
On 8/5/2013 10:30 AM, Charles Marcus wrote:
> On 2013-08-05 10:53 AM, Noel Jones wrote:
>> I don't suppose an open idle connection from an somewhat authorized
>> client will bother anything, so just go with it.
>
> Ok - and by 'go with it', you mean just adjust the settings per your
> last email
On 2013-08-05 10:53 AM, Noel Jones wrote:
I don't suppose an open idle connection from an somewhat authorized
client will bother anything, so just go with it.
Ok - and by 'go with it', you mean just adjust the settings per your
last email and be done with it, right?
I asked Edgewave to esca
On 8/5/2013 9:09 AM, Charles Marcus wrote:
> On 2013-08-05 9:21 AM, Noel Jones wrote:
>> Set those three limits to 100 or higher. Those controls are
>> intended to prevent random clients from wasting your time. Since
>> you don't allow connections from random clients, it's safe to
>> increase th
On 2013-08-05 9:21 AM, Noel Jones wrote:
Set those three limits to 100 or higher. Those controls are
intended to prevent random clients from wasting your time. Since
you don't allow connections from random clients, it's safe to
increase them.
# main.cf
smtpd_hard_error_limit = 100
smtpd_soft_
On 8/5/2013 7:15 AM, Charles Marcus wrote:
> On 2013-08-04 7:30 PM, wie...@porcupine.org (Wietse Venema)
> wrote:
>> Charles Marcus:
We are set up for performance with VRFY probes and by modifying
your postfix config file so postfix will not nave a performance
issue by setting postf
On 08/05/2013 02:15 PM, Charles Marcus wrote:
> Also - I hate to ask (it isn't your job to do their job), but could you
> suggest off the top of your head what they *should* be doing? Would
> properly closing all VRFY probe connections really impact performance on
> their side that much - especiall
On 2013-08-04 7:30 PM, wie...@porcupine.org (Wietse Venema)
wrote:
Charles Marcus:
We are set up for performance with VRFY probes and by modifying
your postfix config file so postfix will not nave a performance
issue by setting postfix option smtpd_soft_error_limit to be larger
than smtpd_hard_
Charles Marcus:
> > We are set up for performance with VRFY probes and by modifying
> > your postfix config file so postfix will not nave a performance
> > issue by setting postfix option smtpd_soft_error_limit to be larger
> > than smtpd_hard_error_limit.
That is nonsense, as demonstrated below:
On Aug 4, 2013, at 21:08, Charles Marcus wrote:
> On 2013-07-31 1:44 PM, Charles Marcus wrote:
>> On 2013-07-31 1:23 PM, wie...@porcupine.org (Wietse Venema)
>> wrote:
>>> That *is*
>>> a problem. Postfix will slow down and eventually hang
>>> up when a client sends too many commands that cau
On 2013-07-31 1:44 PM, Charles Marcus wrote:
On 2013-07-31 1:23 PM, wie...@porcupine.org (Wietse Venema)
wrote:
That*is* a problem. Postfix will slow down and eventually hang
up when a client sends too many commands that cause an error
reply (as in VERY with a non-existent recipient).
To mak
On 2013-07-31 2:53 PM, wie...@porcupine.org (Wietse Venema)
wrote:
Charles Marcus:
When you say 'the verifieD MUST disconnect...', I'm assuming you
meant 'verifieR' - meaning, their server, the one connecting to mine
sending VRFY probes?
Yes. Even when the verifier sends only known recipient
Charles Marcus:
> On 2013-07-31 1:23 PM, wie...@porcupine.org (Wietse Venema)
> wrote:
> > That*is* a problem. Postfix will slow down and eventually hang
> > up when a client sends too many commands that cause an error
> > reply (as in VERY with a non-existent recipient).
> >
> > To make this ro
On 2013-07-31 1:23 PM, wie...@porcupine.org (Wietse Venema)
wrote:
That*is* a problem. Postfix will slow down and eventually hang
up when a client sends too many commands that cause an error
reply (as in VERY with a non-existent recipient).
To make this robust the verified MUST disconnect afte
DTNX Postmaster:
> >> 2013-07-31T10:48:39-04:00 myhost postfix-25/smtpd[17729]: lost connection
> >> after VRFY from smtp446.redcondor.net[208.80.204.46]
Not a real problem...
> > with occasional
> >
> >> 2013-07-31T10:46:28-04:00 myhost postfix-25/smtpd[17993]: too many errors
> >> after VRFY
On Jul 31, 2013, at 18:19, Charles Marcus wrote:
> We are testing a new outsourced anti-spam service (Edgewave/RedCondor). We
> are letting their systems check for valid recipients using the VRFY command,
> but their default verifier uses , instead of
> as the FROM address when verifying. Bec
Hi all,
We are testing a new outsourced anti-spam service (Edgewave/RedCondor).
We are letting their systems check for valid recipients using the VRFY
command, but their default verifier uses ,
instead of as the FROM address when verifying.
Because I employ anti-spoofing (anything from/to on
22 matches
Mail list logo
