Linux technical support, Technical Blogs, Cheap dedicated server support, Cheap linux dedicated server support, Cheap windows dedicated server, Dedicated server support, Data center Operation, System Administration, Bash and perl scripts for server maintainance

I want to use a default mail address of

*: :fail: No such address

… in a domain’s valias file. Easy enough to do but I still want to let through postmaster@domain.com and abuse@domain.com as per common practice. Some servers for instance will not allow mail through if there is no postmaster@… defined for a domain, Sourceforge being an example.

Here’s a solution:

1. Create a file called /etc/myaliases with:

Code:

postmaster: root
abuse: root

2. In the WHM > Exim Configuration Editor scroll down to the section “DIRECTORS CONFIGURATION” and in the first text box of that section put:

Code:

mysystem_aliases:
driver = redirect
allow_defer
allow_fail
data = ${lookup{$local_part}lsearch{/etc/myaliases}}
file_transport = address_file
pipe_transport = address_pipe
retry_use_local_part

You’ll then have a server-wide postmaster and abuse address that won’t be interfered with by users having :fail: Default Addresses.

PopCommunicationErr

Description:	The POP Server encountered an error when trying to communicate with the MSS. Displays “Pop communications failure with message store server, disconnecting user.”
Parameters:	None.
Cause:	Typically caused by a problem with the MSS. The MSS could be in a strange state. The machine that the MSS is running on, which this POP Server is communicating with, could be in a strange state.
Effect:	The event is of warning severity.
Actions:	Check the log file for the MSS that this POP Server is communicating. Probably other errors are a better indication of what is wrong with the MSS.

PopConnectionNotAllowed

Description:	IP Address is attempting to connect to the popserv but is denied because the address is not listed in the allowedIPs configuration key.
Parameters:	IP Address.
Cause:	The allowedIPs configuration key specifies the IP addresses from which the popserv accepts connections. Unlisted IP addresses have their connections dropped immediately.
Effect:	No effect on service; prevents POP attacks.
Actions:	None.

PopConnMade

Description:	The POP Server successfully validated the user. This is a notification in the logfile. It is not an error event.
Parameters:	None.
Cause:	The user being successfully validated by the POP Server.
Effect:	The event is of informational severity.
Actions:	None.

PopConnTimedOut

Description:	A POP communication with a client has timed out and subsequently disconnected.
Parameters:	None.
Cause:	A connection between a client and the POP server was established, but the client has not sent command data to the server within the configurable timeout period (popClientTimeout).
Effect:	If this occurs, the POP server thread terminates the client connection and exits.
Actions:	If the time out period is not long enough, modify parameter popClientTimeout in the configuration database appropriately. Otherwise, reconnect to the POP server and continue where you left off.

PopDomainTableEntryError

Description:	At least one of the values in the loginDefaultDomainTable (found in the config.db) contains an entry which does not follow this format: <ipaddr>:<defaultDomain>
Parameters:	The table entry which caused the problem
Cause:	An entry in the loginDefaultDomainTable was incorrectly entered into the config.db.
Effect:	The loginDefaultDomainTable entry mentioned in the log message, as well as any entries that follow it (within the loginDefaultDomainTable table), is ineffective.
Actions:	Make the appropriate corrections to the loginDefaultDomainTable, using imconfedit. Do not restart services.

PopLockTimeoutTooAggressive

