Hello,

I use autoreplies in MERCURY using an AREPLY.CFG file. With the actual release of MERCURY,we can exclude some autoreplies by managing a file named AREPLY.KFS. I think it could be very interesting to have another file which list all approved e-mail for autoreplies.

With this new file: 

Imagine a simple situation, you are in holliday you want to set an autoreply on your account only for known contacts, so you have just to export you adress book in text format select the Email column and past it in the file.

Another idea could be to support wildcards in AREPLY.KFS (and the new rule file) for example rule like : "*@pipio.com"

Greeting

Francoy 

Well, it's in the help.

Send an unformatted email to maiser@..... 

with the text body like 

Add <listname> <user> <personal name>
Add <listname> <user> <personal name>
Add <listname> <user> <personal name>

Hi Richard

I use both Mercury and Pegasus Mail in a high school, I've about 1300 users. Each year about 1/3rd leave the school, 1/3rd are new ones and the last 1/3rd change their group (as they change their grad).

I created some scripts to manage those change in Mercury/Pmail and also in W2k3 AD, all scripts are in vbs. It's quite simple. You're right some scripts should be given to help to manage Mercury/PM.

Last think : a domain mailbox is not only *ONE* user it's multiple users so you've to pay for the right license.

Regards

Worth giving this another kick [;)]

@fojtik 

Yes, I already use dos command format, sometimes it is still not short enough.  In these cases I resort to .bat files.  However, this is the 'Suggestion & Wishlist' forum, which is why I am posting a request for a feature, which in my opinion, should have been implemented years ago.

I'm afraid there seems to be some problems with the online license purchase system for Mercury.

The first (technical) one is that the PayPal page didn't at all load in Firefox, I had to start again using MSIE. The second (legal) one is that the receipts received from PayPal aren't acceptable business documents for the transaction. The full name and address of the seller isn't included, nor the name of the buyer, nor a specification of what kind of license has been purchased.

/Rolf
 

Update:

There is an email sent out at a later time (in this case 2 days after the payment) with a download link, that gives the opportunity to print an invoice. This does presumably take care of the legal problem.

Hi all

Many thanks for your support, sorry my silence during last days... I see you understand my wish, i want a private relay server and I can 't use IP filter adress because some connections will come from internet and the IP adress could be xxx.xxx.xxx.xxx.

Yesterday i found another way:

    -Close all port on my internet firewall except the incoming port 80

    -Install IMAP support in MERCURY

    -Install Appache-PHP server with squirreimail on the mercury server

So when an internet (autorised) user need to use my SMTP server to relaying an mail, he can do it using the webmail interface.

Francoy 

[quote user="rshouts"] I resolved the problem by creating in our internal DNS server a forward lookup zone for the domain in the other mail server and added all of the A and MX records with internal addresses.  Mercury now sends directly to the other mail server via the internal network.[/quote]

Interesting solution, & I agree to the wish of either a separate config file, to allow direct host forwarding - would prefer not to mess up the hosts file.

[quote user="Thomas R. Stephenson"]Not really sure how much good they will do for most people.[/quote]You could say the same thing about any proposed feature; that doesn't mean the feature lacks value.  In any event, I think it would be VERY useful to at least be able to apply transaction-level filtering to ANY header, even if we must (for now) forego examination of the actual message body.

[quote]The transaction filters generally work on the SMTP mail headers[/quote]But, as it stands now, only a small predefined subset of them.  That's the problem.

[quote]Working on the body of the RFC 2822 message looking for headers means are are in the process of downloading the mail already and normally you would not issue the 500 series error message in this stage of the message delivery.[/quote]I think that in place of "normally", the term "traditionally" is the better fit -- but the traditional approach does not really serve us very well in the here and now.

[quote]I know it's legal to do it this way but it's messy.[/quote]So what's your alternative?  The point here is, issuing a "250 Data received OK" and then realizing you've got a spam/virus/whatever on your hands is even messier.  As explained in my original post, that leaves you on the horns of a no-win dilemma.  No matter what you do at that point, it's going to be wrong in some way -- perhaps seriously wrong in the case of "backscattered" spam (or worse, viruses).  The only truly clean solution is to not "accept" that mail in the first place -- which brings us right back to doing ALL the tests before issuing the "250 ...".

[quote]FWIW, I've got Mercury/32 running on Linux (Ubuntu v7.10 with Wine v0.9.50) without any problems at all.  I am running Clamwall, Spamwall and Graywall as well.[/quote]Cool!  That definitely give me some encouragement; but it doesn't really address the primary issue I posted about.

[quote user="tBB"]Spamhalter doesn't strip images, it just does a Bayesian analysis of the image characteristics. Stripping inline images altogether or converting them to attachments also breaks many commercial (legal) newsletters etc. If you use Mercury's content control you can use something like this

IF BODY MATCHES "/b*src[=3D ]+[\"c]+id:*" WEIGHT 50 Tag "BODY: Contains Inline Image"

to give mails containing inline images additional spam points.

Best regards

Nico
[/quote]

I found that this does a great job in helping me detect the

"enhancement & meds type" image spam. I use it in a CC rule set that gives

SpamHalter 50% trigger value and this the other 50% and

it seems to work very well. Thanks much!

In fact using -1 as the age of a message DOES detect future dated emails in Pegasus so a similar feature in Mercury would be very useful.  

 Having said that the popularity of future dating by spammers seems to be on the wane a bit.
 

Hi

This is something I've already asked for.

Hopefully David will consider it ! [:D]

Hi Peter,

