We currently accept Visa, Mastercard and AMEX Over the phone and through our shopping cart. In addition we offer Google Checkout and PayPal. Please see our store pages listed in the top menus bar.

Your online order is processed through our Ceratec Inc. secure shopping card. The transaction is in US Dollars, on our US site, going through the US Autorize.net credit card center and to US banks. Your credit card information is strictly confidential and is not kept on record by our company. We are incorporated in the State of Texas since 1980. If you have any questions please call us toll free 866-546-3434.

Ceratec Inc. (EmailProfessor) distributes DataEnter, Paragon, Scan&Sort, Desknow and other products in the US and Canada. We also handle tech support for the US and Canada. You can e-mail, fax or call us.

• HelpDesk: http://support.ceratec.net/index.php
• E-mail: support@ceratec.net
• FAX: +1 (480) 287-8355
• Phone: +1 (512) 285-2620

No problem—here are the easy steps.

1. Open SMTPBeamer administration.
2. Set up the users with mailboxes as usual. Set up a mailbox info@mycompany.com.
3. Go to view and forwarding. Add forward request from Info@mycompany.com to Person 1, 2, 3.
4. Un-check the flag "Deliver to original address."
5. Add forward request for the person who wants the mail at home, too. (jdow@mycompany.com - jdow@aol.com)
6. Check the flag "Deliver to original address."

You have options—even with AOL. You can forward to a mailbox like AOL or Hotmail.

• Pros—simple and secure.
• Cons—reply's from the field show AOL return address.

You can make the mail server visible on port 80 and enable the HTTP interface on SMTPBeamer.

• Pros—return address is correct.
• Cons—just another little hole in your firewall.

You can make it visible on port 25/113.

• Pros—full access to your mail server from outside.
• Cons—we have reports that AOl and some others block port 25 (SMTP).
• Cons—more holes in the firewall.

Make it visible on port 25 only if you really need to and if you do route it over a different IP. The reason for that is that there are blacklists. Your IP address will get on there, and the subscribers to the list will block your messages in order to curb spam.

How do I handle problem domains like mail.com?

Blocking mail.com and other simple domain names take a little more work, but it's possible to do. The problem with mail.com is that the word mail can be the ending of another domain name like HOTMAIL.COM. In general, you would enter @mail.com, and that would take care of the hotmail.com problem. However, that will not block mail.com sub-domains So, to block these subdomains, you need to enter a second block ".mail.com" (note the "." before the word mail. That will block the subdomains of mail.com but will not apply to hotmail.com

Yes, you do not want to send your signature and other things like the reply to:, from and so on to the Bayes filter. Over time, these things will start mounting up to a problem.

.

Yes, XWall can relay SMTP mail. By default, out of the box the relay function is turned off. We recommend a conservative approach when enabling the relay function in XWall. In other words, be careful and understand what you are doing. You don't what to enable an unrestricted relay. Such a relay would be abused by spamers in a matter of days. Here are the relay options in XWall.

• Open relay
• Relay restricted to host names
• Relay restricted to IP addresses
• Relay for authenticated (NTLM) users
• Relay accessible via user name and password

The first three options are handled under XWall administration (Mbadmin) go->view->options->relay. If you check the first flag "ALLOW RELAY of SMTP MESSAGES," you are opening the relay to everybody. Usually, you don't want to check that flag.

The option you see checked below will allow relay from specific addresses. These addresses can be internal or external. They also can include a range. For example, to allow relay from address 192.168.1.1 through 192.168.1.254, you would enter "192.168.1." (Note: without the quotes but with the period).

XWall writes great statistical files in .csv format, which is read by most spreadsheets including Excel. In XWall configuration, go to ->view-option-statistics. You can tell XWall where you want the files to be written to. The default is the XWall folder. The SMTP blocking stats are a good idea if you use the recommended SMTP blocking.

XWall allows a number of different actions for different filters. The EmailProfessor recommends to use SMTP level blocking for filters like the spam relays. Here is the reason and some scenarios.

99% of the mail caught by the spam relays is actually spam. That leaves one message per 100 which is not. So what can we do?

You could forward all the spam with a warning. That may be a good idea for the first week to identify the good in the bad bunch. After that, there will be few, and you will send a lot of marked spam to your users. That's probably not what you want to do as a final setting.

You could send it back to the sender with an explanation why the message was returned. The "good" sender can fix the situation and knows that you did not get the message. BUT DON'T FORGET the other 99 messages are spam, and most of them have fake return addresses. They are going to bounce and bounce and bounce...You get the idea. They can tie up your systems for some time. If you really want to do that, set the retries lower (view->options->advanced).

You can forward the message to the admin., mainly YOU. Ok, let's say you have 3,000 users, and every user gets 20 spam messages a day. 3,000 x 20 = 60,000 messages waiting for you in your mailbox every day...and do the math for Monday! The option may work if you have only a small user count and want to see how things are going the first couple weeks.

