Hi Steve,
breaking the RFC by guessing how a spam issueing address might look is
not good.
Better is to reject a spam mail directly during connection phase,
because once your mail server has accepted the mail, you _must_ deliver
it to the user anyway (with special tags i.e.), because of data
prot
On Wed May 13, 2009 at 15:53:34 +0200, Ernesto wrote:
> breaking the RFC by guessing how a spam issueing address might look is
> not good.
Indeed, which is why I wondered how other people solve this
specific problem.
> Better is to reject a spam mail directly during connection phase,
> becaus
You may want to look into BATV.
It works this way (very roughly, see the spec for real details)
Every email you send has a MAIL FROM modified (somewhat ala SRS) to
contain a key as part of the LHS.
Every time you receive an email with a null MAIL FROM, check the RCPT
TO. If the key is not t
On Tuesday 12 May 2009 22:16:14 Steve Kemp wrote:
> I wonder how people on the list deal with joe job attacks?
>
> Right now I accept all incoming messages which are addressed to
> valid recipients on the domains I host *AND* all incoming bounces.
Personally (and this is a private domain) I
First issue: If the plugins (Most are highly customized) run under
forkerserver, will they be expected to run under pre-fork without
modification? I'm trying to recall some of the discussions, and I think
the issues were with pollserver - something about async code(?).
If I recall our own simila
Actually, I'm setting up a completely new system. Briefly reading the
information on the wiki, it appears that this is the best way for me to
go, since I won't be using apache, and pollserver doesn't sound stable.
First issue: If the plugins (Most are highly customized) run under
forkerserver, wil
