Community Discussions and Support
Where is GrayWall.pdf?

I see that it is now available as a download:

 http://www.ararat.cz/download/graywall.pdf

<p>I see that it is now available as a download:</p><p> http://www.ararat.cz/download/graywall.pdf</p>

Hi all,

 

Just upgraded from Mercury/32 4.01b to  4.51 w/ success.  Thank you, David!.

PopfileD 1.22.0 is working. I can't found the Graywall.pdf file. Someone can

point me at it?.

 

TIA.

 

Best regards.

 

Gonzalo López Menéndez.

Candás - Asturias (Spain). 

 
<DIV>Hi all,</DIV> <DIV> </DIV> <DIV>Just upgraded from Mercury/32 4.01b to  4.51 w/ success.  Thank you, David!. </DIV> <DIV>PopfileD 1.22.0 is working. <STRONG>I can't found the Graywall.pdf file</STRONG>. Someone can </DIV> <DIV>point me at it?.</DIV> <DIV> </DIV> <DIV>TIA.</DIV> <DIV> </DIV> <DIV>Best regards.</DIV> <DIV> </DIV> <DIV>Gonzalo López Menéndez.</DIV> <DIV>Candás - Asturias (Spain). </DIV> <DIV> </DIV>

[quote user="GLM"]

Hi all, 

Just upgraded from Mercury/32 4.01b to  4.51 w/ success.  Thank you, David!.

PopfileD 1.22.0 is working. I can't found the Graywall.pdf file. Someone can

point me at it?.

TIA.

Best regards. 

Gonzalo López Menéndez.

Candás - Asturias (Spain). 

[/quote]

I was informed that it is not yet written. So it's not available at all. Perhaps someday.....

 

[quote user="GLM"] <div>Hi all, </div> <div>Just upgraded from Mercury/32 4.01b to  4.51 w/ success.  Thank you, David!. </div> <div>PopfileD 1.22.0 is working. <b>I can't found the Graywall.pdf file</b>. Someone can </div> <div>point me at it?.</div> <div>TIA.</div> <div>Best regards. </div> <div>Gonzalo López Menéndez.</div> <div>Candás - Asturias (Spain). </div><p> [/quote]</p><p>I was informed that it is not yet written. So it's not available at all. Perhaps someday.....</p><p> </p>

-- Han van den Bogaerde - support@vandenbogaerde.net Member of Pegasus Mail Support Group. My own Pegasus Mail related web information: http://www.vandenbogaerde.net/pegasusmail/

Thank you for your responde.

 

I am looking for some documentation about GrayWall, in order to deploy it. I understand most of the parameters in the plug-in configuration, but I need to clarify the meaning of some of them.

 

