How Greylisting works

Most spamming servers will try to deliver a message to the receiving server and give up if they don't receive a quick response. This is usually an automated process by the spammer and retrying message delivery is highly unlikely and difficult to manage if they did retry. Kind of like a shotgun approach where the spammer hopes 10% of their messages reach their target and then forget about it. A "real" mail server however will retry delivery after a short period of time.

Greylisting allows you to temporarily reject an incoming session for a specified period of time. This will hopefully deter many spam servers from resending their messages.

How Greylisting works

1. Connection is made from remote server
   
2. Greylisting checks to see if the connecting IP is on the Greylisting whitelist
   
3. If the IP is on the Greylisting whitelist the connection is allowed
   
4. If the IP is not on the Greylisting whitelist, it checks to see if the IP is pending and whether it waited the specified time? If yes, allow, if not, return 451 warning message, example,
   
   451 4.7.1 This server is currently unavailable, please try later.
   
   
5. This process is repeated for all connecting IP's and may be customized as needed.
   

What is by-passed (specific to VisNetic MailServer)

Local by-passing is automatically implemented using these options:

• By-pass trusted IPs and authenticated sessions (AntiSpam - Other tab)
  
• Exclude outgoing messages from spam scanning (AntiSpam - Other tab)
  
• Local-Local by-pass filter (simply sending TO and FROM a local domain)
  
• Greylisting by-pass file ('B' button, greylist.dat file)
  

If local by-passes are not applied users will get a temporary 4.5.1 error in their mail client and will be allowed to send only after the specified period.

Greylisting descriptions (specific to VisNetic MailServer)

Active

Check this option to enable Greylisting.

Allow new authorization after (Seconds)

Specify the amount of time that incoming connections should be temporarily rejected.

Delete pending sessions after (Hour)

Specify the amount of time after which any "pending" IP addresses are deleted from the database.

Note: "Pending" addresses are addresses which have tried to connect and have been rejected by Greylisting.

Delete authorized sessions after (Days)

Specify the number of days that an authorized IP address is held in the database.

Note: A value of 0 means authorized IP addresses will never be deleted. "Authorized" addresses are addresses that were rejected by Greylisting, but then accepted at a later retry from the same address.

Greylisting mode

Select the data that should be stored in the Greylisting database.

There are four possible modes:

• Sender - The e-mail address of the person sending the e-mail.
  
• IP - The IP address of the machine sending the e-mail.
  
• Sender and IP - Both of the above.
  
• IP+HELO/EHLO - IP address of the machine sending the e-mail and hostname sent in the HELO/EHLO command at the beginning of the SMTP session.

Note: Sender is the recommended mode since multiple IP systems, such as gmail, may retry the connection from a different IP addresses, and this would in turn be greylisted.

SMTP Response

You can optionally specify a custom SMTP response used when a connection is rejected by Greylisting. Your custom response will appear after '451 4.7.1'. If left blank the default SMTP response message is returned.

By-pass file (greylist.dat)

Press the B button to edit a Greylisting by-pass file, where you can specify senders, domains, and IP address ranges that will not be Greylisted. Examples are given within the file.

Grandstream GXW-4104 4-Port FXO Giveaway

Anyone interested in a Grandstream GXW-4104 4-Port FXO Gateway Giveaway should head over to our 3CX Blog for signup details.

Registering to win is easy - just visit the 3CX VoIP IP PBX Phone System Facebook page located here, and scroll to the bottom "Discussion Board" (just below the "wall"). Post a comment to the topic "My Favorite 3CX Feature or Benefit" - and you are eligible to win! We'll keep this open until the end of February and then award the lucky winner. Oh, one other thing - you must become a "fan" of the page also to be eligible for the drawing. If you are not already a Facebook member, you can sign up for free from the 3CX Facebook page.

How to use SysLog Server Daemon - Kiwi

On occasion you might need the ability to obtain logging from hardware devices on your network, such as your router, sip phones, access points, etc... Most of these devices do not include real-time logging that can be used to help troubleshoot problems because of limitations in the device to store log entries to internal memory.

What most of them do have is the ability to send logs to a SysLog Daemon, such as Kiwi SysLog Server. What a SysLog Server does is listen for incoming UDP or TCP connections from devices that "speak" the SysLog language and writes the logs to the SysLog server drive. This extends the devices ability to write logs by sending the logging information across the network and offloading the logs to another computer. Here's an example of how to setup Sys Logging with SIP phone Snom 370 and Kiwi SysLog Server.

1. Download the Kiwi SysLog Server

2. Install the Kiwi SysLog server

3. Configure the SysLog Server - the only real configuration required is to decide whether to use TCP or UDP. My recommendation is to use UDP, the default UDP port is 514. Open Kiwi SysLog Server and select File, Setup, then under Inputs select UDP. Enable Listen for UDP Syslog messages and set Data encoding to System, and save the changes.

4. Your SysLog Server should be listening on UDP port 514 and waiting for incoming connections.

NOTE: If you have a firewall installed on your computer you must allow incoming connections to Kiwi.

Couple of tips before we setup the Snom 370 phone.

The phone will need to send to the IP address of the computer you installed Kiwi SysLog Server on, to find your IP open a DOS window and type ipconfig, the IP will be listed under your Ethernet adapter, for example, 192.168.0.5. To determine if Kiwi SysLog Server is listening on UDP port 514 type netstat -an and you should see an entry under UDP protocol for 0.0.0.0:514.

5. Setup your device (Snom 370). Login to the Web admin for your phone, select Advanced and then the Network tab. Near the bottom is a field for your SysLog server, enter 192.168.0.5 (your computers IP). Save the changes and reboot the phone. After a reboot your phone will write logs to your SysLog server.