Hi Guys,
I am looking for somebody who can provide consultancy to help me tune
some Postfix installations. Can anybody provide recommendations?
I can provide further details if needed, but in a nutshell I am
delivering a lot of list email which is generated using Perl scripts.
I would prefer an
Am 30.07.2014 11:06, schrieb Andrew Beverley:
> I am looking for somebody who can provide consultancy to help me tune
> some Postfix installations. Can anybody provide recommendations?
tune *what* context
> I can provide further details if needed, but in a nutshell I am
> delivering a lot of li
On Wed, 2014-07-30 at 11:12 +0200, li...@rhsoft.net wrote:
> Am 30.07.2014 11:06, schrieb Andrew Beverley:
> > I am looking for somebody who can provide consultancy to help me tune
> > some Postfix installations. Can anybody provide recommendations?
>
> tune *what* context
Mail delivery. Lots of
Am 30.07.2014 11:27, schrieb Andrew Beverley:
> On Wed, 2014-07-30 at 11:12 +0200, li...@rhsoft.net wrote:
>> Am 30.07.2014 11:06, schrieb Andrew Beverley:
>>> I am looking for somebody who can provide consultancy to help me tune
>>> some Postfix installations. Can anybody provide recommendations?
On Wed, 2014-07-30 at 11:34 +0200, li...@rhsoft.net wrote:
[...]
> spit a lot of messages in the queue means that from the
> application side the sending process is done, deliver
> bulk mail to the final RCPT is a different story
Thanks for the additional info.
> for *really* large amount of mail
BlueStar88:
> Regardless how difficult it would be to develop a reliable solution for
> that, I keep thinking here and throw another idea, inspired by Tor and
> it's multilayer crypto: Is there a way, once a connection is established
> to the server, to establish another one downwards within that
>
Am 30.07.2014 um 13:16 schrieb Wietse Venema:
> BlueStar88:
>> Regardless how difficult it would be to develop a reliable solution for
>> that, I keep thinking here and throw another idea, inspired by Tor and
>> it's multilayer crypto: Is there a way, once a connection is established
>> to the ser
BlueStar88:
> Regardless how difficult it would be to develop a reliable solution for
> that, I keep thinking here and throw another idea, inspired by Tor and
> it's multilayer crypto: Is there a way, once a connection is established
> to the server, to establish another one downwards within that
>
On 30/07/2014 15:07, BlueStar88 wrote:
> Am 30.07.2014 um 14:17 schrieb Daniele Nicolodi:
>> One of the main features of the current email infrastructure is its
>> interoperability and capability to work as a federated system. Therefore
>> the adherence to the defined and deployed protocols is very
Am 30.07.2014 um 15:06 schrieb Wietse Venema:
> Wietse:
>> I suggest that you Google for FUSSP.
> Yes, we're all a bunch of retarded sadists who would rather see the
> world suffer than take suggestions from well-meaning people that
> would solve the problem forever. Having confessed this, I will
BlueStar88:
> Am 30.07.2014 um 15:06 schrieb Wietse Venema:
> > Wietse:
> >> I suggest that you Google for FUSSP.
> > Yes, we're all a bunch of retarded sadists who would rather see the
> > world suffer than take suggestions from well-meaning people that
> > would solve the problem forever. Having
On Wed, Jul 30, 2014 at 08:41:51AM +0200, BlueStar88 wrote:
> Regardless how difficult it would be to develop a reliable solution for
> that, I keep thinking here and throw another idea, inspired by Tor and
> it's multilayer crypto: Is there a way, once a connection is established
> to the server,
On Wed, Jul 30, 2014 at 10:06:34AM +0100, Andrew Beverley wrote:
> Incidentally, I am submitting using the sendmail command, rather than
> SMTP (against the advice of the tuning README) - how much difference is
> this likely to make?
This doubles the disk I/O cost of message delivery and serializ
Am 30.07.2014 um 16:14 schrieb Viktor Dukhovni:
> On Wed, Jul 30, 2014 at 08:41:51AM +0200, BlueStar88 wrote:
>
>> Regardless how difficult it would be to develop a reliable solution for
>> that, I keep thinking here and throw another idea, inspired by Tor and
>> it's multilayer crypto: Is there a
On Wed, Jul 30, 2014 at 07:17:43PM +0200, BlueStar88 wrote:
> First, I still like to limit my proposal to MTA-MTA connections.
You have no proposal, you just don't have the expertise to see
that. Unfortunately there is no royal road to expertise in this
or most other fields.
> This proposal dep
BlueStar88:
> "FUSSP stands for "Final Ultimate Solution to the Spam Problem. It's
> used to describe ideas put forth by people with little
> sysadmin/email/spam fighting experience who think that they found the
> magic problem to stop spam"
Indeed. When you come with a solution to solve problem X
The EFF folks behind this effort have reached out to me and we've
discussed some of the issues. I am somewhat ambivalent about this,
as it introduces a non-scalable registry that does fully address
the problem, and perhaps reduces incentives to do it right and
deploy DANE. On the other hand, DNS
On Wed, Jul 30, 2014 at 03:38:41PM -0400, Jacob S Hoffman-Andrews wrote:
> >The EFF folks behind this effort have reached out to me and we've
> >discussed some of the issues. I am somewhat ambivalent about this,
> >as it introduces a non-scalable registry that does fully address
> >the problem, a
On Tue, Jul 29, 2014 at 11:59:41PM +0200, Patrick Ben Koetter wrote:
> > Which brings us back to the key question, what is the real motivation
> > for this? Preventing HELO forgery? Making TLS access control easier
> > to use (with "dane-only", one might be able to use check_helo_access
> > safe
On Wed, 2014-07-30 at 14:23 +, Viktor Dukhovni wrote:
> On Wed, Jul 30, 2014 at 10:06:34AM +0100, Andrew Beverley wrote:
>
> > Incidentally, I am submitting using the sendmail command, rather than
> > SMTP (against the advice of the tuning README) - how much difference is
> > this likely to ma
On Wed, Jul 30, 2014 at 11:33:31PM +0100, Andrew Beverley wrote:
> One more similar question: is there much value in reusing the same
> connection to send each email? Obviously that removes the expense of
> creating a connection, but prevents parallel submission. Should I be
> trying to do both?
On Wed, 2014-07-30 at 22:43 +, Viktor Dukhovni wrote:
> Connection re-use does not prevent concurrency, you'd need a pool
> of connections or parallel submission processes pulling messages
> from the application queue. Concurrency is more important than
> connection re-use.
Ah, okay. Is defau
On Thu, Jul 31, 2014 at 12:07:18AM +0100, Andrew Beverley wrote:
> On Wed, 2014-07-30 at 22:43 +, Viktor Dukhovni wrote:
> > Connection re-use does not prevent concurrency, you'd need a pool
> > of connections or parallel submission processes pulling messages
> > from the application queue. Co
* Viktor Dukhovni :
> On Tue, Jul 29, 2014 at 11:59:41PM +0200, Patrick Ben Koetter wrote:
>
> > > Which brings us back to the key question, what is the real motivation
> > > for this? Preventing HELO forgery? Making TLS access control easier
> > > to use (with "dane-only", one might be able to
24 matches
Mail list logo