Description:	Indicates the LockTimeout configuration key might be too low.
Parameters:	None.
Cause:	A POP user’s exclusive POP lock timed out, but the user was subsequently active.
Effect:	When a POP client successfully logs on to the POP server, it receives an exclusive lock on its mailbox. If there is an attempt to log on to the same mailbox with the exclusive lock, it refuses the attempt with an error message. A POP client normally holds the lock until it Quits. The POP3 specification demands exclusive locking. Unfortunately, a user can end up locked out of his or her own mailbox, causing calls to customer support. This parameter is to control a common cause of these complaints. A communications transport implementation weakness (not part of InterMail) can cause the POP server to believe a connection with a POP client is still open, when in reality the POP client got hung up on. When the user redials and attempts to access his or her mailbox, he or she gets rejected with a message that his or her mailbox is exclusively locked–a message the user is probably not used to seeing. The popClientTimeout will eventually cause the connection to close, but many users will lose patience and call customer support before it kicks in. If a POP client is idle for the LockTimeout, it loses its exclusive rights to the lock, and shares it with the next client that requests it. If it hangs up on a user, the default LockTimeout value will take away the exclusive right to the lock from the dead connection before the user has the time to dial back in. Once the user is connected, she will be able to successfully log on and access her mailbox, because the new session will be able to share the lock with the dead one. The popClientTimeout will subsequently kill off the dead connection for good. Software POP clients access a mailbox in a rapid fashion; it should be very rare in practice to see a LockTimeout kick in when the POP client is still interested in the connection. When this rare case does occur, the POP server records the PopLockTimeoutTooAgressive notification log message. When a LockTimeout does occur to an active session, ill can come of it only if another session grabs the lock. The original session and the new session will both share the lock. The worst that can happen is for one session to delete a message that the other session subsequently tries to retrieve, causing the retriever to get an error. More typically, an active session that suffers a LockTimeout will send a command to the POP server before another session tries to access the mailbox. In this case, the POP server grants the exclusive lock to the session again, and the session continues just as if the LockTimeout never occurred.
Actions:	Lots of these events in the log are a symptom of the LockTimeout configuration key being too low. Adjust it up.

PopMaxSessions

