I don't think that's gonna happen, but it would be great.
I can recommend the program "Examdiff" to do it yourself.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http:/
You know what would be great? Some way for anyone to check what
specifically what changed from version to version... Some sort of a log
of changes, or perhaps a sort of version control system that would allow
developers and non-developers alike to check each other's code. One
might call it a co
Errors in 7819, 7820 & 7821
mlog($fh,"Message-Score: $score ($reason2)" if $DoPenaltyMessage==2 &&
$status==1;
mlog($fh,"IP-Score: $score ($reason2)" if $DoPenaltyMessage==2 && $status==2;
mlog($fh,"Message/IP-Score: $score ($reason2)" if $DoPenaltyMessage==2 &&
!$status;}
--
Micheal Espinola Jr wrote:
SMTP sessions (connections if you will) are the second stage of an
SMTP e-mail transaction process , so since DoPenaltyExtreme blocks
based on the IP connection (the first stage of the process), that
would come first.
Bah... Sorry, I should have checked the GUI to
Paul Houlbrooke wrote:
Fritz Borgstedt wrote:
DoPenaltyExtreme says it blocks IPs
DoPenaltyExtremeSMTP says it blocks SMTP connections
I don't know, who?... it doesn't say. What's the point of both of these
options? Why would you want to block the IP later on if you could block
it earlier o
Fritz Borgstedt wrote:
ASSP development mailing list
> schreibt:
>> Wouldn't it be similar to have 1 setting like this, instead of 2.
>>
>> DoPenaltyExtreme
>> block early (before delaying)
>> block later (after delaying)
>> monitor
>
>
> and how do you say that you monitor early or monitor
Craig Schmitt wrote:
> DoPenaltyExtremeSMTP blocks early, based on the IP's score from previous
> SMTP sessions.
>
> DoPenaltyExtreme blocks later (after the header is done), based on the IP's
> score from previous and the current SMTP session.
>
> So, yes, both are useful as an IP might slip b
DoPenaltyExtremeSMTP blocks early, based on the IP's score from previous
SMTP sessions.
DoPenaltyExtreme blocks later (after the header is done), based on the IP's
score from previous and the current SMTP session.
So, yes, both are useful as an IP might slip by DoPenaltyExtremeSMTP because
it'
ASSP development mailing list
schreibt:
>Wouldn't it be similar to have 1 setting like this, instead of 2.
>
>DoPenaltyExtreme
> block early (before delaying)
> block later (after delaying)
> monitor
and how do you say that you monitor early or monitor later?
---
Ahh ... sorry. Working well now. :-)
On Tue, Feb 26, 2008 at 1:44 PM, Fritz Borgstedt <[EMAIL PROTECTED]> wrote:
>
> >pluto.mydomain.com:10025
>
>
> Please put the IP number! in it.
-
This SF.net email is sponsored by
Fritz Borgstedt wrote:
>> DoPenaltyExtreme says it blocks IPs
>> DoPenaltyExtremeSMTP says it blocks SMTP connections
>
>
> Both block IPs.
> One does it earlier than the other - guess who?
I don't know, who?... it doesn't say. What's the point of both of these
options? Why would you want to bl
Fritz Borgstedt wrote:
>> DoPenaltyExtreme says it blocks IPs
>> DoPenaltyExtremeSMTP says it blocks SMTP connections
>
>
> Both block IPs.
> One does it earlier than the other - guess who?
Wouldn't it be similar to have 1 setting like this, instead of 2.
DoPenaltyExtreme
block early (before
>
>DoPenaltyExtreme says it blocks IPs
>DoPenaltyExtremeSMTP says it blocks SMTP connections
Both block IPs.
One does it earlier than the other - guess who?
-
This SF.net email is sponsored by: Microsoft
Defy all challenge
>pluto.mydomain.com:10025
Please put the IP number! in it.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
__
On Tue, Feb 26, 2008 at 12:48 PM, Fritz Borgstedt <[EMAIL PROTECTED]> wrote:
> ASSP development mailing list
> schreibt:
>
> >I must be missing something obvious.
>
> what is the content of the smtpDestination field in Network Setup.
>
> The IP number! and port number of your primary SMTP MTA
Fritz Borgstedt wrote:
>> Right, but
>
>
> I do not understand your "but".
DoPenaltyExtreme says it blocks IPs
DoPenaltyExtremeSMTP says it blocks SMTP connections
Are these 2 separate options? Or does one rely on the other? The wording
is confusing to me. To me, blocking an IP and blocking a
ASSP development mailing list
schreibt:
>I must be missing something obvious.
what is the content of the smtpDestination field in Network Setup.
The IP number! and port number of your primary SMTP MTA.
-
This SF.net emai
>Right, but
I do not understand your "but".
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
Hi all
After having had great success with ASSP on Windows / Exchange I've
now installed 1.3.5 on Linux / sendmail.
Everything looks good but graylisting is simply not working at all.
EnableDelaying is checked on and I can't see anything that should be
stopping it. The log never mentions adding t
$mayRealSize should be $maxRealSize ( 2 occurrences )
#use strict "vars"; strikes again.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MR
Fritz Borgstedt wrote:
>> What is the difference between DoPenaltyExtreme and
>> DoPenaltyExtremeSMTP? One says it will block IPs, and the other says
>> it
>> will deny SMTP connections. What happens when they are both set to
>> "block", does one supersede the other? Or does DoPenaltyExtremeSMTP
>What is the difference between DoPenaltyExtreme and
>DoPenaltyExtremeSMTP? One says it will block IPs, and the other says
>it
>will deny SMTP connections. What happens when they are both set to
>"block", does one supersede the other? Or does DoPenaltyExtremeSMTP
>depend on DoPenaltyExtreme?
What is the difference between DoPenaltyExtreme and
DoPenaltyExtremeSMTP? One says it will block IPs, and the other says it
will deny SMTP connections. What happens when they are both set to
"block", does one supersede the other? Or does DoPenaltyExtremeSMTP
depend on DoPenaltyExtreme?
--
> To prevent this "exploit" (it is not a bug, it's a rarely used feature,
which you
> decided not to disable), you have to follow the tips from JP:
Thanks,
But we're both the same person ;-)
I'll let him know...
To make things clear:
UUCP-support wasn't giving a problem if sendmail was talking wi
>>To prevent this exploit from happening I need to ENABLE
>>"EnableBangPath"?
>>What will happen when support is dropped in a future release?
>>Will it then still translate or will it refuse the mail?
To prevent this "exploit" (it is not a bug, it's a rarely used feature, which
you
decided not t
>To prevent this exploit from happening I need to ENABLE
>"EnableBangPath"?
>What will happen when support is dropped in a future release?
>Will it then still translate or will it refuse the mail?
I am not discussing the expoit.
I think it should be quite clear, that EnableBangPath ENABLES the
I have disabled UUCP on my sendmail, so it will not relay to another domain,
but it will accept it as mail for itself.
http://safari.oreilly.com/1565928393/sendmail3-CHP-4-SECT-7
Don't assume UUCP support and UUCP relaying are turned off by default.
Always use the nouucp feature (FEATURE(nouucp))
To make things clear!
To prevent this exploit from happening I need to ENABLE "EnableBangPath"?
What will happen when support is dropped in a future release?
Will it then still translate or will it refuse the mail?
-Oorspronkelijk bericht-
Van: [EMAIL PROTECTED]
[mailto:[EMAIL PROTEC
28 matches
Mail list logo