it's Regular Expressions. Sorry for using it.

A KB article with as much as possible examples was very much appreciated. Especially as regular expressions in different portions of the program seem to behave different and the help file does not cover it (enough).
Mostly I think about information what part of information is evaluated at all (like the "SMTP TO:me@domain.comCRLF" in transaction filtering), where to derive it from and which regular expressions (or metacharacters) are supported at which point.
Example: H, "[HE][HE]LO lappy/w/w", S, "my machine" works in transaction filtering, H, "/x[HE][HE]LO lappy", S, "Lappy" does not (from help, section content control: "/x Toggle "ignore-non-alpha" mode - ignore non alphanumeric characters".

Thank you, Rainer

[quote user="David Harris"]
You are welcome to suggest extensions to the existing regex engine, though - I will consider any reasonable request if it is feasible and can be done without creating significant backwards-compatibility problems.
[/quote]

I suggest this:

 Cheers!

Properly learned Spamhalter is very bipolar due used technology. Nearly all classifications have 0% or 100% result. Other results are only marginal or extreme cases.

Spamhalter is designed to decide if message is spam or not. It cannot produce result like 'it is maybe spam'. So, it have just one level - if classification is higher - message is spam. This configured level is essencial for corrections and training functions, becasue corrections and learning process working with this level value.

So, do not filter spam by your spam probability level. Allways use leve configured in Spamhalter. If classification is higher, then Spamhalter add "Spam detected" additional header what is designed for filtering purpose.

By this level Spamhalter knows itself, if message is spam or not, and this information is used for self-learning. If message is corrected, then this level is used for check, if correction is sucessfull or not.

If you are adding your individual levels by percentage instead of "spam detected" headers, then all of this cannot work properly. Please, use only configured spam level. Spamhalter is really sure if message is spam or not. There is not place for 'maybe'. And if human found error, then made correction immediately.
 

I know your post is old, but just wanted to add my voice that I think this would be a killer feature to be added to graywall.  Allowing any mail to the honeypot address address to get through.  That way those messages could be tagged as spam at least 15 minutes before they are sent to other users. 

The way it is now if a spam message is being sent to a bunch of users there is no guarantee that it will be sent to the honeypot address first.  It may in fact go to all the other users before ever being sent to the honeypot address.

Oh yes - I forgot about that small detail. BLAT is set to use our ISP's SMTP server for sending. I set the "outgoing" address as noreply@treverton.co.za and, of course, that address does not exist. I do see the SMTP server trying to deliver all of the failure messages to Mercury, but of course, they are never accepted.

The message that gets sent is:

Treverton has a very strict policy on unsolicited commercial email or SPAM.
Due to some wording or other part of your message to a user at treverton.co.za, your message was classified as SPAM and deleted.
You may resend your message with the code “jKx58Fq” appearing somewhere in the Subject line in order to ensure delivery.
You may also contact the IT Manager at postmaster@treverton.co.za, remembering to place the code “jKx58Fq" in the Subject line, and ask for your address to be whitelisted.

The other detail I omitted to mention: When my script parses a messages classified as SPAM but cannot find a local addressee in the headers, the message is saved in an "Orphans" folder. About 10 messages end up there every day, mostly "lottery winners" and "419" letters. Maybe 1 or 2 per day are send via a mailing list and I then have to go to the MercuryS logs and check the date and time and find out who the message was intended for. I then move the messages from the Orphans folder to the user's mail folder and add the sender to the whitelist.

> Yes I have but AJAX is not the only way to do things.

Right now it's the only way to avoid to reload an entire page every time you click somewhere. And it is done in JavaScript. And even if you don't use AJAX if you want a modern looking web page you will end up writing a lot of JavaScript. HTML itself is no longer enough.

> if there is no need for anything more than the stdin/stdout redirection then anything more is a moot point. 

Never said that CGI can't work - just that it's being phased out due to its shortcomings. You can code the application of tomorrow, or that of yesterday.

> Ok, I see you want to be picky.

No, I am just correct. That's science - you can be correct or wrong, not "picky". Therefore I have no misconception about what is needed and what is not.

> Now to address the subject of dll files. As of Windows 2000,  dll files once loaded stay in memory until the system is rebooted,

Again, not true.

> HKEY_LOCAL_MACHINE > Software > Microsoft > Windows > CurrentVersion > Explorer > AlwaysUnloadDLL

That's just avoid the "cache time" Windows Explorer uses when an application exits and its dll are unloaded - as long no other application uses them. That's to avoid to reload them from disk if the next app needs them. Ask yourself why this key is not the default if so useful...

>. You cannot tax 486 DX2 66 on a T1 with NT4 running, with todays computers....

Don't know where you live, but I can easily overwhelm a P4 with Windows 2003 with the bandwith and users available here.

> So you are implying that I cannot write a webmail system that is useful and should use an existing package. 

No, I am just implying that your foundations are probably wrong, or obsolete. Feel free to write your own, but I suggest you to compare yours with those already available, and ask yourself why someone should use yours instead of the others.

> Because I want to. 

Good luck. Bidirectional synchronization is always a nightmare, believe me. You are just reimplmenting the wheel, adding more complexity and the need of more resources, with no benefits. But you're the kind of guy who needs to hit the wall to acknowledge it's there.

Then feel free to insult me when you're unable to support you claims with facts.

Very useful, thanks. 

Perhaps using the existing add a block of text tool as a basis allow administrators to set up a logo and effectively company wide signature for all outgoing email.   In our case we would use the current disclaimer text along with company contact information and our logo.