Whitelist domain (do not mark as spam)

[FHolzer 0]

Hi,

i set up a whitelist via user_specific_configuration (user_config = "esets_smtp_spec.cfg")

The `esets_smtp_spec.cfg` looks like this
 

[black-list]
action_av = "reject" 

[white-list]
action_av = "accept"
action_as = "accept"

[|sndrname1@sndrdomain1.com]
parent_id = "white-list"

 

is there a wildcard way for whitelisting the whole domain?
Will Something like this work? :
 

[|sndrdomain1.com]
parent_id = "white-list"

also - the help page is referring to "For esets_smtp, refer to the esets_smtp(1) man page."
Where can i find this man page online?

sincerly,
Franz

[J.J. 26]

Man pages can be accessed from terminal once product is installed commands are:

man esets_smtp, man esets_pop3, man esets.cfg etc.

Also here you can download exported man pages http://ftp.nod.sk/~jedovnicky/esets_manpages.zip

Here is information about user specific configuration:

USER SPECIFIC CONFIGURATION

 

The ESETS system implements possibility to define so called user specific configuration, i.e. rele vant con-figuration parameters specific for e-mail recipient and/or e-mail sender can be defined.

 

As described in section USER SPECIFIC CONFIGURATION of esets.cfg(5) manual page the user spe-cific configuration is created when an appropriate special configuration section created within a special con-figuration file path referenced from this agent section (see main ESETS configuration file) by option user_config = path.

 

The header name of user specific section must be in general of the following format,

 

[s_eml|c_eml]

 

where 's_eml' is server's (i.e. recipient's) fully qualified email address or its domain subset, 'c_eml' is client's (i.e. sender's) fully qualified email address or its subset.

 

Note that it is not mandatory to define both client' s and server's parts of the header name. In this case the appropriate part not present within header name will be assumed to be not restricted. The following exam-ple shows definition of section with the section header name compound only from the client' s e-mail address for which we would like to define special configuration.

 

[|username@domain.com]

 

av_scan_obj_archives = yes

 

Please, note that thanks to '|' character present at the beginning of section header name, the main ESETS daemon knows that an appropriate email address represents the client's part of the section header name. In case you omit the character '|', the appropriate content of the section header name will be assumed to be its server's part as shown in an example below.

 

[username@domain.com]

 

av_scan_obj_archives = yes

 

Note also that the section header name can be only domain subset of an appropriate fully qualified email address as shown in an example below

 

[domain.com]

 

av_scan_obj_archives = yes

 

or even

 

[org|domain.com]

 

av_scan_obj_archives = yes

 

Once user specific configuration defined, it will be used if main ESETS system control and scanning dae-mon has been instructed about it. The esets_smtp agent will do this automatically and tell the daemon about the first recipient and also about the sender of the message.

 

Once fully qualified recipient' s and/or sender's email address passed to the daemon, it is compared with section header names found in the special configuration file. The comparison is performed with all section header names consecutively in order as they are written within the file. The configuration appropriate to the first matched section is chosen. If no section header name matches the recipient's/sender's email address passed to the daemon, the configuration appropriate to the agent section from main ESETS configuration file is chosen. The section header name matching algorithm is as follows:

 

If no recipient's address passed to the daemon or no recipient's part of the section header name present, the algorithm returns match for this part of section header name. If fully qualified recipient' s address 'rcptname@rcptdomain.com' passed to the daemon, the algorithm compares this address and its parts (i.e. consecutively 'rcptname@rcptdomain.com', 'rcptdomain.com', 'com' is compared) with the recipi-ent's part of the section header name.

Similarly if no sender's address passed to the daemon or no sender's part of the section header name present, the algorithm returns match for this part of section header name. If fully qualified sender' s address 'sndrname@sndrdomain.com' passed to the daemon, the algorithm compares this address and its parts (i.e. consecutively 'sndrname@sndrdomain.com', 'sndrdomain.com', 'com' is compared) with the sender's part of the section header name.

 

If both comparison steps described above return match the configuration appropriate to the section header name is chosen. On the other hand if at least one of the steps returns no match, an appropriate section is skipped.