On 16/12/10 01:04, Benny Pedersen wrote:
so more then one header is needed in your case ?
Well SA only see first header, second header added after mail
re-inserted into queue after SA check.
What I don't understand is why it was working for some hosts before,
because there always at least one
Problem was in "spf: relayed through one or more trusted relays, cannot
use header-based Envelope-From"
always_trust_envelope_sender 1 is helps in my case, both of my trusted
relays are 127.0.0.1.
On 15.12.10 22:29, Benny Pedersen wrote:
On ons 15 dec 2010 20:05:46 CET, Nikolay Sh
On 15.12.2010 21:28, Benny Pedersen wrote:
On ons 15 dec 2010 19:20:28 CET, Nikolay Shopik wrote
I did play more with gmail as example, and notice. If I send email
from web interface SPF always matched and OK. If I'm using MUA to send
mail via SMTP it never fail or pass SPF rule. Probabl
On 15.12.2010 20:33, Benny Pedersen wrote:
On ons 15 dec 2010 18:08:20 CET, Nikolay Shopik wrote
my mx have public ip and not behind nat, should i add public ip of my
mx into internal_networks?
no, just trusted (you trust your own server, and forwarding ips)
internal is more if you use
my mx have public ip and not behind nat, should i add public ip of my mx into
internal_networks?
"Matus UHLAR - fantomas" wrote:
>>> On 15.12.10 10:59, Nikolay Shopik wrote:
>>>> I have domain hosted at google apps, and my domain have recomended
>by
>
On 15/12/10 12:04, Matus UHLAR - fantomas wrote:
On 15.12.10 10:59, Nikolay Shopik wrote:
I have domain hosted at google apps, and my domain have recomended by
google txt record "v=spf1 include:_spf.google.com ~all". So far when I
receive mail from this domain spamassassin doesn'
I have domain hosted at google apps, and my domain have recomended by
google txt record "v=spf1 include:_spf.google.com ~all". So far when I
receive mail from this domain spamassassin doesn't trigger rule SPF_PASS
nor SPF_SOFTFAIL, is this normal?
I'm running 3.3.1 version
On 8/26/2007 11:36 PM, John D. Hardin wrote:
On Sun, 26 Aug 2007, Nikolay Shopik wrote:
Just parse received headers in attached message in backscatter.
You can easily see what this message sent not by your server and
you can reject such backscatter, because you never sent such
messages.
Not
On 8/26/2007 11:36 PM, John D. Hardin wrote:
On Sun, 26 Aug 2007, Nikolay Shopik wrote:
Just parse received headers in attached message in backscatter.
You can easily see what this message sent not by your server and
you can reject such backscatter, because you never sent such
messages.
Not
On 8/26/2007 4:57 AM, Rob McEwen wrote:
Marc,
Overall good answers... but about six months ago, one of my users was
joe jobbed in "biblical proportions"... in this case, the spammer chose
this one "real" address and that spammer must have either sent the bots
this info, or pre-programmed the
On 8/26/2007 12:08 AM, John Rudd wrote:
mouss wrote:
Kai Schaetzl wrote:
Rense Buijen wrote on Wed, 22 Aug 2007 16:43:19 +0200:
I didn't know that a backup MX can lead to more trouble then having
just one
Unfortunately, backup MXes attract spammers :-(. You could at least
add some m
Hi list,
I would like to know if there already rule exist. Parsing receive
headers check HELO existing in DNS and if not increase score.
Checked docs for SA and found only eval:check_rbl and this is seems not
what I'm need at all, correct me if I'm wrong.
12 matches
Mail list logo