In the long run, SMTP LEVEL blocking will probably be your choice. XWall simply refuses the messages if it does not pass the spam relay test. That means the message does not get into your system. But the mail server on the other end will send a non-delivery report to the original sender. If that was a "good" sender, they may contact you, and you can add them to your exclude list. The "bad" spamers—don't worry about them. They tie up the SMTP server on the other end but not your system.

1. At the command line, change to the XWall directory.
2. Type MBSERVER INSTALL

NOTE! As with all NT servers by default, they are installed as LOCALSYSTEM. If you use NT authentication to protect your SMTP relay, XWall will not be able to authenticate the user. You must change the log-on setting for the service.

1. Go to control panel and select services (NT) or admin. tools and services to 2000.
2. Locate the XWall service (mbserver).
   
3. Right click and select properties.
   
4. Click on LOG ON.
   
5. Change to domain user.
   
6. Add user and password.
   
7. Save/app.
   

Please note that as a service, you will no longer see the log entries on the screen. I recommend enabling the log features.

Sent = Sent messages
Recv = Received messages
S-O = SMTP outbound queue
S-I = SMTP inbound queue
E-O = Exchange outbound queue
E-I = Exchange inbound queue
Con = Connection count

All domains hosted on Exchange need to be listed in XWall under Admin->View->Domains on Exchange. If you do not list them, the messages will loop and receive a relay denied from XWall.

The "keep message option" goes into a fixed directory ( HIST-IN and HIST-OUT )
This is the same as in the SMTPBeamer.

They do find spam and plenty of it. We did notice that for some customers, the function seemed not to work. But a look at their log showed the problem right away. Assuming your DNS is working right, in almost every case, the firewall or proxy was to blame.

What happens is that some of these proxies pose as the sending SMTP mail server to XWall or any other SMTP receiver down the line. That means the spam relays check the address of your proxy or SMTP firewall, not the original sender. You need to allow XWall to receive the mail directly from the sending SMTP server. XWall has its own firewall features built in.

Yes, there are many others with different purposes. Below, you will find a partial list. Please note: these spam relays may or may not work for your situation. Some of the relays will take a long time to remove "Good guys" and may lead to excessive false positives.

Basic Testing
Use the following procedure to make sure that communication between the Host and IMC is working.

NOTE: Press ENTER after you type each line.
Start a Telnet session by using the following command:
telnet 125.125.0.4 25 (substituting the above IP)

If this works, you receive the following response from the IMC:
220 site.company.com Microsoft Exchange Internet Mail Connector version number of the IMC

Begin communication by typing the following command:
HELO test.company.com

You receive the following response:
250 OK

Type the following command to tell the IMC whom the message is from:
MAIL FROM:<Admin@po1.company.com>

You receive the following response:
250 OK - MAIL FROM <Admin@po1.company.com>

Type the following command to tell the IMC whom the message is to (use a valid Microsoft Exchange recipient's SMTP address).
RCPT TO:<User@Site.Domain.Com>

You receive the following response:
250 OK - Recipient <User@Site.Domain.Com>

Type the following command to tell the IMC that you are ready to send data:
DATA

You receive the following response:
354 Send data. End with CRLF.CRLF

Type the following command to add a subject line:
Subject: test message

Press ENTER two times. You will not see a response from this command.

NOTE: The two ENTER commands conform to Request for Comments (RFC) 822, which states that 822 Commands must be followed by a blank line.
Type the following command to add message body text:
This is a test message

You will not see a response from this command.
Type a period at the next blank line, and then press the ENTER key.

You receive the following response:
250 OK

Close the connection by typing the following command:
QUIT

You receive the following response:
221 closing connection

If you receive a "500 Command not recognized" error message for any of the preceding commands, it means that the IMC does not recognize what you typed because of a syntax error or invalid command.
Log on to the Microsoft Exchange client mailbox for the user you sent the message to in Step 4. If your test message is there, the inbound IMC communication is working.
If any error messages appear in the application event log, or if there are problems receiving the message, check the configuration or the communication to the host.

I found this test at a Microsoft site. http://support.microsoft.com/default.aspx?scid=kb;en-us;q153119

Is your virus scanner working?

This test sends an e-mail with the EICAR test file. This is not a virus but a test which triggers all popular virus scanners.

Are you on a RBL list?

A link to OpenRBL.org. It takes a bit getting used to, but it checks a lot of RBL's.

DSLB listing:

Check if you're listed on the DSLB spam relay

SPEWS.ORG

Test an IP address for being listed on SPWES.

Spamhaus Top 50s

A lists of the 50 worst spam sources...well, the good news is—you have XWall.

ORDB.org

Another spam relay supported by XWall

Do you have an open relay?

This test checks for an open relay on your server. If one or two tests fail, you may have a protected relay. The test may find it when trying to relay within your domain. That would be acceptable.

Paul Graham A plan for Spam

Good information on how the Bayes filter works

Online Spam Analysis Tool

Our project ESAT E-mail Spam Analysis Tool is now two weeks in the making. It will be a premier tool to tweak your XWall spam filter.