On 5/1/2014 8:15 PM, Alex wrote:
...
> These are both corporate 10mbs dedicated links and I don't think latency
> and/or bandwidth is a problem.
The problem, if network related, will be UDP packet loss somewhere in
the end-to-end path, not b/w or latency on the CPE link into the
provider's net.
>
Hi,
On Thu, May 1, 2014 at 5:38 PM, Wietse Venema wrote:
> Alex:
> > I'm using postfix-2.10.3 with fedora20 and have configured postscreen
> with
> > spamhaus, barracuda, and a few other DNSBLs. I'm however occasionally
> > receiving the following timeout message:
> >
> > May 1 17:15:01 mail01
Alex:
> I'm using postfix-2.10.3 with fedora20 and have configured postscreen with
> spamhaus, barracuda, and a few other DNSBLs. I'm however occasionally
> receiving the following timeout message:
>
> May 1 17:15:01 mail01 postfix/postscreen[4429]: warning: dnsblog reply
> timeout 10s for swl.sp
Hi,
I'm using postfix-2.10.3 with fedora20 and have configured postscreen with
spamhaus, barracuda, and a few other DNSBLs. I'm however occasionally
receiving the following timeout message:
May 1 17:15:01 mail01 postfix/postscreen[4429]: warning: dnsblog reply
timeout 10s for swl.spamhaus.org
T
* Curtis Maurand :
> Hello,
>
> I think I've missed something dumb, but I have SASL working on my
> postfix/dbmail setup using imap authentication to the dbmail imap
> server. However, if the client connects on port 587, smtp
> authentication fails. Thunderbird seems to understand the key
> (com
Am 01.05.2014 20:44, schrieb Curtis Maurand:
> I think I've missed something dumb, but I have SASL working on my
> postfix/dbmail setup using imap authentication to
> the dbmail imap server. However, if the client connects on port 587, smtp
> authentication fails. Thunderbird seems
> to unders
Hello,
I think I've missed something dumb, but I have SASL working on my
postfix/dbmail setup using imap authentication to the dbmail imap
server. However, if the client connects on port 587, smtp
authentication fails. Thunderbird seems to understand the key
(complains that it's not signed
Noel Jones:
> On 5/1/2014 10:57 AM, Marcus wrote:
>> Noel Jones:
>>> Or maybe a PCRE map that replies to both "*" and not-local domains,
>>> leaving only the local domains for the slow map.
>>
>> Can PCRE reply be non-static or pseudo-random (if you will)?
>
> No. But it can respond very quickly to
please keep it on list
Am 01.05.2014 18:19, schrieb Marcus:
>> li...@rhsoft.net wrote:
>>> Marcus:
Noel Jones:
Or maybe a PCRE map that replies to both "*" and not-local domains,
leaving only the local domains for the slow map.
>>>
>>> Can PCRE reply be non-static or pseudo-random (
On Thu, May 01, 2014 at 11:20:00AM -0400, post...@nisny.com wrote:
> My active queue keeps growing over the past 90 minutes (1410 messages at
> this point). qmgr is not throwing any warnings, errors, panics, etc.
> qshape reports domains affected as local, so appear to be incoming or
> local ema
On 5/1/2014 10:57 AM, Marcus wrote:
> Noel Jones:
>> Or maybe a PCRE map that replies to both "*" and not-local domains,
>> leaving only the local domains for the slow map.
>
> Can PCRE reply be non-static or pseudo-random (if you will)?
No. But it can respond very quickly to a list (or a !not li
My active queue keeps growing over the past 90 minutes (1410 messages at
this point). qmgr is not throwing any warnings, errors, panics, etc.
qshape reports domains affected as local, so appear to be incoming or
local emails.
Reviewing the logs it appears that emails come into postfix and there
Am 01.05.2014 17:57, schrieb Marcus:
> Noel Jones:
>> Or maybe a PCRE map that replies to both "*" and not-local domains,
>> leaving only the local domains for the slow map.
>
> Can PCRE reply be non-static or pseudo-random (if you will)?
> I'm after something that works as following...
> Sometim
Noel Jones:
> Or maybe a PCRE map that replies to both "*" and not-local domains,
> leaving only the local domains for the slow map.
Can PCRE reply be non-static or pseudo-random (if you will)?
I'm after something that works as following...
Sometimes 'example.com' is sent down 'foo' and other time
Marcus:
> Wietse:
> > AS DOCUMENTED you can query transport_maps with the RECIPIENT ADDRESS.
>
> I surely can, but the same setting will also query "*" and sender addresses.
Don't be silly. Each trivial-rewrite process does one "*" query
and remembers the result until it terminates.
Wiet
On 5/1/2014 10:21 AM, Marcus wrote:
> Wietse:
>> AS DOCUMENTED you can query transport_maps with the RECIPIENT ADDRESS.
>
> I surely can, but the same setting will also query several times "*"
> and sender addresses
> As oposed to query ONLY recipient address ONCE.
>
If you can't speed up the s
Am 01.05.2014 17:21, schrieb Marcus:
> Wietse:
>> AS DOCUMENTED you can query transport_maps with the RECIPIENT ADDRESS.
>
> I surely can, but the same setting will also query several times "*"
> and sender addresses
> As oposed to query ONLY recipient address ONCE
where do you see a benefit in
Wietse:
> AS DOCUMENTED you can query transport_maps with the RECIPIENT ADDRESS.
I surely can, but the same setting will also query several times "*"
and sender addresses
As oposed to query ONLY recipient address ONCE.
Marcus:
> >> I'm after something that works as follows
> >> # sometimes 'example.com' is sent down 'foo' and other times it's
> >> # sent down 'bar'
> >> example.comfoo:
> >> example.combar:
> >
> > Looks like the proposed randmap that was discussed a week or so ago.
>
> Or maybe `recipien
> Wietse:
>> Marcus:
>>> Wietse:
>>> You need to use a more efficient implementation. Why do you need a
>>> UNIX-domain server in the first place?
>>
>> Because that's the only way I could think of that would work given that
>> the solution must work with pseudo-random transport.
>>
>> I'm after so
Victor,
>>Understand and memorize this simple formula:
>>
>> Throughput = Concurrency / Latency
>If Latency = 20, Concurrency=2.8s, Throughput=7.14286/second, which is equal
>to 12,857/30minutes. Is this a threshold? If real throughput is approximately
>greater than this number, delays >wi
Am 01.05.2014 15:47, schrieb Wietse Venema:
> Marcus:
>>> You need to use a more efficient implementation. Why do you need a
>>> UNIX-domain server in the first place?
>>
>> Because that's the only way I could think of that would work given that
>> the solution must work with pseudo-random transpo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/1/2014 8:13 AM, James Lay wrote:
> Hey all,
>
> Trying to figure out why the below made it through
>
> May 1 06:57:14 gateway postfix/smtpd[15631]: warning:
> hostname irc.madboxes.cc does not resolve to address
> 67.51.218.144 May 1 06:57:14
Marcus:
> > You need to use a more efficient implementation. Why do you need a
> > UNIX-domain server in the first place?
>
> Because that's the only way I could think of that would work given that
> the solution must work with pseudo-random transport.
>
> I'm after something that works as follow
Wietse:
>> Marcus:
>> So I tried transport_maps. And it works, but ...
> [...]
> You need to use a more efficient implementation. Why do you need a
> UNIX-domain server in the first place?
Because that's the only way I could think of that would work given that
the solution must work with pseudo-r
Am 01.05.2014 15:13, schrieb James Lay:
> May 1 06:57:14 gateway postfix/smtpd[15631]: connect from
> unknown[67.51.218.144]
that is pretty clear a DNS issue
most likely you have your smtpd chrooted
yes i understand you want to know why the message did not
get filtered out but if basics like
Hey all,
Trying to figure out why the below made it through
May 1 06:57:14 gateway postfix/smtpd[15631]: warning: hostname
irc.madboxes.cc does not resolve to address 67.51.218.144
May 1 06:57:14 gateway postfix/smtpd[15631]: connect from
unknown[67.51.218.144]
May 1 06:57:15 gateway postfix/s
Marcus:
> Based on the recipient, send that message down a custom transport (defined in
> master.cf) and this should be applied to outbound messages only.
> By outbound messages I mean messages sent to domains other than $mydomain.
Use transport_maps.
> So I tried transport_maps. And it works, bu
TL,DR: Looking for a recipient dependent option, similar to
sender_dependent_default_transport_maps.
I've got a working solution sending messages through 2 distinct custom
transports. This solution solved a problem I had which was *not* recipient
dependent.
I implemented a unix socket that respon
29 matches
Mail list logo