The link under the Ararat logo (http://www.ararat.cz/eng/show.php?graywall) in the GrayWall configuration does not link to anything related to GrayWall. I am unable to find any reference to GrayWall in www.ararat.cz web site.

 

Thank you again.

 

Best regards.

Gonzalo López Menéndez

Candás - Asturias (Spain)

 

 
<DIV>Thank you for your responde. </DIV> <DIV> </DIV> <DIV>I am looking for some documentation about GrayWall, in order to deploy it. I understand most of the parameters in the plug-in configuration, but I need to clarify the meaning of some of them. </DIV> <DIV> </DIV> <DIV>The link under the Ararat logo (<A href="http://www.ararat.cz/eng/show.php?graywall">http://www.ararat.cz/eng/show.php?graywall</A>) in the GrayWall configuration does not link to anything related to GrayWall. I am unable to find any reference to GrayWall in <A href="http://www.ararat.cz/">www.ararat.cz</A> web site. </DIV> <DIV> </DIV> <DIV>Thank you again.</DIV> <DIV> </DIV> <DIV>Best regards.</DIV> <DIV>Gonzalo López Menéndez </DIV> <DIV>Candás - Asturias (Spain)</DIV> <DIV> </DIV> <DIV> </DIV>

If you ask the questions, we'll try to answer them or get to Lukas to get them answered for you.  GrayWall has been the single best tool I've implemented in reducing spam from even making it into my system at all.

If you ask the questions, we'll try to answer them or get to Lukas to get them answered for you.  GrayWall has been the single best tool I've implemented in reducing spam from even making it into my system at all.

Thank you for your help.

 

Can you please elaborate on the following settings?

 

-Unlock request expiration time in minutes

-Successful unlock expiration time in minutes

 

TIA

 

Regards,

Gonzalo López Menéndez

Candás - Asturias (Spain)

 
<DIV>Thank you for your help.</DIV> <DIV> </DIV> <DIV>Can you please elaborate on the following settings?</DIV> <DIV> </DIV> <DIV>-Unlock request expiration time in minutes</DIV> <DIV>-Successful unlock expiration time in minutes</DIV> <DIV> </DIV> <DIV>TIA</DIV> <DIV> </DIV> <DIV>Regards,</DIV> <DIV>Gonzalo López Menéndez</DIV> <DIV>Candás - Asturias (Spain)</DIV> <DIV> </DIV>

[quote user="GLM"]

Can you please elaborate on the following settings?

 

-Unlock request expiration time in minutes[/quote]

 
 This is how long you will allow the sender to retry the email in order to be "unlocked" and allowed to resend.  If you set it at 1440, the sender would need to retry within 24 hours in order for the second attempt to be acknowledged as a followup to the original graylisting.  If the second attempt is greater than 1440 minutes, the cycle would start as if new.  Most retries are within 60 minutes, if not within 10.
 
[quote user="GLM"]
-Successful unlock expiration time in minutes[/quote]
 
This means once the sender successfully unlocks the graylisting, how many minutes between successive attempts do you allow in order for the unlock to remain.  For example, if you set it at 28 days (40320 minutes), a sender would need to send mail at least once in 28 days in order for the graylist unlock to not expire.  If they send email every week, it won't expire at all.  It they don't send any email for more than 28 days, the graylist process for that sender would start new the next time they send email.
 
Hope that helps. 

 

 

[quote user="GLM"]<div>Can you please elaborate on the following settings?</div> <div> </div> <div>-Unlock request expiration time in minutes[/quote]</div> <div> </div><div> This is how long you will allow the sender to retry the email in order to be "unlocked" and allowed to resend.  If you set it at 1440, the sender would need to retry within 24 hours in order for the second attempt to be acknowledged as a followup to the original graylisting.  If the second attempt is greater than 1440 minutes, the cycle would start as if new.  Most retries are within 60 minutes, if not within 10. </div><div> </div><div>[quote user="GLM"] </div><div>-Successful unlock expiration time in minutes[/quote]</div><div> </div><div>This means once the sender successfully unlocks the graylisting, how many minutes between successive attempts do you allow in order for the unlock to remain.  For example, if you set it at 28 days (40320 minutes), a sender would need to send mail at least once in 28 days in order for the graylist unlock to not expire.  If they send email every week, it won't expire at all.  It they don't send any email for more than 28 days, the graylist process for that sender would start new the next time they send email. </div><div> </div><div>Hope that helps. </div><p> </p><p> </p>

Thank you, RoryK.

 

I have now a more clear comprehension of how GrayWall works.

 

Best whises.

 

Gonzalo López Menéndez

Candás - Asturias (Spain)

 
<DIV>Thank you, RoryK.</DIV> <DIV> </DIV> <DIV>I have now a more clear comprehension of how GrayWall works.</DIV> <DIV> </DIV> <DIV>Best whises.</DIV> <DIV> </DIV> <DIV>Gonzalo López Menéndez</DIV> <DIV>Candás - Asturias (Spain)</DIV> <DIV> </DIV>

Why is the Minimum retry time for unlock in minutes? defaulted to 10 minutes?  Wouldn't it be better to set it at 1 minute?  Also, why would you want a Successrul unlock to expire, ever?  Wouldn't it be better to allow an unlocked email address to remain unlocked forever?

 Thanks
 

<p>Why is the Minimum retry time for unlock in minutes? defaulted to 10 minutes?  Wouldn't it be better to set it at 1 minute?  Also, why would you want a Successrul unlock to expire, ever?  Wouldn't it be better to allow an unlocked email address to remain unlocked forever?</p><p> Thanks  </p>

[quote user="MikePreston"]

Why is the Minimum retry time for unlock in minutes? defaulted to 10 minutes?  Wouldn't it be better to set it at 1 minute?[/quote]

Why not use minutes? Is this a complaint?

You should feel free to change it to a time interval with which you are comfortable.  I use 5 minutes.  But 10 minutes works fine also.  Would 1 minute work?  Probably less well than 5 or 10, but I really haven't studied it well enough to determine.  But, 5 minutes is sufficient in my environment.

[quote]  Also, why would you want a Successrul unlock to expire, ever?  Wouldn't it be better to allow an unlocked email address to remain unlocked forever?[/quote]

 
If someone isn't sending  you any email, why shouldn't it expire at some point?  If there is an unlock and that person regularly sends you email, it won't expire.

[quote user="MikePreston"]<p>Why is the Minimum retry time for unlock in minutes? defaulted to 10 minutes?  Wouldn't it be better to set it at 1 minute?[/quote]</p><p>Why not use minutes? Is this a complaint?</p><p>You should feel free to change it to a time interval with which you are comfortable.  I use 5 minutes.  But 10 minutes works fine also.  Would 1 minute work?  Probably less well than 5 or 10, but I really haven't studied it well enough to determine.  But, 5 minutes is sufficient in my environment. </p><p>[quote]  Also, why would you want a Successrul unlock to expire, ever?  Wouldn't it be better to allow an unlocked email address to remain unlocked forever?[/quote]</p><p>  If someone isn't sending  you any email, why shouldn't it expire at some point?  If there is an unlock and that person regularly sends you email, it won't expire. </p>

[quote user="roryk"]

Why not use minutes? Is this a

complaint?[/quote]Not at all.  Just trying to understand the reasoning

behind the default settings. 

[quote user="roryk"]You should feel

free to change it to a time interval with which you are comfortable.  I

use 5 minutes.  But 10 minutes works fine also.  Would 1 minute work? 

Probably less well than 5 or 10, but I really haven't studied it well

enough to determine.  But, 5 minutes is sufficient in my

environment.[/quote]Well, this goes to the heart of my question.  I

don't understand why one might be better than the other.  It seems we

are making an assumption that a spammer will not send through a message

from the same address within a specific window of time, but that a

non-spammer will.  Our job is to define that window so that the

non-spammer's response fits in there, but the spammer won't "find" the

window and exploit it.  Do I have that right?  If so, I can understand

why you would want a long enough "minimum retry time for unlock" so

that the spammer doesn't fit within the window merely by sending two

messages to each address the first of which is caught by GW and the

second of which serves to unlock GW.  But the thing I'm trying to get a

handle on is what is the expectation for mail servers legitimately

turning around and re-trying a rejected message?  Is that something

that each individual mail server sets differently?  Is there an

industry standard?  I've read the comments so far and I understand that

most retries take place within 60 minutes.

[quote]  Also, why

would you want a Successrul unlock to expire, ever?  Wouldn't it be

better to allow an unlocked email address to remain unlocked

forever?[/quote]

[quote user="roryk"]If someone isn't sending 

you any email, why shouldn't it expire at some point?  If there is an

unlock and that person regularly sends you email, it won't

expire.[/quote][/quote]When you are a service provider, if one of your

clients' employees send you email, you want that email address unlocked

forever and ever.  There is absolutely no reason to have them suffer

through another "qualification" process even if it is two years (or

more!) since they last sent you an email.

Thanks for the information.

I'm

thinking of writing a program that allows folks an easy method of

moving from graywalling to whitelisting.  Since gwexlist.txt is nothing

more than a text file, it should be a simple matter to write a program

that will take an email message addressed to an alias of some choosing

(for example: addtowhitelistx994323@mydomain.com) formatted to have one

entry per line (as one would expect in gwexlist.txt) and:

 a) first see if each entry in the email already exists within gwexlist.txt

b) if it doesn't exist add it to it

