Charlie Orford:
>I know I am starting to sound like a broken record but I really
>think a sensible, clean method to run a secondary mx that is capable
>of verifying recipients and accepting mail (rather than deferring)
>with or without the primary being up would be a nice feature to
>have.
Indeed,
- Original Message -
From: Noel Jones
To: postfix-users@postfix.org
Cc:
Sent: Wednesday, July 6, 2011 12:25 AM
Subject: Re: unverified_recipient_tempfail_action = permit
>To run a policy service on all addresses, add the
>check_policy_service directive to your smtpd restrictions a
On 7/5/2011 4:00 PM, Charlie Orford wrote:
> For the above to work, I assume you could give check_recipient_access a
> table containing: *@ on the left and the policy script on the right (i.e. to
> force it
> to fire the policy script for every recipient). Not sure if that actually
> works or is
- Original Message -
From: Reindl Harald
To: postfix-users@postfix.org
Cc:
Sent: Tuesday, July 5, 2011 11:03 PM
Subject: Re: unverified_recipient_tempfail_action = permit
>hm why not using mysql for the list of valid users and replication?
>mysql-replication supports SSL, the
Am 05.07.2011 23:00, schrieb Charlie Orford:
>
>
>
>
> - Original Message -
> From: Noel Jones
> To: postfix-users@postfix.org
> Cc:
> Sent: Tuesday, July 5, 2011 8:49 PM
> Subject: Re: unverified_recipient_tempfail_action = permit
>
>> Mayb
- Original Message -
From: Noel Jones
To: postfix-users@postfix.org
Cc:
Sent: Tuesday, July 5, 2011 8:49 PM
Subject: Re: unverified_recipient_tempfail_action = permit
>Maybe a compromise?
>How about running on the main MX
>postmap -s btree:/path/verify | grep ':250 &
- Original Message -
From: Wietse Venema
To: Postfix users
Cc:
Sent: Tuesday, July 5, 2011 8:38 PM
Subject: Re: unverified_recipient_tempfail_action = permit
>Fundamentally, both approaches rely on talking to the primary MX,
>and therefore both approaches would suffer from err
- Original Message -
From: /dev/rob0
To: postfix-users@postfix.org
Cc:
Sent: Monday, July 4, 2011 3:06 PM
Subject: Re: unverified_recipient_tempfail_action = permit
>On Mon, Jul 04, 2011 at 04:48:44AM -0700, Charlie Orford wrote:
>> unverified_recipient_tempfail_action = perm
On 7/5/2011 1:38 PM, Wietse Venema wrote:
> Charlie Orford:
>> I will run the tests and get the output for you later tonight but
>> my suspicion is that there was likely nothing wrong with the
>> address cache, just that a lot of addresses had never been probed
>> by the secondary mx as the primary
Charlie Orford:
> I will run the tests and get the output for you later tonight but
> my suspicion is that there was likely nothing wrong with the
> address cache, just that a lot of addresses had never been probed
> by the secondary mx as the primary mx is up virtually 99.9% of
> the time.
Wietse
- Original Message -
From: Wietse Venema
To: Postfix users
Sent: Tuesday, July 5, 2011 6:46 PM
Subject: Re: unverified_recipient_tempfail_action = permit
>>Charlie Orford:
>> I will run the tests and get the output for you later tonight but my
>> suspicion
>>
Charlie Orford:
> I will run the tests and get the output for you later tonight but my suspicion
> is that there was likely nothing wrong with the address cache, just that
> a lot of addresses had never been probed by the secondary mx as the
> primary mx is up virtually 99.9% of the time.
In that
- Original Message -
>From: Wietse Venema
>To: Postfix users
>Sent: Tuesday, July 5, 2011 5:38 PM
>Subject: Re: unverified_recipient_tempfail_action = permit
>
>>Reindl Harald:
>> Am 05.07.2011 16:55, schrieb Wietse Venema:
>> > If no such pro
Reindl Harald:
> Am 05.07.2011 16:55, schrieb Wietse Venema:
> > If no such problem exists, then we know that cache expiration
> > has nothing to do with the issue and we can move on.
> >
> > When the address verify cache works properly, it should become
> > populated over time (by spammers, by le
Am 05.07.2011 16:55, schrieb Wietse Venema:
> If no such problem exists, then we know that cache expiration
> has nothing to do with the issue and we can move on.
>
> When the address verify cache works properly, it should become
> populated over time (by spammers, by legitimate sites that have
Charlie Orford:
>Hi Wietse,
>
>Although the address caching should have worked as you describe,
>we found that it failed for a number of addresses despite the fact
>that these addresses had received email in the last 31 days (most
>had in fact received mail in the last 24 hours).
To report a probl
- Original Message -
From: Charlie Orford
To: Postfix users
Sent: Tuesday, July 5, 2011 10:45 AM
Subject: Re: unverified_recipient_tempfail_action = permit
>Hi Wietse,
>
>Although the address caching should have worked as you describe, we
>found that it failed for a number
>From: Wietse Venema
>Sent: Monday, July 4, 2011 9:10 PM
>Subject: Re: unverified_recipient_tempfail_action = permit
>
>My previous reply suffered from damage while editing. This is an
>attempt to fix it.
>
>The problem with recipients not in the verify cache is easily
Jerry:
> On Mon, 4 Jul 2011 04:48:44 -0700 (PDT)
> Charlie Orford articulated:
>
> > unverified_recipient_tempfail_action = permit? would have solved this
> > problem with the small penalty of a brief period of potential
> > backscatter.
>
> The "potential
Jerry:
> On Mon, 4 Jul 2011 04:48:44 -0700 (PDT)
> Charlie Orford articulated:
>
> > unverified_recipient_tempfail_action = permit? would have solved this
> > problem with the small penalty of a brief period of potential
> > backscatter.
>
> The "potential
On Mon, Jul 04, 2011 at 04:48:44AM -0700, Charlie Orford wrote:
> unverified_recipient_tempfail_action = permit would have solved
> this problem with the small penalty of a brief period of potential
> backscatter.
>
> Where is the down side?
That "small penalty"
On Mon, 4 Jul 2011 04:48:44 -0700 (PDT)
Charlie Orford articulated:
> unverified_recipient_tempfail_action = permit would have solved this
> problem with the small penalty of a brief period of potential
> backscatter.
The "potential backscatter" is enough to turn me off on th
yed to doesn't accept the user). Backscatter
> is usually caused by spam of course, because spam is sent to all kinds of
> users @example.com.
>
> I had in mind to use recipient address verification to avoid that and then
> set "unverified_recipient_tempfail_action = p
On 2011-06-12 Wiebe Cazemier wrote:
> From: "Reindl Harald"
>> Am 11.06.2011 16:55, schrieb Wiebe Cazemier:
>>> That's not what I meant. I meant that 99% of the time, the primary
>>> server will be up and recipient address verification will work to
>>> reject (spam) messages to unknown users. Thos
Am 12.06.2011 11:50, schrieb Manuel Riel:
> I also kept a list of valid recipients on my backup mx for quite some time,
> but this is no elegant solution. I need to collect the list from various SLQ-
> and LDAP sources every few hours.
man mysql replication
man mysql ssl
if your configurati
On 12 Jun 2011, at 11:23, Wiebe Cazemier wrote:
> - Original Message -
>> From: "Reindl Harald"
>> To: postfix-users@postfix.org
>> Sent: Sunday, 12 June, 2011 10:04:02 AM
>> Subject: Re: unverified_recipient_tempfail_action = permit
>>
&g
- Original Message -
> From: "Reindl Harald"
> To: postfix-users@postfix.org
> Sent: Sunday, 12 June, 2011 10:04:02 AM
> Subject: Re: unverified_recipient_tempfail_action = permit
>
>
>
> Am 12.06.2011 09:06, schrieb Wiebe Cazemier:
> >> so yo
Am 12.06.2011 09:06, schrieb Wiebe Cazemier:
>> so you do not need any backup-MX because if your primary
>> is not available the deferring happens on the sender
>>
>> this is the way smtp works
>
> Default defer time for most SMTP servers is only 3 to 5 days, that is not
> long enough for me.
- Original Message -
> From: "Reindl Harald"
> To: postfix-users@postfix.org
> Sent: Saturday, 11 June, 2011 6:23:59 PM
> Subject: Re: unverified_recipient_tempfail_action = permit
>
>
>
> Am 11.06.2011 16:55, schrieb Wiebe Cazemier:
> > That
Am 11.06.2011 16:55, schrieb Wiebe Cazemier:
> That's not what I meant. I meant that 99% of the time, the primary server
> will be up and recipient address verification will work to reject (spam)
> messages to unknown users. Those two scenario's you mentioned are when
> the primary is down or
- Original Message -
> From: "Wietse Venema"
> To: "Wiebe Cazemier"
> Cc: postfix-users@postfix.org
> Sent: Friday, 10 June, 2011 9:37:39 PM
> Subject: Re: unverified_recipient_tempfail_action = permit
>
> Wiebe Cazemier:
> > That's wh
Wiebe Cazemier:
> That's why I was asking if it wouldn't be a good idea to have
> 'permit' be a viable option for unverified_recipient_tempfail_action.
unverified_recipient_tempfail_action is triggered when:
- The backup MX could not reach the primary MX.
- The primary MX replied with a 4xx resp
On Fri, Jun 10, 2011 at 09:35:03PM +0200, Wiebe Cazemier wrote:
> > It can't. Never before seen recipients will be deferred, recipients
> > validated while the primary MX was up and cached (for 7-14 days) will
> > however be accepted. This is good enough, and the best you can do
> > without gettin
- Original Message -
> From: "Victor Duchovni"
> To: "Wiebe Cazemier"
> Cc: postfix-users@postfix.org
> Sent: Friday, 10 June, 2011 5:04:09 PM
> Subject: Re: unverified_recipient_tempfail_action = permit
>
> On Fri, Jun 10, 2011
On Fri, Jun 10, 2011 at 05:00:16PM +0200, Wiebe Cazemier wrote:
> - Original Message -
> > From: "Wietse Venema"
> > To: "Wiebe Cazemier"
> > Cc: postfix-users@postfix.org
> > Sent: Friday, 10 June, 2011 2:50:34 PM
> > Subje
- Original Message -
> From: "Wietse Venema"
> To: "Wiebe Cazemier"
> Cc: postfix-users@postfix.org
> Sent: Friday, 10 June, 2011 2:50:34 PM
> Subject: Re: unverified_recipient_tempfail_action = permit
>
> Wiebe Cazemier:
> > - The serve
Wiebe Cazemier:
> - The server is backup MX for mail hosts that I don't know anything
> about.
In that case, the backup MX needs to ask the primary MX if the
recipient is valid. Otherwise, you become a backscatter source.
Wietse
- Original Message -
> From: "Ansgar Wiechers"
> To: postfix-users@postfix.org
> Sent: Friday, 10 June, 2011 12:47:35 AM
> Subject: Re: unverified_recipient_tempfail_action = permit
>
> On 2011-06-10 Wiebe Cazemier wrote:
> > Ansgar Wiechers wrote:
t; accept the user). Backscatter is usually caused by spam of course,
>>> because spam is sent to all kinds of users @example.com.
>>>
>>> I had in mind to use recipient address verification to avoid that and
>>> then set "unverified_recipient_tempfail
> (bounces of messages because the server that is relayed to doesn't
> accept the user). Backscatter is usually caused by spam of course,
> because spam is sent to all kinds of users @example.com.
>
> I had in mind to use recipient address verification to avoid that and
>
;
> I had in mind to use recipient address verification to avoid that and
> then set "unverified_recipient_tempfail_action = permit". The idea
> behind this was:
>
> - Prevent backscatter mail when the primary host is up because every
> address is verified first.
>
s of users
@example.com.
I had in mind to use recipient address verification to avoid that and then set
"unverified_recipient_tempfail_action = permit". The idea behind this was:
- Prevent backscatter mail when the primary host is up because every address is
verified first.
- Acce
42 matches
Mail list logo
