You could ask the core developers to give you direct access to the main github
repo :-)
It seems apparent that you're invested in moving QP forward, and have the time,
talent, and motivation to do so while still playing by the rules. If I was on
the core team I think I'd be fine with letting yo
https://github.com/smtpd/qpsmtpd/pull/20
Prior to this change, many of the plugins had some form of immunity tests. Most
of the implementations were partial (ie, they set immunity to for 1, 2, and
sometimes 3 of the standard immunity tests (relay_client, whitelisthost,
whitelistsender). This
Is there anything else I can do to move this forward?
Matt
On May 21, 2012, at 12:06 PM, Matt Simerson wrote:
>
> https://github.com/smtpd/qpsmtpd/pull/13
>
>
> replaces 3 relay plugins (check_relay, check_norelay, relay_only) with a
> single plugin (relay).
>
> Same functionality.
> Bonu
Added dependency tests within the plugins, so the plugins and tests will check
for, and gracefully fail if their dependencies don't exist.
Pull request: https://github.com/smtpd/qpsmtpd/pull/19
Changes: https://github.com/smtpd/qpsmtpd/pull/19/files
Matt
On Jun 2, 2012, at 11:15 AM, Jared Johnson wrote:
>> Yup. Part of the motivation for this plugin was to short circuit all the
>> intermediate plugins and handlers so I can feed the message to sa-learn
>> and dspam. Until dspam is trained, that's a very important step in
>> training it. But there'
>> Why hasn't your rejected idea been worked into qpsmtpd yet?
>
> Because I came to view qpsmtpd in a different way than many
> do (many view it as a service with useful plugins which they
> can deploy, use, and enjoy). Instead I view it more as a
> framework for rejecting/processing/handlin
> Yup. Part of the motivation for this plugin was to short circuit all the
> intermediate plugins and handlers so I can feed the message to sa-learn
> and dspam. Until dspam is trained, that's a very important step in
> training it. But there's no gain in validating the HELO name, SPF, or
> Domain
> Yup. Part of the motivation for this plugin was to short circuit all the
> intermediate plugins and handlers so I can feed the message to sa-learn
> and dspam. Until dspam is trained, that's a very important step in
> training it. But there's no gain in validating the HELO name, SPF, or
> Domain
> What problems might I encounter if I were to do this?
>
> I ask because I have a client who is currently getting spammed viciously
> by spammers who use one address in MAIL FROM (to pass SPF tests) and they
> use the senders email address in the From: header so they can get
> whitelist scoring by
Is it a good idea to validate that the MAIL FROM address is the same as the
From: header in the message?
What exceptions need to be made, if any?
What problems might I encounter if I were to do this?
I ask because I have a client who is currently getting spammed viciously by
spammers who use
On Fri Jun 01, 2012 at 18:40:04 -0700, Matt Simerson wrote:
> But reducing code and simplifying plugins is just as important. This
> implementation adds more control and flexibility to plugins without
> additional code. For example, now it's possible (without writing code)
> to configure all plugi
11 matches
Mail list logo