Then

all I have to do is get in the habit of sending mail to that particular

alias. Perhaps a permanent bcc: would do that trick.

My only

concern is that if Mercury is processing against gwexlist.txt at the

same moment that my program is modifying it, will it cause Mercury to

crash?  I guess I'll find out.
 


 

[quote user="roryk"]<p>Why not use minutes? Is this a complaint?[/quote]Not at all.  Just trying to understand the reasoning behind the default settings. </p><p>[quote user="roryk"]You should feel free to change it to a time interval with which you are comfortable.  I use 5 minutes.  But 10 minutes works fine also.  Would 1 minute work?  Probably less well than 5 or 10, but I really haven't studied it well enough to determine.  But, 5 minutes is sufficient in my environment.[/quote]Well, this goes to the heart of my question.  I don't understand why one might be better than the other.  It seems we are making an assumption that a spammer will not send through a message from the same address within a specific window of time, but that a non-spammer will.  Our job is to define that window so that the non-spammer's response fits in there, but the spammer won't "find" the window and exploit it.  Do I have that right?  If so, I can understand why you would want a long enough "minimum retry time for unlock" so that the spammer doesn't fit within the window merely by sending two messages to each address the first of which is caught by GW and the second of which serves to unlock GW.  But the thing I'm trying to get a handle on is what is the expectation for mail servers legitimately turning around and re-trying a rejected message?  Is that something that each individual mail server sets differently?  Is there an industry standard?  I've read the comments so far and I understand that most retries take place within 60 minutes. </p><p>[quote]  Also, why would you want a Successrul unlock to expire, ever?  Wouldn't it be better to allow an unlocked email address to remain unlocked forever?[/quote]</p><p>[quote user="roryk"]If someone isn't sending  you any email, why shouldn't it expire at some point?  If there is an unlock and that person regularly sends you email, it won't expire.[/quote][/quote]When you are a service provider, if one of your clients' employees send you email, you want that email address unlocked forever and ever.  There is absolutely no reason to have them suffer through another "qualification" process even if it is two years (or more!) since they last sent you an email.</p><p>Thanks for the information.</p><p>I'm thinking of writing a program that allows folks an easy method of moving from graywalling to whitelisting.  Since gwexlist.txt is nothing more than a text file, it should be a simple matter to write a program that will take an email message addressed to an alias of some choosing (for example: addtowhitelistx994323@mydomain.com) formatted to have one entry per line (as one would expect in gwexlist.txt) and:</p><p> a) first see if each entry in the email already exists within gwexlist.txt</p><p>b) if it doesn't exist add it to it</p><p>Then all I have to do is get in the habit of sending mail to that particular alias. Perhaps a permanent bcc: would do that trick. </p><p>My only concern is that if Mercury is processing against gwexlist.txt at the same moment that my program is modifying it, will it cause Mercury to crash?  I guess I'll find out.  </p><p>  </p>

