To use any of SecurityGateway's custom Sieve extensions, you must include the following require command at the top of any script in which you wish to use them:
require “securitygateway”;
Test Commands
ip
The ip test can be performed during any stage of the SMTP process (i.e. during any mail event).
•cidr—second argument is IP address or pattern to compare with client IP address. Can be exact IP address, range specified using CIDR (eg. 10.0.0.0/24 ), or wildcard pattern: ? (1 any char), * (0+ any chars), # (1+ digits) in pattern (eg. 10.*.*.* ).
Example code: if not ip :cidr "10.0.0.0/24" { greylist; }
•public—true if client IP address is not in the RFC-1918 private subnets, and not a loopback address and not a DHCP auto IP address, otherwise false (127.0.0.0/8, 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 169.254.0.0/16).
Example code: if ip “public” { greylist; }
•private—logical inverse of public.
•ssl—true if client has successfully negotiated a secure (SSL) connection
•des—true if client is a domain email server
lookup
When the lookup test can be called depends on the first argument:
•ptr—when this is the first argument, the lookup test can be performed at any time. The second argument can be a standard tagged argument or “resolves”, “resolvestoclient”, or “error”.
For example: if lookup "ptr" :matches "*.domain.com" { greylist; }.
•resolves—return true if the PTR record exists.
•resolvestoclient—returns true if the PTR record matches – that is to say the A lookup of the PTR host returns the IP address of the client.
•error—returns true if there was a temporary DNS query error.
•helo—when this is the first argument, the lookup test can only be performed in the HELO event or after. The second argument can be “resolves”, “resolvestoclient”, or “error”.
•resolves—return true if the HELO argument is a valid IP or hostname.
•resolvestoclient – returns true if the HELO argument matches – that is to say the A lookup of the HELO argument returns the IP address of the client.
•error – returns true if there was a temporary DNS query error.
•mail—when this is the first argument, the lookup test can be performed in the MAIL event or after. The second argument can be “resolves”, “resolvestoclient”, or “error”.
•resolves—return true if the MAIL FROM domain is a valid domain.
•resolvestoclient—returns true if the MAIL FROM domain matches – that is to say the A lookup of the MAIL FROM DOMAIN returns the IP address of the client.
•error—returns true if there was a temporary DNS query error.
•spf—when this is the first argument, the lookup test can be performed in the MAIL event or after. The second argument can be “pass” “fail” or “error”.
•pass—returns true if sender passes SPF, false for neutral or fail result.
•fail—returns true if sender fails SPF, false for neutral or pass result.
•error—returns true if there was an error in processing (usually DNS query error)
•rblip—when this is the first argument, the lookup test can be performed at any time. The second argument can be “all”, “any”, or “error”.
•all—returns true if client IP address passes all DNS blocklists
•any—returns true if client IP address passes any DNS blocklist.
•error—return trues if there was an error in processing (usually DNS query error)
•rblhdr—when this is the first argument, the lookup test can only be performed in the DATA event. The second argument can be “all”, “any”, or “error”.
•all—returns true if received headers passes all DNS blocklists
•any—returns true if received headers address passes any DNS blocklist.
•error—return trues if there was an error in processing (usually DNS query error)
port
The port test can be performed at any time. The one and only argument is the port number to compare with the actual port the client connected to.
Example code: if port 25 { greylist; }
auth
When the auth test can be called depends on the first argument:
•succeeded—true if authentication was successful. When this is the first argument, the auth test can be performed in the AUTH event or after.
•match—true if authentication successful and the MAIL FROM address matches the authenticated account. When this is the first argument, the auth test can be performed in the MAIL event or after.
verify
The verify test validates addresses (see: User Verification Sources). Unlike all other tests, this test is always performed, even if it is not encountered in a sieve filter. That is to say, every MAIL FROM and RCPT TO address is verified and the results cached. When the verify test can be called depends on the first argument:
•from—true if the MAIL FROM address is a valid local address. When this is the first argument, the verify test can be performed in the MAIL event or after.
•fromdomain—true if the MAIL FROM address is from a valid local domain. When this is the first argument, the verify test can be performed in the MAIL event or after.
•fail_from—true if there was an error verifying the MAIL FROM address. When this is the first argument, the verify test can be performed in the MAIL event or after.
•to—true if the RCPT TO address is a valid local address. When this is the first argument, the verify test can be performed in the RCPT event or after.
•todomain—true if the RCPT TO address is to a valid local domain. When this is the first argument, the verify test can be performed in the RCPT event or after.
•fail_to—true if there was an error verifying the RCPT TO address. When this is the first argument, the verify test can be performed in the RCPT event or after.
dkim
The dkim test checks against DomainKeys Identified Mail (DKIM) verification and can only be performed in the DATA event.
•pass—returns true if message is signed with DKIM and the signature passes verification.
•fail—return true if DKIM processing returns a hard fail. (requires SSP option)
•error—return true if there was an error in DKIM processing.
cbv
The cbv test can be performed in the MAIL event or after. Without an argument, it returns true if the MAIL FROM address passes Callback Verification.
•error—returns true if there was an error in CBV processing.
spamtotal
The spamtotal test checks against the Message Score and can be performed in any event. However, in most cases it should be run in the last filter of the DATA event so that all other filters can make their contribution to the message score.
The spamtotal test has a single argument: the threshold value. If the message score is greater than or equal to the threshold, it returns true, otherwise false.
OutbreakProtection
The OutbreakProtection test can only be performed in the DATA event. Without an argument it returns true if Outbreak Protection classifies the message as spam, virus, or bulk email.
•spam—returns true if Outbreak Protection classifies the message as spam.
•virus—returns true if Outbreak Protection classifies the message as containing a virus.
•phish—returns true if Outbreak Protection classifies the message as a phishing email.
•suspect—returns true if Outbreak Protection classifies the message as suspected spam.
•bulk—returns true if Outbreak Protection classifies the message as bulk email.
•error—returns true if there was an error in Outbreak Protection processing.
allowlisted
This test has an alias: exempt (for backwards compatibility). When this test can be performed depends on the first argument:
•all—same as no argument; returns true if client is allowlisted. This can be called in any event and will only use the information available. For example, when called in the IP event (the first event), only the allowlisted IPs and Hosts that match the PTR record will be compared.
•ip—returns true if client is listed in the IPs allowlist. Can be performed in any event.
•host—returns true if client is listed in the Hosts allowlist. The match can be either with the HELO argument or the PTR host. Can be performed in the HELO event or after.
•mail—returns true if MAIL FROM is in the Addresses allowlist. Can be performed in the MAIL event or after.
•from—returns true if From: header is in the Addresses allowlist. Can only be performed in the DATA event.
blocklisted
This test has an alias: blacklist (for backwards compatibility). The arguments and functionality are identical to the allowlist test, except the comparison is to the Blocklists.
Action Commands
error
The error command is identical to the reject command as defined in RFC 3028, except that it has 2 arguments. The first argument is the SMTP error code and the second argument is a text message. Both are sent in response to the current client command.
disconnect
The disconnect command is identical to the “error” command, except it also closes the TCP/IP socket. This is analogous to the shutdown option in MD.
greylist
The greylist command activates Greylisting.
dynamicscreen
The dynamicscreen command activates Dynamic Screening.
tarpit
The tarpit command activates Tarpitting.
sign
The sign command adds a signature header to the message. The first argument can be:
•dkim—sign the message with DKIM. The second argument is the name of the selector to use.
throttle
The throttle command activates Bandwidth Throttling. The first argument is bandwidth limit in characters per second.
ipshield
The ipshield command activates IP Shielding.
spamscore
The spamscore command adds the first argument to the current message score total of the message. See the spamtotal test.
tagheader
The tagheader command prepends a tag to a header in the message. The first argument is the header to modify. The second argument is the text to insert in the header value.
addheader
The addheader command adds a new header to the message. The first argument is the header to add and the second argument is the value.
removeheader
The removeheader command deletes a header from the message. The first argument is the header to remove.
alert
The alert command sends a note. The single argument is an email body containing from:, to:, subject: and other headers. The entire string is subject to macro expansion.
changesender
The changesender action is used to change the value of the SMTP MAIL FROM command that SecurityGateway uses when delivering a message. This could be used, for example, when an internal-only domain name is being used and must be changed when sending mail outside the domain.
Example:
require ["securitygateway", "envelope"];
if envelope :matches "From" "frank@internal.mail"
{
changesender "frank@example.com";
}
execute
•The script must be placed in the "Sieve Executable Path" directory which can be configured from Setup » System » Directories. The "execute" sieve keyword may be used as an action and a test.
•First parameter is the name of the script. .bat, .exe, and PowerShell are supported.
•The second parameter is arguments that will be passed to the process. The message_filename sieve variable is populated with the full path to the RFC822 source of the message being currently processed.
Example:
require ["securitygateway","relational","comparator-i;ascii-numeric"];
execute "Test.ps1" "-msg '${message_filename}'";
The text of the PowerShell script that will log the filename of each message processed is...
param
(
[string]$msg = ""
)
Add-Content -Path "c:\files_processed.txt" -Value $msg
Write-Host $msg