Description:	The POP Server is hitting the maximum number of connections configured by the system administrator, and does not accept additional connections until other clients are disconnected. The maximum connections allowed is configured using the /*/popserv/maxSessions keyword within the configuration server (imconfserv). Setting the maxSessions to the default [0] disables this feature.
Parameters:	count: the maximum number of connections
Cause:	There are too many incoming connections.
Effect:	The event is of warning severity.
Actions:	If these messages persist, consider raising the connection limit, or add additional servers if the server is already overloaded.

PopNoMSS

Description:	While verifying the user and password, the MSS was unavailable. Displays “User’s MSS is currently inactive.”
Parameters:	None.
Cause:	Something is either wrong with the MSS or the machine on which the MSS is running. Note that the event that caused this is AcctInactive.
Effect:	The event is of minor severity.
Actions:	This is not typically a problem with the POP Server. Check the status of the MSS with which this POP Server was communicating. Check the machine on which the MSS is running.

PopProtocolErr

Description:	This event occurs when the POP Server receives a command from a POP client that is not part of the POP protocol (from the server’s point of view). It is not a serious error.
Parameters:	cmd: the POP command.
Cause:	The POP client sends a command that is not in the POP set of commands.
Effect:	The event is of warning severity. This is not serious and indicates a problem with the client software.
Actions:	None. See man page on POP Server and Post Office Protocol and Post Office Protocol extensions.

PopProxyLoopDetected

Description:	The POP server has been configured to proxy connections back to its own incoming POP port. This will cause the POP server to loop to itself, and use up all available connection threads, denying service to other incoming clients. The incoming connection is closed. The pop proxy host is configured using the /*/popserv/popProxyHost keyword within the configuration server (imconfserv). The pop proxy port is configured using the /*/popserv/popProxyPort keyword within the configuration server (imconfserv). One or both of these values must be configured to a value other than the one currently in use by the popserv that is being configured.
Parameters:	None.
Cause:	The popserv has been configured to proxy all incoming connections back to itself, causing an infinite loop.
Effect:	The event is of urgent severity. Users are prevented from collecting their mail while this condition exists.
Actions:	Immediately after receiving this message, the POP proxy settings should be reviewed, and the settings should be changed to appropriate new values.

PopServerTooManyBadCommands

Description:	The POP client issued too many invalid commands, so the connection was closed.
Parameters:	IP address: the client’s IP address.
Cause:	Either the client program does not correctly implement the POP protocol, or someone has connected to the POP port with telnet and issued several invalid commands.
Effect:	This event is for information only.
Actions:	Look for previously logged events for PopProtocolErr to see what the bad commands were.

PopSyncError

Description:	Synchronization error with MSS; got reply reply in state “state.”
Parameters:	reply: name of the unexpected reply received. state: state of the POP connection when the reply received.
Cause:	The MSS or POP Server could be in a strange state.
Effect:	May indicate a problem with the MSS or the POP Server. Clients may not be able to access mail using POP.

SmtpAddressFixed

Description:	An SMTP client sent a command to the server that contained an improper e-mail address. The address fixed to conform to e-mail standards.
Parameters:	otherHost: the other SMTP host. SMTPCommand: the SMTP command given by the other host. newAddress: the new address.
Cause:	The connected SMTP client does not follow Internet standards, or is perhaps misconfigured.
Effect:	The event is of informational severity.
Actions:	No action is necessary. Contacting the remote site’s postmaster may be a good idea if the improper addresses are excessively broken. It is possible that the resulting address will not refer to an actual mailbox, so delivery to it may fail.

SmtpBadRelayPolicy

Description:	The anti-spam relay policy is mis-configured because it is not a known policy.
Parameters:	relay policy: The relay policy as listed in config.db.
Cause:	The config.db entry for relaySourcePolicy is incorrectly entered.
Effect:	The relaySourcePolicy defaults to allow-all.
Actions:	Fix the config.db entry for relaySourcePolicy.

SmtpClientGreetResponse

Description:	The SMTP server on the named host sent a greeting message containing a status code that indicates it is unwilling or unable to accept mail.
Parameters:	hostName: the host name. statusCode: the status code. greetingType: the greeting type.
Cause:	The remote server is unwilling or unable to accept mail.
Effect:	The event is of informational severity. Mail not delivered to the named machine, so this condition may be causing mail to queue locally (it may deliver successfully to another mail server, though).
Actions:	Connect to the SMTP port of the machine referenced in the hostName key (using telnet) to see the greeting message.

SmtpClientLineTooLong

Description:	The connected SMTP client sends a line that exceeds the defined maximum line length.
Parameters:	clientIp: the IP address of the client. clientLineLengthLimit: the defined maximum line length allowed from a client.
Cause:	Either the client program does not correctly implement the SMTP protocol, someone has connected to the SMTP port with telnet and issued an invalid command, or the configuration variable clientLineLengthLimit is set too low.
Effect:	The client command is rejected.
Actions:	Inspect the clientLineLengthLimit configuration variable. Make sure it is 0 (no limit) or at least 1000 (the RFC821 maximum).

SmtpClientMailLoopDetected

Description:	While attempting to deliver a message to the specified domain, the system determined (by DNS lookups) that the message would have to be delivered locally; however, the mail server is not properly configured to accept mail for the domain. If the message were delivered to the server, it would end up in a loop whereby the message continually delivers to itself.
Parameters:	mailRecipient: the recipient of this message.
Cause:	· The MX records for the domain indicate that there are no other servers with a higher preference than this server · Upon connecting to the remote server, it had the same name as this server (so the server probably connected to itself to deliver the mail).
Effect:	The event is of informational severity. While this condition exists, cannot deliver mail destined for the domain.
Actions:	Look up the MX records for the domain (using nslookup). Check the MTA configuration for the list of local mail domains. Fix the configuration of the MTA to accept mail for the domain and/or fix the configuration of the DNS for the domain.

SmtpClientNoGreeting

Description:	The SMTP server running on hostName did not respond with a greeting within a reasonable amount of time, so the connection closed.
Parameters:	hostName: the name of the host.
Cause:	The server is likely busy handling other network connections and does not have the resources to respond within the time-out period. A network connectivity problem may also be the cause, but this is less likely.
Effect:	The event is of informational severity. Mail to deliver to the server may have queued for a later attempt; however, it may have successfully delivered to an alternate mail server. If this condition persists for several days and no other servers are available to receive the messages, they will return to their senders.
Actions:	· Use trace route to verify network connectivity. · telnet to the remote host’s MTA port.

SmtpClientNoResponse

<

Description:	The SMTP server running hostName did not respond to the specified command within a reasonable amount of time, so the connection closed.
Parameters:	hostName: the host on which the other server is running. command: the command the other server did not respond to.
Cause:	The server is likely busy handling other network connections and did not have the resources needed to respond within the time-out period. A network connectivity problem may also be to blame.
Effect: