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
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
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
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
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
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
-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
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
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
> 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
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:
> 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.
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
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
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
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
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
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
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
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
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 (
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
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
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
* 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
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
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,
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
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.
>
29 matches
Mail list logo