[quote user="MikePreston"][quote user="roryk"]

Why not use minutes? Is this a

complaint?[/quote]Not at all.  Just trying to understand the reasoning

behind the default settings. 

[quote user="roryk"]You should feel

free to change it to a time interval with which you are comfortable.  I

use 5 minutes.  But 10 minutes works fine also.  Would 1 minute work? 

Probably less well than 5 or 10, but I really haven't studied it well

enough to determine.  But, 5 minutes is sufficient in my

environment.[/quote]Well, this goes to the heart of my question.  I

don't understand why one might be better than the other.  It seems we

are making an assumption that a spammer will not send through a message

from the same address within a specific window of time, but that a

non-spammer will.  Our job is to define that window so that the

non-spammer's response fits in there, but the spammer won't "find" the

window and exploit it.  Do I have that right?  If so, I can understand

why you would want a long enough "minimum retry time for unlock" so

that the spammer doesn't fit within the window merely by sending two

messages to each address the first of which is caught by GW and the

second of which serves to unlock GW.  But the thing I'm trying to get a

handle on is what is the expectation for mail servers legitimately

turning around and re-trying a rejected message?  Is that something

that each individual mail server sets differently?  Is there an

industry standard?  I've read the comments so far and I understand that

most retries take place within 60 minutes.[/quote]

 There is no standard that I know of.
 

