Wietse wrote:
> In that case, arrange for whitelisting like ever legitimate sender does.
I do that for Gmail, Yahoo, Microsoft, AOL .. and it works, so much
so that we have never been graylisted by any of those folks despite
the tens of thousands emails we send daily.
But I can't afford do that f
On Thu, Mar 27, 2014 at 08:48:17PM +, MV wrote:
> > It is a program! Not a fixed mapping. It receives a sender address,
> > and replies (with a possibly cached per-sender) answer which is
> > computed on a mostly-round-robin basis.
>
> If that's not asking too much, could you please provide
MV:
> > Wietse:
> > What is the legitimate use case for this kind of policy evasion?
>
> Just to be clear, I'm not a spammer, if anything, I couldn't be more
> far from it.
> I'm in the business of (strictly subscription-only) "monitoring
> stuff". I mean, as soon as an event happens the subscribe
Viktor Dukhovni wrote:
> It is a program! Not a fixed mapping. It receives a sender address,
> and replies (with a possibly cached per-sender) answer which is
> computed on a mostly-round-robin basis.
If that's not asking too much, could you please provide me with a
practical example or point me
On Thu, Mar 27, 2014 at 07:44:46PM +, MV wrote:
> > sender dependent maps would actually largely ignore the sender,
>
> But how to I define the sender (map), if that's not asking too much,
> could you please provide me with an example file?
It is a program! Not a fixed mapping. It receives
Viktor Dukhovni:
> Of course you can. You're just not listening carefully. Your
I'm failing to grasp the concept and can't find any working examples online...
Finding this thread
http://thread.gmane.org/gmane.mail.postfix.user/203958 has helped a
bit..
> sender dependent maps would actually larg
> Wietse:
> What is the legitimate use case for this kind of policy evasion?
Just to be clear, I'm not a spammer, if anything, I couldn't be more
far from it.
I'm in the business of (strictly subscription-only) "monitoring
stuff". I mean, as soon as an event happens the subscribers who signed
up t
On Thu, Mar 27, 2014 at 06:23:39PM +, MV wrote:
> >Viktor Dukhovni wrote:
> > Furthermore, because "*" is cached, you really don't want to use
> > "*" at all for dynamic transport resolution.
> Thanks for your input RE the caching of the special pattern "*" results.
>
> > I answered your ques
MV:
> I don't want to use sender-based static "routes". I'm looking for
> a "random" or round-robin-ish split of smtp that provides consistent
> "helo .. hostname .. ip .. reverse-dns-lookup"
What is the legitimate use case for this kind of policy evasion?
Wietse
>Viktor Dukhovni wrote:
> Furthermore, because "*" is cached, you really don't want to use
> "*" at all for dynamic transport resolution.
Thanks for your input RE the caching of the special pattern "*" results.
> I answered your question upthread, use:
> sender_dependent_default_transport_maps
On Thu, Mar 27, 2014 at 04:50:25PM +, MV wrote:
> Now going a step further, how can I split the "*" (all non-local)
> between smtpX and smtpY (without running multiple postfix instances) ?
> Something like ...
>
> mydomain.ltd:
> .mydomain.ltd :
> * smtpX
> *
>Wietse:
>> MV:
>> As far as I can tell, in my case since I'm using sing tcp-base tables
>> some look ups are not performed and that's fine. But there are no
>> mentions to the change in the order which patterns are checked.
>> So am I wrong to expect to see the logs showing "get bar
>> foreign.tl
On Thu, Mar 27, 2014 at 12:04:34PM +, MV wrote:
> As far as I can tell, in my case since I'm using sing tcp-base tables
> some look ups are not performed and that's fine. But there are no
> mentions to the change in the order which patterns are checked.
> So am I wrong to expect to see the log
MV:
> As far as I can tell, in my case since I'm using sing tcp-base tables
> some look ups are not performed and that's fine. But there are no
> mentions to the change in the order which patterns are checked.
> So am I wrong to expect to see the logs showing "get bar
> foreign.tld" and "get foo
> Wietse Venema wrote:
> In other words, RTFM.
I'd love to say I haven't read the manual and thank you for pointing
it out to me, but my OCD is too damn high, so I always read manuals.
Unfortunately this time I can't quite get my head around it to figure
it out on my own how to correctly and sanel
MV:
> Also I've noticed that different queries are sent to the transport
> map. Looking at the logs I see that early on in the request the
> transport map is queried as follow
> get *
> get *
> get b...@foreign.tld
> get f...@mydomain.tld
>
> and I can't figure out what those two initial "get *" q
> Wietse wrote:
> By having the transport map reply "not found" for local destinations.
> Noel Jones wrote:
> ... Configure your TCP table ignore local addresses. In
> the context of a TCP table, the response should be something like
> 500 not found
So, am I right to assume that by replying to s
On Wed, Mar 26, 2014 at 03:58:16PM -0500, Noel Jones wrote:
> Don't use the smtp transport for local addresses.
To attempt to evade receiving system client controls by spreading
load over multiple local IPs use sender_dependent_default_transport_maps.
If all you want is round-robin of the IPs, w
On 3/26/2014 3:59 PM, MV wrote:
>> Wietse wrote:
>>> MV wrote:
>>> I'm trying to use multiple smtp IPs without having multiple postfix
>>> instances.
>>>
>>> So I tried to split smtp using transport_maps and that works ok for
>>> local mail destined to foreign destinations.
>>> But it breaks the d
MV:
> > Wietse:
> >> I'm trying to use multiple smtp IPs without having multiple postfix
> >> instances.
> >>
> >> So I tried to split smtp using transport_maps and that works ok for
> >> local mail destined to foreign destinations.
> >> But it breaks the delivery of foreign mail destined to local
> Noel Jones wrote:
> Don't use the smtp transport for local addresses.
And how would I do that? I mean how can I have custom smtp for REMOTE
deliveries and not breaking the LOCAL deliveries,
Marcus
>Wietse wrote:
>> MV wrote:
>> I'm trying to use multiple smtp IPs without having multiple postfix
>> instances.
>>
>> So I tried to split smtp using transport_maps and that works ok for
>> local mail destined to foreign destinations.
>> But it breaks the delivery of foreign mail destined to local
On 3/26/2014 3:42 PM, MV wrote:
> Noel Jones wrote:
>> MV wrote:
>>>
>>> 1.1.1.1:smtpinet n - n - - smtpd
>>> -o myhostname=mx1.example.com
>>> -o smtp_helo_name=mx1.example.com
>>> -o smtp_bind_address=1.1.1.1
>>
>> You can't set "smtp" options within t
Noel Jones wrote:
> MV wrote:
>>
>> 1.1.1.1:smtpinet n - n - - smtpd
>> -o myhostname=mx1.example.com
>> -o smtp_helo_name=mx1.example.com
>> -o smtp_bind_address=1.1.1.1
>
> You can't set "smtp" options within the "smtpd" service.
smtp options won't aff
MV:
> I'm trying to use multiple smtp IPs without having multiple postfix instances.
>
> So I tried to split smtp using transport_maps and that works ok for
> local mail destined to foreign destinations.
> But it breaks the delivery of foreign mail destined to local
> destinations with the error "
On 3/26/2014 2:42 PM, MV wrote:
> I'm trying to use multiple smtp IPs without having multiple postfix instances.
>
> So I tried to split smtp using transport_maps and that works ok for
> local mail destined to foreign destinations.
> But it breaks the delivery of foreign mail destined to local
> d
I'm trying to use multiple smtp IPs without having multiple postfix instances.
So I tried to split smtp using transport_maps and that works ok for
local mail destined to foreign destinations.
But it breaks the delivery of foreign mail destined to local
destinations with the error "mail for example
27 matches
Mail list logo
