Good Afternoon,
I am using OpenBSD 4.1 Release, patched as of today.
When starting spamd in debug mode I receive a bogus config line message.
Where it says need 'tag;message;a/m;a/m;a/m...' this looks like the format
for spamd.conf,
but I am using the default spamd.conf with no changes, so I
Hi,
I've got an OpenBSD 4.1-stable i386 setup with active spamd.
When a connection comes in it gets redirected into spamd... but the
spamdb isn't updated. When turning off the redirection or sending out
emails new servers are getting whitelisted just fine.
from /etc/rc.conf.local
spamd_flags
Hi,
A have two questions regarding the gathering of statistics.
1. ftp-proxy
How does one track FTP usage of lan to internet servers?
2. spamd
Is there any way to gather intelligent reports of what is happening
with spamd? In essence, I want to get an idea of how much spam has
been prevented
On 2007/07/06 09:26, Juan Miscaro wrote:
1. ftp-proxy
How does one track FTP usage of lan to internet servers?
pfctl -sr -vv is one of many ways.
2. spamd
Is there any way to gather intelligent reports of what is happening
with spamd? In essence, I want to get an idea of how much spam has
--- Stuart Henderson [EMAIL PROTECTED] wrote:
On 2007/07/06 09:26, Juan Miscaro wrote:
1. ftp-proxy
How does one track FTP usage of lan to internet servers?
pfctl -sr -vv is one of many ways.
I am using labels to record traffic. The FTP data traffic is visible
using your invocation but
Hello list,
I've been bitten by a race condition in spamd. I've got a low-prio MX
configured as an MX trap with spamd -M:
bzero.se. 900 IN MX 10 mx.bzero.se.
bzero.se. 900 IN MX 99 mxtrap.bzero.se.
In the log below, a re-attempt
I think the passtime should use now + passtime not now + expire,
Is it correct?
Index: libexec/spamd/grey.c
===
RCS file: /cvs/src/libexec/spamd/grey.c,v
retrieving
hi!
On Tue, Jun 26, 2007 at 07:04:29PM -0400, Daniel Ouellet wrote:
I setup the spamd sync feature between two servers running 4.1 and I
observe the following issues with the setup itself. Some setup based on
the man page do not work for me anyway and some are not always reliable
and some
?
try to set
multicast_host=dc0
in /etc/rc.conf or /etc/rc.conf.local
I sure will try. In any case, I sure can use unicast only as well. But I
will try to know for sure.
did you upgrade it to 4.1-stable? there was a minor fix for spamd-sync
after the release.
No yet. (; I install about 20
traffic through the box. ripd -- as it already plays around with
the routing table -- add such a route on startup but I think that's
overkill for spamd.
--
:wq Claudio
for the clarification Claudio!
May be a suggestion, a quick addition to man 8 spamd in regards to
enable ip multicast on the systems might be welcome. I sure overlook
that for sure and looking at the man page again. I see no reference to
it. Obviously, I should have thought about it, but just
On Wed, Jun 27, 2007 at 04:05:06PM -0400, Daniel Ouellet wrote:
Thanks for the clarification Claudio!
May be a suggestion, a quick addition to man 8 spamd in regards to
enable ip multicast on the systems might be welcome. I sure overlook
that for sure and looking at the man page again. I
Jason McIntyre wrote:
On Wed, Jun 27, 2007 at 04:05:06PM -0400, Daniel Ouellet wrote:
Thanks for the clarification Claudio!
May be a suggestion, a quick addition to man 8 spamd in regards to
enable ip multicast on the systems might be welcome. I sure overlook
that for sure and looking
Hi,
I setup the spamd sync feature between two servers running 4.1 and I
observe the following issues with the setup itself. Some setup based on
the man page do not work for me anyway and some are not always reliable
and some always work. See below.
Example
Interface facing the Internet
Hi,
From the man page it appears that spamd relies on
static information about spam originators.
Why not a more dynamic scheme ?.
Why not run the content of the mail through a spam
detector (like dspam), find the spam score and make
decisions based on that. I know that spam detection
On Tue, 12 Jun 2007 03:04:23 -0700 (PDT), Praveen wrote:
Hi,
From the man page it appears that spamd relies on
static information about spam originators.
Why not a more dynamic scheme ?.
Why not run the content of the mail through a spam
detector (like dspam), find the spam score and make
Praveen wrote:
From the man page it appears that spamd relies on
static information about spam originators.
greylisting is pretty dynamic.
---
Lars Hansson
RW wrote:
On Tue, 12 Jun 2007 03:04:23 -0700 (PDT), Praveen wrote:
Hi,
From the man page it appears that spamd relies on
static information about spam originators.
Why not a more dynamic scheme ?.
Why not run the content of the mail through a spam
detector (like dspam), find
* Praveen [EMAIL PROTECTED] [2007-06-12 05:14]:
Hi,
From the man page it appears that spamd relies on
static information about spam originators.
Why not a more dynamic scheme ?.
No, it doesn't. please read the man page instead of
trolling.
Why not run the content of the mail
I still don't see how hosts in spamd-white are not sent to spamd.
what if a host is in spamd-white, but not in spamd-exempt..
-Bob
* Stuart Henderson [EMAIL PROTECTED] [2007-06-11 17:21]:
On 2007/06/08 16:02, Bob Beck wrote:
rdr-anchor hoststated/smtp from spamd-white
rdr
On 2007/06/12 09:04, Bob Beck wrote:
I still don't see how hosts in spamd-white are not sent to spamd.
what if a host is in spamd-white, but not in spamd-exempt..
# pfctl -sn -vv|grep -E '(smtp|hoststated)'
@0 rdr-anchor hoststated/smtp from spamd-white:1440 to any
@1 rdr inet proto tcp
It's good to see I'm not the only one;-) I checked the archives and I
must have missed the memo. Here shows an updated version:
http://www.ualberta.ca/~beck/greyscanner/
Ah, thanks. I've googled for greyscanner and found only beck@'s
presentation...
But now I see it.. thanks ;)
into an IPS on OpenBSD (snort inline works only on
Linux, if I'm not mistaken).
Similarly, when SpamAssassin or DSPAM determine that an e-mail is spam,
(again in layman terms) they inform spamd about the spammer IP and
then-after that IP is handled by spamd. Please beware this scheme does
On 6/12/07, Soner Tari [EMAIL PROTECTED] wrote:
Probably a simple shell script could do the job, which would look at
SpamAssassin logs to find out the spam score and IP address, and insert
into spamd blacklists as necessary. The only caveat is that threshold
spam score for blacklisting should
to a host that
doesn't exist, and wastes a little of their time. I'm wondering if
a common spamd tarpit across all domains and clients - judicious
use of -b and -4 and -s options should do the trick - sitting
at this highest-pref MX might give me some information on email
addresses that get
On Wed, 13 Jun 2007 16:19:21 +1200 Stuart Henderson
[EMAIL PROTECTED] wrote:
On 2007/06/13 15:36, Kevin Nelson wrote:
We see a lot of spam targeting high-pref MX records.
Did you notice -M?
No (well yes, but mis-read low priority MX as low preference
MX), good point, I'll take a look.
long,
since spamd will not tarpit the host yet, right?
I am asking because I see some connected/disconnected messages not
related to any blacklist that last quite a while.
Regards,
Jeff
--
Get a Free E-mail Account at Mail.com!
Choose From 100+ Personalized Domains
Visit http://www.mail.com today
Hi,
The default setup in pf.conf makes spamd work on both
directions:
#no rdr on $ext_if proto tcp from spamd-white to any port smtp
#rdr pass on $ext_if proto tcp from any to any port smtp \
# - 127.0.0.1 port spamd
What is the best way to tell PF that spamd should work only
on inbound
read the archives for the answer to this and other fascinating
questions.
or look very carefully at the contents of that directory.
* Anton Karpov [EMAIL PROTECTED] [2007-06-09 04:53]:
I've noticed that original greyscanner by beck@ doesn't work with latest
spamd.
Is there fixed
On 2007/06/08 16:02, Bob Beck wrote:
rdr-anchor hoststated/smtp from spamd-white
rdr proto tcp from !spamd-exempt to $MX port smtp - 127.0.0.1 port spamd
The fact that those two table names are different looks suspiciously
wrong to me.
It took you pointing this out for me
Hi,
Thank you.
Can I assume that all connected/disconnected messages I see in /var/log/daemon
are
from blacklisted hosts or some are still greylisted (undefined)?
Regards,
Jeff
--
Get a Free E-mail Account at Mail.com!
Choose From 100+ Personalized Domains
Visit http://www.mail.com today
--- Jeff Santos [EMAIL PROTECTED] wrote:
Hi,
Thank you.
Can I assume that all connected/disconnected messages I see in
/var/log/daemon
are
from blacklisted hosts or some are still greylisted (undefined)?
Either blacklisted or greylisted.
Be smarter than spam. See how smart
blacklisted or greylisted.
If they are blacklisted, the connected/disconntected message
will name the blacklist(s) they are on. if they are greylisted, there
will be no mention of lists in the log message. For example, from my logs,
minutes ago:
Jun 10 13:50:32 snouts spamd[17678]: 82.54.64.16
I've noticed that original greyscanner by beck@ doesn't work with latest
spamd.
Is there fixed/updated version of greyscanner anywhere?
Thanks.
Hi,
I am new to OpenBSD and SPAMD, so forgive if I say stupid questions.
1. When run in default mode (greylist), spamd knows the spammers come
from blacklists in spamd.conf. But there is no spamd table in PF.
How?
2. Is there one way to know how many and which are the blacklisted
hosts
On 2007/06/09 13:17, Jeff Santos wrote:
1. When run in default mode (greylist), spamd knows the spammers come
from blacklists in spamd.conf. But there is no spamd table in PF.
How?
Everyone who isn't whitelisted gets redirected to spamd, so there's
only a need for a copy of the table in spamd
--- Jeff Santos [EMAIL PROTECTED] wrote:
Hi,
I am new to OpenBSD and SPAMD, so forgive if I say stupid questions.
1. When run in default mode (greylist), spamd knows the spammers come
from blacklists in spamd.conf. But there is no spamd table in PF.
How?
Greylisting and blacklisting
I'm feeling lazy today, has anyone already worked out how to use
greylisting with a hoststated pool that would like to share config?
name accordingly):
rdr-anchor hoststated/smtp from spamd-white
rdr proto tcp from !spamd-exempt to $MX port smtp - 127.0.0.1 port spamd
rdr-anchor hoststated/*
I might just have come up with this sooner if it weren't for
http://www.winkleighcider.com/?p=prodpound ...
rdr-anchor hoststated/smtp from spamd-white
rdr proto tcp from !spamd-exempt to $MX port smtp - 127.0.0.1 port spamd
The fact that those two table names are different looks suspiciously
wrong to me.
-Bob
to telnet to
port 25 of 1.1.1.35 which as I understand is caused by many reasons,
among them that the src hosts expects tcp packets only from
1.1.1.35 and
not from 1.1.1.5 which is the only ip from which the bridges spamd
could
use to talk to the src host (sender mta).
Try some
Hi All,
According to http://www.openbsd.org/spamd/ I have added a couple of new
blacklists to my original spamd.conf, previously I had only spews1,
china, and korea, and there was no problem. But now pfctl gives me an
error:
# /usr/libexec/spamd-setup -d
Getting http://www.openbsd.org/spamd
.
As far as I understood the article I am setting up a bridge with an ip
assigned [1.1.1.5/24] to the external interface in front of my
mailserver [1.1.1.35/24].
Now given the pf rules from above URL and spamd configured and running,
I see the following problem:
case 1: src host is whitelisted
that the src hosts expects tcp packets only from 1.1.1.35 and
not from 1.1.1.5 which is the only ip from which the bridges spamd could
use to talk to the src host (sender mta).
I don't think case 2 is for the reason you point out. At least I never
had that problem.
Do you have the absolutely essential pass
reasons,
among them that the src hosts expects tcp packets only from 1.1.1.35 and
not from 1.1.1.5 which is the only ip from which the bridges spamd could
use to talk to the src host (sender mta).
I don't think case 2 is for the reason you point out. At least I never
had that problem.
Do you
of 1.1.1.35 which as I understand is caused by many reasons,
among them that the src hosts expects tcp packets only from 1.1.1.35 and
not from 1.1.1.5 which is the only ip from which the bridges spamd could
use to talk to the src host (sender mta).
Try some tcpdump'ing to see where
On 2007-06-05T06:43, Edgars Mak?a wrote:
IP is static and entered commands/text is the same too. No mistakes, i
was carefully checking all commands and entered text.
And as i found most problematic smtp is windows based MailEnable.
What else i should check?
maybe your spamlogd is the problem.
I tried to restart spamlogd, nothing...
Any other ideas?
Thanks.
Marcus Popp wrote:
On 2007-06-05T06:43, Edgars Mak?a wrote:
IP is static and entered commands/text is the same too. No mistakes, i
was carefully checking all commands and entered text.
And as i found most problematic smtp is
Hi!
I have some problems with spamd. A lot of smtp servers stops at this
point of cycle:
Jun 4 20:40:17 firewall spamd[7659]: xxx.yyy.zzz.ccc: connected (118/3)
Jun 4 20:44:14 firewall spamd[7659]: xxx.yyy.zzz.ccc: disconnected
after 374 seconds.
After some retries nothing changes
Many things. according to the logs you have there it didn't
even talk smtp to you, so it shouldn't pass.
* Edgars Mak??a [EMAIL PROTECTED] [2007-06-04 12:07]:
Hi!
I have some problems with spamd. A lot of smtp servers stops at this
point of cycle:
Jun 4 20:40:17 firewall spamd
With one such non passable smtp server admin we tested it via phone. He
said that promt is very slow (as it should be), then he got 451 Temp
error. After 5, 15, 30 and 60 minutes he retried, nothing :(
What is a most common options for spamd?
Bob Beck wrote:
Many things. according
On 6/4/07, Edgars Makra [EMAIL PROTECTED] wrote:
With one such non passable smtp server admin we tested it via phone. He
said that promt is very slow (as it should be), then he got 451 Temp
error. After 5, 15, 30 and 60 minutes he retried, nothing :(
If you tried connecting by manually
IP is static and entered commands/text is the same too. No mistakes, i
was carefully checking all commands and entered text.
And as i found most problematic smtp is windows based MailEnable.
What else i should check?
Rogier Krieger wrote:
On 6/4/07, Edgars Makra [EMAIL PROTECTED] wrote:
With
* Bob Beck [EMAIL PROTECTED] [2007-05-24 08:22]:
rfc 2821 specifically forbids this behaviour.
quote
The DATA command can fail at only two points in the protocol exchange:
- If there was no MAIL, or no RCPT, command, or all such commands
were rejected, the server MAY
received.
Which of course would undermine a lot of the benefit of spamd. I
think one of the points is to reject the mail before the data is sent
down the pipe, allowing the data wastes the receivers bandwidth.
I went looking in other places within these two RFCs for indications
yes, but not in response to the DATA command (what I was talking about)
but after.
no, you're wrong. right from rfc 2821:
8
DATA
I: 354 - data - S: 250
E: 552, 554, 451, 452
E: 451, 554, 503
8
explicitly - if I decide something is wrong
* Bob Beck [EMAIL PROTECTED] [2007-05-24 17:13]:
yes, but not in response to the DATA command (what I was talking about)
but after.
no, you're wrong. right from rfc 2821:
8
DATA
I: 354 - data - S: 250
E: 552, 554, 451, 452
E: 451, 554,
On 5/24/07, Henning Brauer [EMAIL PROTECTED] wrote:
...
the table totally contradicts the text... kind of funny :)
Perhaps that's why the current internet-draft for the revision of RFC
2821 has this in the table:
DATA
I: 354 - data - S: 250
E: 552,
* Renaud Allard [EMAIL PROTECTED] [2007-05-22 14:15]:
Indeed, but it could cause you to get blacklisted by some automated
checkers
no, that is bullshit.
those checkers do not exist any more (or they went irrelevant).
it has been proven many many many moons ago that this kind of test is
* Bob Beck [EMAIL PROTECTED] [2007-05-22 23:45]:
just deduced from trial and error. Also greylisting should happen at
RCPT TO, and probably not at DATA as there are some widely used MTAs
that are buggy and choke when a 4xx error is sent in the DATA phase.
I've been running this at
Henning Brauer wrote:
err, wait, are you giving a 4xx in reply to DATA?
that is invalid.
The response to the DATA command is 354 as it should. But at the end of
the DATA phase, a 451 is returned.
--
01010010011001010110111001110111010101100100
On 5/23/07, Henning Brauer [EMAIL PROTECTED] wrote:
...
err, wait, are you giving a 4xx in reply to DATA?
that is invalid.
At least for 451 and 421 replies, it sure seems legal to me. To quote RFC 2821:
4.3.2 Command-Reply Sequences
...
In addition to the codes listed below, any SMTP
* Henning Brauer [EMAIL PROTECTED] [2007-05-23 11:48]:
* Bob Beck [EMAIL PROTECTED] [2007-05-22 23:45]:
just deduced from trial and error. Also greylisting should happen at
RCPT TO, and probably not at DATA as there are some widely used MTAs
that are buggy and choke when a 4xx error is
* Renaud Allard [EMAIL PROTECTED] [2007-05-23 12:10]:
Henning Brauer wrote:
rfc 2821 specifically forbids this behaviour.
Not really.
quote
- If the verb is initially accepted and the 354 reply issued, the
DATA command should fail only if the mail transaction was
Hello,
I just used dnsstuff to test one of my domain names and it showed me
(the first time only) that my server is an openrelay, which is obviously
not true. This is due to the default behaviour of spamd of accepting
everything, even when a spamd.alloweddomains file is present. I think
Renaud Allard [EMAIL PROTECTED] writes:
I just used dnsstuff to test one of my domain names and it showed me
(the first time only) that my server is an openrelay, which is obviously
not true. This is due to the default behaviour of spamd of accepting
everything, even when
Peter N. M. Hansteen wrote:
Renaud Allard [EMAIL PROTECTED] writes:
I just used dnsstuff to test one of my domain names and it showed me
(the first time only) that my server is an openrelay, which is obviously
not true. This is due to the default behaviour of spamd of accepting
everything
that any of our servers (all spamd
protected) were on any of them.
I take this as an indication that at least the more commonly used ones
do not behave as you suspect. If other, less common ones or or pay to
use lists are more trigger happy and as a consequence offer less
accurate data than the free
never found any indication that any of our servers (all spamd
protected) were on any of them.
I take this as an indication that at least the more commonly used ones
do not behave as you suspect. If other, less common ones or or pay to
use lists are more trigger happy and as a consequence
/cvsweb.cgi/src/libexec/spamd/spamd.c#rev1.85
instance is
restarted. I know this is also a bug in Exchange, but many people use it.
As a secondary effect, sender callouts made from a remote server will
also be accepted
that's exactly why it changed from rejecting at rcpt to: stage.
http://www.openbsd.org/cgi-bin/cvsweb.cgi/src/libexec/spamd
MX, not to
the host sending the mail. I know they are somewhat broken but there is
no point in contacting the sender domain server if you want to check for
an openrelay as the from header is more than likely a fake.
You wouldn't need spamd on the address of a send-only instance..
(if mail's only
Stuart Henderson wrote:
On 2007/05/22 15:50, Renaud Allard wrote:
Stuart Henderson wrote:
You wouldn't need spamd on the address of a send-only instance..
(if mail's only submitted on 587/465 or from known address ranges, it
could just RST port 25 to the rest of the world).
Good point
Renaud Allard wrote:
I think a better solution would be for *more* people to use greylisting
implementations which do this, so that more MSexchange users will either
bother Microsoft to fix their bug, or script 'net stop smtpsvc;net start
smtpsvc' to run a few times a day so they can send
On 2007/05/22 17:12, Renaud Allard wrote:
I have only seen this when the 4xx error is sent at DATA time, not when
sent at RCPT TO.
How about: --i-dont-want-to-receive-mail-from-people-using-exchange-2003
and --i-dont-want-to-receive-mail-from-people-using-callout-verification
Those are
is broken and answers the
sending server with a 5xx when it receives a 4xx as response from the
callout. But to be sure not to delay or break callouts, MAIL FROM:
should be redirected to the real server directly. However, this is quite
tricky to do as the communication with spamd has already
I just used dnsstuff to test one of my domain names and it showed me
(the first time only) that my server is an openrelay, which is obviously
not true. This is due to the default behaviour of spamd of accepting
everything, even when a spamd.alloweddomains file is present. I think
this could
are using is just making stupid assumptions.
This was certainly not my intention to spread FUD and I am sorry if I
did. Maybe I am a little bit too paranoid. I just wanted people to share
their experiences with this.
However, there is clearly a problem with MS exchange and current spamd
Jacob Yocom-Piatt wrote:
Renaud Allard wrote:
I think a better solution would be for *more* people to use greylisting
implementations which do this, so that more MSexchange users will
either
bother Microsoft to fix their bug, or script 'net stop smtpsvc;net
start
smtpsvc' to run a few
Bob Beck wrote:
Any automated test I've ever set up for open relay, (and I run
them) as well as any sane ones I ever see test for open relay by
actually relaying a message not looking at the smtp dialoge.
You're making much ado over nothing and spreading FUD -
the tester you
Darth Lists wrote:
Unfortunately, this little MS-behaviour is very likely to be the last
straw that gets our greylisting turned off here.
Despite my logs that prove that greylisting has removed over 95% of
incoming spam before spamassassin has to deal with it, the fact that
some legitimate
just deduced from trial and error. Also greylisting should happen at
RCPT TO, and probably not at DATA as there are some widely used MTAs
that are buggy and choke when a 4xx error is sent in the DATA phase.
I've been running this at DATA for months, and not seen any
issues with it.
Bob Beck wrote:
just deduced from trial and error. Also greylisting should happen at
RCPT TO, and probably not at DATA as there are some widely used MTAs
that are buggy and choke when a 4xx error is sent in the DATA phase.
I've been running this at DATA for months, and not seen any
I manage about 30 mail servers, all using greylisting for years (not
OpenBSD spamd, but a version running in the MTA). But as I greylist at
RCPT TO, I only noticed the problem it when clamav did go down and the
server was producing a 4xx error at DATA when it should have scanned the
mail
Bob Beck wrote:
I have definately seen issues here with other implemntations,
because the 4XX code given, the XX's matter... Have you seen
this with OpenBSD spamd? (As opposed to something else..)
I have seen this with 451 errors, not on spamd but with the exact same
error code
On Sun, May 20, 2007 at 12:55:58PM +0200, Maurice Janssen wrote:
On Saturday, May 19, 2007 at 22:46:29 +0100, Jason McIntyre wrote:
On Fri, May 18, 2007 at 05:25:32PM -0500, Nick Templeton wrote:
Since when running spamd(8) in blacklisting mode requires
that spamd-setup(8) also be run
spamd version for http?
Instead of just grepping the logs
and adding to the pf tables, and blocking,
love to redirect to a fake webserver and waste
their time also
Guess I could redirect their http(s) requests to spamd,
confuse the hell out their http client.. :)
Getting tired of seeing
On Saturday, May 19, 2007 at 22:46:29 +0100, Jason McIntyre wrote:
On Fri, May 18, 2007 at 05:25:32PM -0500, Nick Templeton wrote:
Since when running spamd(8) in blacklisting mode requires
that spamd-setup(8) also be run with the -b option, should
/etc/rc (the system startup script) be modified
On Sun, May 20, 2007 at 12:55:58PM +0200, Maurice Janssen wrote:
why do you want to do this? spamd(8) says to use crontab.
Yes, but the default is once per hour. So without the -b flag to
spamd-setup in /etc/rc, the blacklisted hosts are not sent to the
spamd table in pf for quite some
On Fri, May 18, 2007 at 05:25:32PM -0500, Nick Templeton wrote:
Since when running spamd(8) in blacklisting mode requires
that spamd-setup(8) also be run with the -b option, should
/etc/rc (the system startup script) be modified with something
like I provide below?
Index: rc
Since when running spamd(8) in blacklisting mode requires
that spamd-setup(8) also be run with the -b option, should
/etc/rc (the system startup script) be modified with something
like I provide below?
Index: rc
===
RCS file: /cvs
I have two mail servers running 4.1-stable and am trying to get spamd
synchronization working between them.
During testing using a basic set of options
/usr/libexec/spamd -y nfe0 -Y nfe0 -d
in the resulting debug I see
using multicast spam sync mode (ttl 1, group 224.0.1.240, port 8025
upgraded my firewall to 4.1. The firewall runs spamd, and
redirects connections (that don't go to spamd) to a server behind the
firewall.
I modified my pf.conf per the sample in the spamd(8) man page. It's a
couple of days later, and suddenly I realize that I'm only getting mail
that's
I've just upgraded my firewall to 4.1. The firewall runs spamd, and
redirects connections (that don't go to spamd) to a server behind the
firewall.
I modified my pf.conf per the sample in the spamd(8) man page. It's a
couple of days later, and suddenly I realize that I'm only getting mail
I'm finally upgrading from 3.5 to 4.0! I use the whitelist from puremagic
and in the past 2.5 years I have also added another 10 ip addresses to
spamd whitelist because of problems with mail getting through. This week I
did tests on 3 of those ip addresses and we are 3/3 for current spamd
Thanks. 4.1 has some major changes too, so bear in mind
spamd wise it's a big change from 4.0
-Bob
* Frank Bax [EMAIL PROTECTED] [2007-04-20 08:29]:
I'm finally upgrading from 3.5 to 4.0! I use the whitelist from puremagic
and in the past 2.5 years I have also added another
Is there a place that documents the spamd differences from 4.0 to 4.1; or
am I left with detecting the differences in documentation? I see 41.htm
mentions greylist sync which I won't need (although I could see a one-time
use when migrating boxes); greytrapping sounds interesting, might try
This will set you in the right direction:
http://www.undeadly.org/cgi?action=articlesid=20070301144846
On 4/20/07, Frank Bax [EMAIL PROTECTED] wrote:
Is there a place that documents the spamd differences from 4.0 to 4.1; or
am I left with detecting the differences in documentation? I see 41
Yes, the upgrading to 4.1 page mentions this.
-Bob
* Frank Bax [EMAIL PROTECTED] [2007-04-20 12:43]:
Is there a place that documents the spamd differences from 4.0 to 4.1; or
am I left with detecting the differences in documentation? I see 41.htm
mentions greylist sync
Paolo Supino wrote:
I appriciate your straight and forward replies :-) but the world isn't
black and white and sometime you have to create work arounds to overcome
other people's crap (well most of the time).
No, in this case it is black and white. There is NO WAY to reliably fix
this
901 - 1000 of 1468 matches
Mail list logo