[quote user="MikePreston"]When you are a service provider, if one of your

clients' employees send you email, you want that email address unlocked

forever and ever.  There is absolutely no reason to have them suffer

through another "qualification" process even if it is two years (or

more!) since they last sent you an email.[/quote]

 "Suffer"?  That is a bit dramatic in my opinion.  The qualification process just happens, no one is even aware it is going on.  No intervention is necessary and certainly mail servers go off-line all the time resulting in similar small delays to delivery of email.


[quote user="MikePreston"][quote user="roryk"]<p>Why not use minutes? Is this a complaint?[/quote]Not at all.  Just trying to understand the reasoning behind the default settings. </p><p>[quote user="roryk"]You should feel free to change it to a time interval with which you are comfortable.  I use 5 minutes.  But 10 minutes works fine also.  Would 1 minute work?  Probably less well than 5 or 10, but I really haven't studied it well enough to determine.  But, 5 minutes is sufficient in my environment.[/quote]Well, this goes to the heart of my question.  I don't understand why one might be better than the other.  It seems we are making an assumption that a spammer will not send through a message from the same address within a specific window of time, but that a non-spammer will.  Our job is to define that window so that the non-spammer's response fits in there, but the spammer won't "find" the window and exploit it.  Do I have that right?  If so, I can understand why you would want a long enough "minimum retry time for unlock" so that the spammer doesn't fit within the window merely by sending two messages to each address the first of which is caught by GW and the second of which serves to unlock GW.  But the thing I'm trying to get a handle on is what is the expectation for mail servers legitimately turning around and re-trying a rejected message?  Is that something that each individual mail server sets differently?  Is there an industry standard?  I've read the comments so far and I understand that most retries take place within 60 minutes.[/quote]</p><p> There is no standard that I know of.  </p><p>[quote user="MikePreston"]When you are a service provider, if one of your clients' employees send you email, you want that email address unlocked forever and ever.  There is absolutely no reason to have them suffer through another "qualification" process even if it is two years (or more!) since they last sent you an email.[/quote]</p><p> "Suffer"?  That is a bit dramatic in my opinion.  The qualification process just happens, no one is even aware it is going on.  No intervention is necessary and certainly mail servers go off-line all the time resulting in similar small delays to delivery of email. </p>

Thanks for the reply.  I think I understand the issues.

In my world, if a client is trying to send me an email (and for this purpose, I am thinking of that employee who hasn't sent me an email in 2 years) and I'm waiting at this end to get it, if he presses "send" and then it goes into the authentication loop as defined by graywall, the word "suffer" is precisely correct.  From their perspective, they are an existing client and they sent me email from that same email address once, why shouldn't it work again?  Why should their email have to wait for some unspecified period of time (the retry time associated with their server, which they probably don't even have a clue how it is set)?

This is NOT a complaint about graywall.  I think it is GREAT.  I just want to make sure I implement it properly and understand its ramifications.

I think this screams for a solution that automatically adds addresses to the gwexlist.txt file in some fashion. I'll start to work on that.

Thanks again.
 

<p>Thanks for the reply.  I think I understand the issues.</p><p>In my world, if a client is trying to send me an email (and for this purpose, I am thinking of that employee who hasn't sent me an email in 2 years) and I'm waiting at this end to get it, if he presses "send" and then it goes into the authentication loop as defined by graywall, the word "suffer" is precisely correct.  From their perspective, they are an existing client and they sent me email from that same email address once, why shouldn't it work again?  Why should their email have to wait for some unspecified period of time (the retry time associated with their server, which they probably don't even have a clue how it is set)?</p><p>This is NOT a complaint about graywall.  I think it is GREAT.  I just want to make sure I implement it properly and understand its ramifications.</p><p>I think this screams for a solution that automatically adds addresses to the gwexlist.txt file in some fashion. I'll start to work on that.</p><p>Thanks again.  </p>
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft