Domino Router Restrictions and Controls Explained, Problem/Technote (troubleshooting) The Restrictions and Controls section of the Server Configuration document is an important part of the Domino SMTP/mail server. This is where mail restrictions are configured to help prevent spam

Technote (troubleshooting)

Problem

Introduction
The Restrictions and Controls section of the Server Configuration document is an important part of the Domino SMTP/mail server. This is where mail restrictions are configured to help prevent spam. Spam mail is also referred to as Unsolicited Commercial Email (UCE) or Unsolicited Bulk Email (UBE) and can cause many problems for Domino Administrators. This section of the Configuration document can also be used to control users, servers, domains, and Notes organizations from sending or receiving mail.

Purpose
The purpose of this Technical Paper is to assist you in configuring the Restrictions and Control section of the Server Configuration document. In describing Restrictions, SMTP inbound controls, SMTP outbound controls, Delivery controls, Transfer controls and Rules, this document not only addresses the restrictions for unwanted Internet mail, but it also describes the process for configuring threads and other router restrictions. Examples are provided of the restrictions and the error messages displayed when the restriction is applied by the server.

Assumptions
This document assumes that:

• You have a working SMTP Domino R8.x server with a registered Internet domain and the corresponding settings in Domain Name System (DNS).
• You have working knowledge of the SMTP conversation for mail transmission. For more information on the SMTP commands, refer to the Request for Comments number 821, also known as RFC821.

The error messages herein are the default error messages for each field; it is assumed that no error messages have been modified in the Failure Message section under Router/SMTP, Advanced, Controls.

Furthermore, this document uses the terms "local Internet domain" and "external Internet domain" throughout. Here, the local Internet domain refers to the Global Domain document's "Local Primary Internet Domain" and "Alternate Internet Domain aliases." All entries in these two fields are considered the local Internet domain, and all Internet domains not listed are considered the external Internet domains.

Resolving the problem

Restrictions




Allow mail only from domains:

This field is used to specify the Notes domains that can send mail to this domain. If a domain is added to this field, mail will be accepted only from this domain; mail from other Notes domains will be rejected. This restriction does not affect mail routing within the local Notes domain.

The following error message displays on the server console, is written to the log, and is sent back to the originator when the user's domain is not listed in this field:

"02:21:04 PM Router: Policy Reason: Your Domain does not have access to route messages to the specified domain."

Field-Level Help: Domains that will be allowed to send mail to this domain..

Deny mail from domains:

This field is used to specify the Notes domains that cannot send mail to this domain. Adding a domain to this field denies mail from this domain only; Domino will continue receiving mail from all other Notes domains. This restriction, like the "Allow mail from domains" field, does not affect mail routing in the local Notes domain.

The error message is the same as that for the "Allow mail from domains" field, except it is displayed when the domain is entered in this field.

Note: If a single Notes domain is entered in both the allow and deny fields, then the deny field would takes precedence over the allow, this is done because of security issues.

Field-Level Help: Domains that will be restricted from sending mail to this domain.

Allow mail only from the following organizations and organizational units: (*/Acme, */Sales/Corp)

This field is similar to the "Allow mail from domains" field; however, this restriction uses organizational units and/or organizations to allow mail instead of the Notes domains. An entry in this field allows mail only from this organization or organizational unit to send mail to this domain. For example, suppose you enter */acme in this field. This entry allows only users from the acme organization to send mail to the local domain. However, organizations can be split into multiple domains, so this restriction could be done with the "Allow mail from domains" field, but it would require multiple entries.

Error message when the organization is not listed in the allow field:

"02:44:01 PM Router: Policy Reason: Router: CN=First Last/O=ACME@ACME is restricted from sending mail through server SERVER/R80."

Field-Level Help: Organizations and organizational units which are allowed to send mail to this
domain. This restriction applies only if the sender's address is a Notes distinguished name.


Deny mail only from the following organizations and organizational units: (*/Acme, */Sales/Corp)

This field is very similar to "Deny mail from domains" field; however, this restriction uses the organizational units and/or organizations to restrict Notes mail routing. An entry in this field denies mail only from this organizational unit and/or organization. The Domino server will allow the server to route mail from all other organizations. For example, if you enter */north/acme in this field, it will deny all mail from this organizational unit, but it would allow mail from */south/acme to be delivered.

NOTE: If a single Notes organization is entered in both the Allow and Deny fields, the Deny takes the precedence over the Allow because of security reasons.

Error Message received on the Domino console when the sending organization is listed in this field:

"02:49:38 PM Router: Policy Reason: Router: CN=First Last/O=ACME@ACME is restricted from sending mail through server SERVER/R80"

Field-Level Help:Organizations and organizational units which are restricted from sending mail to this domain. This restriction applies only if the sender's address is a Notes distinguished name.


Maximum message size: 0 KB (default)

This is the maximum message size in KB (Kilobytes) the server will accept for routing both Internet mail and Notes mail. This restriction is used for both transfer and local delivery. The default setting 0 K, which will allow the router to deliver any message size.

There are two error messages associated with this field when the message exceeds the maximum size:

"02:53:13 PM Router: Policy Reason: Router: Unable to dispatch message. Size exceeds 1 Kbytes"

"552 Message size exceeds fixed maximum message size set by administrator"

The first is written to the Log and sent back to the registered Notes user in the form of a deliver failure report. The second error message is displayed on delivery failure reports for Internet users.

Field-Level Help: Messages larger than this size will not be transferred or delivered. A non delivery message will be returned to the sender reporting the reason for the failure.


Send all messages as low priority if message size is between: Disabled




This field works with the maximum message size; when the field is enabled, it displays another field. This hidden field allows the to set a size range in KB. If a message falls within this range, the message status would be set to low, and it would routed as low priority. For more details on setting low-priority message delivery, see "Low Priority mail routing time range" in the Transfer Controls tab.

This option can be used if network bandwidth is an issue and you want a certain-sized messages to be received but not transferred during busy production hours. This option works only if the message is being transferred; it does not work for local delivery.

No error messages given or displayed on the server. You can issue a "tell router show" on the server console to see the queue status.

Field-Level Help: Messages in this size range will have their priority permanently changed to low causing them to be sent only during off peak hours. Note that a range of 0 to 0 means never change priority.
---------------------------------------------------------------------------------------------------------------------------------------------------------

---

SMTP Inbound Controls

Inbound Relay Controls

An IP range can be used to represent more than one host. If the asterisk is placed in one or more units of an IP address, the variant range(s) takes effect.

For example:

This syntax does not work ----> [9.9.*]

Some syntaxes that work ------> [9.9.9.*], [9.9.*.*], [9.*.*.*]




Allow messages to be sent only to the following external Internet domains:

This field configures the Domino R8 mail server as a relay for the specified Internet domains. For example, if you enter acme.com, Domino will relay messages for recipients only in this external Internet domain. This entry will also allow the server to route mail for user@server.acme.com. If @acme.com is entered in this field, a message addressed to user@server.acme.com will be rejected by the Domino server. Any message an SMTP server attempts to relay to this server will be rejected, unless they belong to the acme.com Internet domain.

It is important to note that this setting is used only when the connecting server is not a member of the local Internet domain and it is attempting to relay a message for a recipient in the acme.com domain. This field is a text field that will accept multiple entries, but these entries must be separated by a comma.

Error Message when the Internet domain is not listed in this field:

"12:59:11 PM SMTP Server [026A:0005-0125] Attempt to relay mail to anyone@domain1.com rejected for policy reasons. Relays to recipient's domain denied in your configuration."

Field Level Help: The external Internet domains to which messages will be relayed (or the Domino domains to which messages will be relayed if the item starts with a percent sign). Recipients in all other domains will be rejected. Items need only match the end of the domain name (acme.com will match jsmith@serv1.acme.com, @acme.com will match jsmith@acme.com but will not match pbrown@serv1.acme.com ).

Deny messages from external Internet domains to be sent to the following Internet domains:

Entries in this field restrict the Domino server from relaying messages from external hosts to the domain specified in this field. If the message is addressed to recipients in this domain, the Domino server rejects the message. This field, like the Allow field, will also accept multiple entries, but these entries must be separated by a comma.

For example, if you enter "acme.com" in this field, when a external server connects to send mail to user@acme.com, the message would be rejected. If you enter "@acme.com" in this field, the Domino server would only reject message from users that belong to this Internet domain; messages addressed to user@server.acme.com would be allowed.

NOTE: If you specify the same entry in the Allow field and the Deny fields, Domino will always take the Deny field as precedence over the Allowed field. Because of security concerns, Deny must take precedence. You can also use an asterisk (*) as a wildcard to indicate all domains are denied.

Error Message displayed when the domain is entered the deny field:

"01:04:18 PM SMTP Server [0101:0004-0148] Attempt to relay mail to user@acme.com rejected for policy reasons. Relays to recipient's domain denied in your configuration."

Field Level Help: The external Internet domains to which we will never relay messages(or the Notes domains to which messages will never be relayed if the item starts with a percent sign). * would reject message relays to all recipients. Items need only match the end of the domain name (acme.com will match jsmith@serv1.acme.com, @acme.com will match jsmith@acme.com but will not match pbrown@serv1.acme.com ).

Allow messages only from the following external Internet hosts to be sent to external Internet domains:

The entries in this field identify the external hosts and/or IP addresses allowed to relay messages through this Domino server. The message destination must be an Internet domain for which the intended recipient is another Internet domain. These host names and/or IP address will be able to relay messages through the Domino R5 server.

For Example, if you enter acme.com in this field, Domino will only accept mail from servers that match this entry, so server.acme.com would match. More information on this can be found in the Field Level help.

Error Message received in the form of Delivery failure reports when the domain is not listed in the Allow field:

"554 Relay rejected for policy reasons"

Field Level Help: The fully qualified host names or IP addresses of connecting hosts for which we will relay messages. Items need only match the end of host names (acme.com will match serv1.acme.com). IP addresses are always enclosed in square brackets and may include * as a wildcard for subnet addresses.

Deny messages from the following external Internet hosts to be sent to external Internet domains:

The entries in this field identify the external hosts and/or IP address restricted from relaying messages through this Domino server. A message intended for recipients outside the local Internet domain would be rejected.

For Example, if you enter Domain1.com in this field, Domino will reject the ability to relay mail from servers that belong to this Internet domain.

NOTE: If you specify the same entry in the Allow field and the Deny fields, Domino will always take the Deny field as precedence over the Allowed field. Because of security concerns, Deny must take precedence. You can also use an asterisk (*) as a wildcard to indicate all domains that are denied from relaying.

Error Message received in the form of Delivery failure reports when the domain is listed Deny:

"554 Relay rejected for policy reasons"

Field Level Help: The fully qualified host names or IP addresses of connecting hosts for which we will never relay messages. * means all hosts. Items need only match the end of host names (acme.com will match serv1.acme.com). IP addresses are always enclosed in square brackets and may include * as a wildcard for subnet addresses.

Inbound Relay Enforcement Perform Anti-Relay enforcement for these connecting hosts:

Field Level Help: Specifies whether inbound relay controls apply to internal as well as external host. Choose one.

"External host" (default) The server enforces inbound relay controls only for host outside the local internet domain. Internal host can always relay.

"All connecting host" Provides a stricter relay enforcement by applying inbound relay controls to internal as well as external host.

"None" - Disables inbound relay controls.


Exclude these connecting hosts from anti-relay checks

Field Level Help: Enter the IP address or host names to specify host exempt from enforcement of inbound relay controls. Enter an IP address in square brackets: for example [127.0.0.1]. You can wild cards to represent an entire subnet address, but not to represent values in a range.

For example, [127.*.0.1] is valid. 123.123.12.*.123] is not.


Exceptions for authenticated users:

Field Level Help: Specifies whether authenticated user are exempt from enforcement of the inbound relay controls.

Perform anti-relay checks for authenticated users - The server does not allow exceptions for authenticated users. Authenticated users are subject to the same enforcement as non-authenticated users.

Allow all authenticated users to relay - User who logs in with a valid name and password are exempt from the applicable inbound relay controls. Use this to enable relaying by POP3 or IMAP users who connect to the network from ISP accounts outside the local Internet domain.

Note: When setting your configuration settings document to 'Allow all authenticated users to relay' the
administrator will need to change the server document: Mail tab Name & password to Yes under Mail SMTP Inbound

Server Document:



DNS Blacklist Filters
DNS Blacklist Filters:

Field Help: If enabled the smtp listener task will perform dns queries against the blacklist sites configured below for all host that are subject to inbound relay control enforcement.

Enabled - When Domino receives an SMTP connection request, it checks whether the connecting host is listed in the blacklist at the specified sites.

Disabled - Domino does not check whether a connecting host is on the blacklist.


Allow connections only from the following SMTP internet hostnames/IP addresses:

Field Help: Allow messages only from these host. Items need only match the end of host names (acme.com will match server1.acme.com) IP address must be enclosed in square brackets and may include an * as a wild card or subnet address.

Deny connections from the following SMTP internet hostnames/IP addresses:

Field Help: Refuse messages from these hosts. Items need only match the end of host names (acme.com will match server1.acme.com) IP address must be enclosed in square brackets and may include an * as a wild card or subnet address.

Error limit before connection is terminated:

Field Help: Terminates the connection when the number of protocol errors returned for the session exceeds this value. For example, possible errors are blacklist rejections, or RCPT to rejections. The error returned is – 421 smtp service is not available.. Closing transmission channel.

DNS Whitelist Filters

DNS Whitelist Filters:
When enabled the SMTP listener task performs DNS queries against whitelist sites your you define in the "DNS Whitelist filters".

Field Help: If enabled the smtp listener task will perform dns queries against the whitelist sites configured below for all host that are subject to inbound relay control enforcement.

DNS Whitelist Sites:
Defines a list of DNS whitelist sites in which the SMTP listener task will perform DNS queries.

Field Help: Specifies the dns whitelist sites to check when domino receives an smtp connection request.

Desired action when a connecting host is found in a dns whitelist:
Specifies actions to be taken when a host is found in DNS whitelist,

Field Help:
Silently skip blacklist filters – Performs no logging>
Log only – Records the host name and IP address of the connecting server found in the private whitelist.
Log and tag – Adds the Note item, $DNSWLSITES, to messages accepted from whitelisted hosts.

Private Blacklist Filters
Private Blacklist Filter:

Field Help: If enabled, the smtp listener task will determine if the connecting host has been blacklisted by the Administrator. Note: Applies only to host subject to inbound relay enforcement.

Blacklist the following hosts:

Field Help: Enter the ip addresses or host names of the systems to black list. Enclose IP addresses with square brackets: For example [127.0.0.1]. IP ranges and masks are supported. Wild cards can be used except within ranges.

Desired action when a connecting host is found in the private blacklist:

Field Help: Log only - Records the host name and IP address of the connecting server and the name of the site where the server was listed.
Log and tag messages - Adds the Note item, $DNSBLSites to the messages accepted from blakclisted host.
Log and reject message - Rejects the connection and returns a configurable error message to a blacklisted host.

All actions skip blacklist filters, if enabled.

Custom SMTP error response for rejected messages:

Field Help: Text included in the error response when rejecting messages from blacklisted hosts. The format specifier '%s' can be used to insert the ip address of the connecting host. For example, if you enter the following text Your host %s was blacklisted, when domino rejects a message from the blacklisted host 127.0.0.1, it will return the following error message. Your host 127.0.0.1 was black listed.

Private Whitelist Filters
Private Whitelist filters

Field Help: If enabled, the SMTP listener task will perform DNS queries against the whitelist sites configured below for all host that are subject to inbound relay control enforcement.

DNS Whitelist Sites:

Field Help: Enter IP address or host names of the system to whitelist. Enclose IP adresses with square brackets: for example: [127.0.0.1]. IP ranges and masks are supported. Wildcards can be used except within ranges.

Desired action when a connecting host is found in a DNS whitelist:

Field Help: Silently skip blacklist filters - Performs no logging. Log only - Records the host name and IP address of the connection server, and the name of the site where the server was listed. Log and tage message - Adds the note item $DNSWLSites, to messages accepted from whitelisted hosts. All actions skip blacklist filters, if enabled.

---

Outbound Sender Controls Allow messages only from the following Internet addresses to be sent to the Internet:
Field Help: The sender may send messages outside of the local internet domain only if their address is included in this list. This restriction only applies if the sender's address is an internet address.
Specifies the RFC 821 Internet addresses of users in the local Internet domain from whom IBM® Lotus® Domino® accepts mail destined for Internet addresses outside the local Internet domain. If this field contains entries, Domino accepts outbound Internet mail from the specified Internet addresses only and rejects outbound Internet mail sent from other addresses. Rejected mail is returned to the sender.
Enter Internet addresses in the form user@domain.com, or enter the name of an IBM® Lotus® Notes® group containing a list of Internet addresses allowed to send mail to the Internet.
Wildcards (for example, *acme.com) and isolated Internet domain suffixes (for example, acme.com) are not acceptable values in this field.
Group entries cannot contain a domain part or dot ('.'). For example, the group with the name DenyMail is valid, but the groups named Deny.iris.com or Denymail@iris are not.
Deny messages from the following Internet addresses to be sent to the Internet:
Field Help: The sender may not send messages outside of the local internet domain if their address is included in this list. 8 means deny all. This restriction only applies if the sender's address is an Internet address.
Specifies the RFC 821 Internet addresses of users in the local Internet domain from which Domino does not accept mail destined for external Internet addresses. If this field contains entries, Domino rejects outbound Internet mail sent from the specified Internet addresses and returns it to the sender. All other users can send Internet mail.
Enter Internet addresses in the form user@domain.com, or enter the name of a Notes group listing the Internet addresses from which to deny outbound Internet mail.
Wildcards (for example, *acme.com) and isolated Internet domain suffixes (for example, acme.com) are not acceptable values in this field.
Group entries cannot contain a domain part or dot ('.'). For example, the group with the name DenyMail is valid, but the groups named Deny.iris.com or Denymail@iris are not.
Allow messages only from the following Notes addresses to be sent to the Internet:
Field Help: The sender may send messages outside of the local internet domain only if their address is included in this list. This restriction only applies if the sender's address is a Notes address. Groups are allowed as entries, however, ACL type groups are not supported.
Specifies the Notes user names from which Domino accepts mail destined for external Internet addresses. If this field contains entries, Domino accepts outbound Internet mail from the specified entries only and rejects outbound Internet mail sent from all other Notes addresses. Rejected mail is returned to the sender.Enter fully-qualified Notes addresses in the form User/Organizational_unit/Organization, or enter the name of a Notes group whose members you want to prevent from sending Internet mail. Group entries cannot contain a domain part or dot ('.'). For example, the group with the name DenyMail is valid, but the groups named Deny.iris.com or Denymail@iris are not.
Deny messages from the following Notes addresses to be sent to the Internet:
Field Help: The sender may not send messages outside of the local internet domain if their address is included in this list. * means all. This restriction only applies if the sender is a Notes address. Groups are allowed as entries., however ACL type groups are not supported.
Specifies the Notes user names from which Domino does not accept mail destined for external Internet addresses. If this field contains entries, Domino rejects outbound Internet mail sent from the specified entries and returns it to the sender. Domino accepts outbound Internet mail from all other Notes addresses.
Enter fully-qualified Notes addresses in the form User/Organizational_unit/Organization or the name of a Notes group whose members you want to prevent from sending Internet mail.
Group entries cannot contain a domain part or dot ('.'). For example, the group with the name DenyMail is valid, but the groups named Deny.iris.com or Denymail@iris are not.
Outbound Recipient Controls
Allow messages only to recipients in the following Internet domains or host names
Field Help: Messages will be allowed if the recipient's domain name is in the list. Messages will also be allowed if one of the possible mail exchange (mx) hostnames for the intended recipient's domain matches an entry in this list. Messages to other domains or hostnames are denied. Entries only need to match the end of names (acme.com allows server1.acme.com).
Specifies the Internet domains, such as acme.com, and Internet host names, such as mailhost.acme.com, to which Domino can send mail. If there are entries in this field, users can only send Internet mail to the specified entities. Domino denies mail to all other domains or host names.
If you specify an Internet domain, users can send mail to any host or sub-domain in that domain. Domino matches entries against the last part of domain names or host names, so entering host.acme.com allows mail to mail.host.acme.com as well inbound.host.acme.com.
Group entries cannot contain a domain part or dot ('.'). For example, the group with the name AllowMail is valid, but the groups named Allow.iris.com or Allowmail@iris are not.
Deny messages to recipients in the following Internet domains or host names
Field Help: Messages to recipients in domains specified in this list are denied. Messages are also denied if a hostname in this list matches one of the possible mail exchange (mx) hostnames of intended recipient's domain. Entries only need to match the end of names (acme.com denies server1.acme.com)
Specifies the Internet domains, such as acme.com, and Internet host names, such as mailhost.acme.com, to which Domino cannot send mail. Domino allows mail to all other domains or host names. Domino matches entries against the last part of domain names or host names, so entering host.acme.com denies mail to smtp.host.acme.com as well as inbound.host.acme.com.
Group entries cannot contain a domain part or dot ('.'). For example, the group with the name DenyMail is valid, but the groups named Deny.iris.com or Denymail@iris are not.

Delivery Controls

Delivery Controls Maximum delivery threads: Field Help: Enter the maximum number of delivery threads. If left blank, the Router automatically sets the value. The maximum number of server threads Domino can create to deliver mail from MAIL.BOX to local mail files. The Router automatically sets the default maximum number of delivery threads based on server memory. Letting the Router select the maximum number is usually best. To set the maximum number manually, enter a maximum between 1 and 25, based on the server load. Encrypt all delivered mail: Field Help: Enavled - Always encrypts mail, regardless of settings in recipient's Person document. Disabled - Encrypts mail only if specified by settings in the recipient's Person document. Enabled - When delivering messages to local mail files, Domino encrypts the messages, regardless of whether the sender encrypted the message or the recipient's mail file encrypts messages. Disabled (default) -- Domino encrypts messages only if the recipient's mail file is set to encrypt received messages. Pre-delivery agents: Field Help: This field specifies the maximum elapsed time that any pre-delivery agent will allowed to execute. If the agent executes beyond the number of seconds specified by this field, the execution of the agent will be aborted. Users who create LotusScript™ or Java™ agents for their mail files can set that the agent runs before new mail arrives. When delivering mail, if the Router detects such a pre-delivery agent, it runs it on against message before the message ever appear in the recipient's Inbox. Use this field to specify whether the server permits the use of pre-delivery agents. Choose one: Enabled - (default) Allows the Router to run agents that process mail before delivering it to user mail files on the server. Disabled - Prevents the Router from running pre-delivery agents. Pre-delivery agent timeout: Field Help: This field specifies the maximum elapsed time that any pre-delivery agent will be allowed to execute. If the agent executes beyond the number of seconds specified by this field, the execution of the agent will be aborted. The maximum time (in seconds) that a pre-delivery agent, such as a mail filter, can run before the Router interrupts it. Because the Router waits for pre-delivery agents to complete, failure to restrict agents can slow routing performance on the server. The default time-out is 30 seconds. User rules mail forwarding: Field Help: Enabled - The Router Supports the "Send copy to" action for the client mail rules, allowing users to send copies of messages automatically to other recipients. Disabled - Prevents Notes clients from using "Send copy to" rule action. Notes users can create mail file rules that automatically process new mail. Client mail rules specify an action to take on newly-delivered messages that meet certain conditions. Use this field to specify whether the Router on this server supports the rule action to send copies of selected messages automatically to other recipients. Choose one: Enabled - The Router supports the "Send copy to" action for client mail rules, allowing users to send copies of messages automatically to other recipients. Disabled - Prevents Notes clients from using the "Send copy to" rule action. Reverse path for forwarded mail: Field Help: Configure how the revers-path (SMTP Originator) is specified for messages forwarded by the user mail rule action "send copy to" By default revers path is set to null, indication delivery status reports (DSNs) should not be sent. Set revers-path to null -- The default setting. This setting avoids loops, but is rejected by som SMTP servers' spam filters. Preserve existing value --Message originator may receive failure reports. Use the current recipient's Internet address -- The person forwarding the message may receive a failure report. Caution! This can cause loops. Construct nondeliverable return address -Prepend "nonbounce" to the current recipient's Internet address to construct a nondelivreable return address. Set reverse-path to null -- Default setting. Delivery status reports are not sent. Preserve existing value -- Leave the setting as is. The message originator, that is, the person who originally sent the message, may receive delivery failure reports. Use recipients Internet address -- Use the current recipient's Internet address as the message originator. Construct non-deliverable return address -- Use "nobounce" prepended to current recipient's Internet address. Quota Controls Over Warning Threshold Notifications: Field Help: Send warning notification message to user when they are over their quota warning threshold. Specifies how often the Router delivers notifications to users who exceed their warning threshold. Choose one: None - The Router does not deliver notifications when mail files grow larger than the specified warning threshold. Per Message - The Router delivers a notification for every message it delivers after the mail file exceeds the specified warning threshold. Per Interval N - Send notifications at a specified interval until the user deletes or archives enough messages to bring the size of the mail file below the specified Warning Threshold. When this option is selected, an additional field, "Warning Interval Minutes," appears. Warning Interval Minutes: Field Help: Time Period during which only one warning notification should be given to users who are over their quota warning threshold. This field is available when selecting 'per time interval' from the above field. Specifies, in minutes, how long the Router waits to send the next Over Warning Threshold Notification Over Quota Notification: Field Help: Send error notification message to user when they are over their quota. The message will indicate the action taken by the router. Specifies how often the Router delivers notifications to users who exceed their quota. Choose one: None - The Router does not deliver notifications when mail files grow larger than the specified warning threshold. Per Message - The Router delivers a notification for every message it delivers after the mail file exceeds the specified quota. Per time interval - The Router immediately sends an "over quota" notification to the user's mail file; the notification is sent immediately -- not according to the specified per time interval setting. Error Interval: Specifies, in minutes, hours, or days how long the Router waits to send the next Over Quota Notification. Over Quota Enforcement: Field Help: Select Deliver Anyway to disregard the quota limit. Non Deliver will not allow delivery to the mail database over quota and will return a non delivery message to the sender reporting the reason for the failure. Hold and Retry will keep the message pending in the mail.box and try to deliver it later when the database may be under quota. Specifies the action the Router takes when receiving new mail for a user whose mail file is larger than the specified quota. Choose one: Deliver anyway (don't obey quotas) - (Default) The Router continues to deliver mail to a mail file that is over quota. Non Deliver to originator - The Router stops delivering new messages to the mail file and returns a nondelivery message to the sender reporting that the message could not be delivered because the intended recipient's mail file was full. Hold mail and Retry - The Router stops delivering new messages to the mail file and temporarily holds incoming messages in MAIL.BOX until space is available in the mail file. After a configured interval, the Router tries to deliver the message. If the user has sufficiently reduced the size of the mail database by the next scheduled delivery attempt, the mail is delivered. Messages that cannot be delivered before the configured expiration time (default =1 day) are returned to the sender as undeliverable. If you choose this option, the document displays additional fields where you can specify how the server handles held messages.

Transfer Controls
Transfer Controls
Maximum transfer threads:
Field Help: The maximum number of threads Domino creates to transfer messages to all other servers. The value applies to both Notes routing and SMTP. The Router sets a default maximum number of transfer threads based on server memory. Letting the Router select the maximum number is usually best . If you set the maximum number manually, set the maximum to between 1 and 25 threads, depending on server load.

The maximum number of server threads Domino creates to transfer messages to all other servers. The value applies to both Notes routing and SMTP. The Router sets a default maximum number of transfer threads based on server memory. Letting the Router select the maximum number is usually best. If you set the maximum number manually, set the maximum to between 1 and 25 threads, depending on server load. Maximum concurrent transfer threads:
Field Help: The maximum number of server threads the Domino Router uses to transfer messages to a single destination. The value applies to both Notes routing and SMTP. If no value is specified, the default value is equal to one-half of the maximum transfer threads, rounded down to the nearest integer. By default, domino does not use multiple concurrent threads when transferring messages over Notes routing from one Domino domain to another.
Maximum hop count:
Field Help: The maximum number of times a message can be transferred between servers before delivery fails and domino sends a non-delivery messages.
Low-priority mail routing time range:
Field Help: The time range when domino routes messages marked as low priority. The default is between 12 AM and 6AM.
Low priority delay notification:
Field Help: If you configure the Router to hold low-priority messages until a given time period, message originators may not be aware of the reason for the delay. The Router can generated delay notifications for every low-priority message held., or for specific messages only. Choose on:
Disable -The Router does not notify senders when messages are delayed for priority reasons.
Only if priority changed for policy reasons - The Router notifies senders of priority-related delays only for messages that were designated low-priority as the result of a configured mail rule or size restriction.
Only if user requested low-priority- The Router notifies senders of priority-related delays only for messages which the sender designated as low-priority.
All low-priority messages - The Router notifies senders of priority-related delays for all low-priority messages.
Initial transfer retry interval:
Field Help: The time (in minutes) that the Router waits after a message transfer failure before retrying the transfer.
The default interval is 15 minutes. Lower values increase the retry attempts per hour and could possibly increase the success rate of routing the messages. Higher values decrease the retry attempts per hour, resulting in longer routing times.
The Router continues attempts to transfer a pending message until the age of the message reaches the configured time-out value (by default, 24 hours). After a message times out, the Router generates a delivery failure report to the sender.
Expired message purge interval:
Field Help: Specifies, in minutes, how often the router checks the MAIL.BOX for expired messages to purge. The default is 15 minutes.
Transfer and delivery delay notifications:
Field Help: Choose whether to send a delay notification to the author of a pending message that was not transferred or delivered within a specified amount of time. For each priority level, define the period of time in the Delay notification intervals fields. This notification differs from the low priority time range delay notifications in that the transfer and deliver settings applies to all messages priorities, and indicates the message is being retried after a failed transfer or delivery attempt. Low priority time range delay notifications are a one-time notification indicating that no attempt is made to transfer a message until the low priority time range.
Choose one:

• Enabled -- To allow the transfer and delivery of Delay notifications.
• Disable -- To prevent the transfer or delivery of Delay notifications.
• 
  

Delay notification intervals: Enter how long (in minutes) a pending message should be in the queue before the Roter will send a delay report to the author. If the interval is reached a second time, a second delay report will be sent.
Specify the amount of time that a high, normal, and low priority message should reside in the message queue before the router sends a Delay report to the author of the message. The default for each priority is four (4) hours.
Specify the amount of time in hours or minutes for High priority mail, Normal priority mail, and Low priority mail.

Rules Condition Component and Description: Message item: Specifies the IBM® Lotus® Notes® message item that the Router examines when evaluating whether to apply a rule. Choose one of the following: Sender, Subject, Body, Importance, Delivery priority, To, CC, BCC, To or CC, Body or subject, Internet domain, Size (in bytes), All documents, Attachment name, Number of attachments, Form, Recipient count, or Any recipient Logical operator or qualifier: Specifies how the Router evaluates the content of the target field. Choose one of the following: contains (for text field values) does not contain (for text field values) is is not is less than (for numeric field values) is greater than (for numeric field values) For example, if you selected the message item Attachment Name, selecting the qualifier "is" defines a rule that acts on all messages having an attached file with a name that exactly matches the name you specify. Field value to check: Specifies the content to search for in the target message item. For example, if the target message item is Attachment Name and the qualifier is "contains," enter .VBS to create a rule that acts on all messages having an attached file with a name containing the string .VBS, including, LOVE-LETTER.VBS, CLICK-THIS.VBS.TXT, and MY.VBS.CARD.EXE. Action name and Description Journal this message: The Router sends a copy of the message to the configured Mail Journaling database and continues routing the message to its destination. Mail journaling must be enabled on the Router/SMTP - Advanced - Journaling tab. Move to database: The Router removes the message from MAIL.BOX and quarantines it in the database specified in the accompanying text field, for example, GRAVEYARD.NSF. The specified database must already exist. The message is not routed to its destination. Placing messages in a quarantine database lets you examine them more closely for viruses or other suspicious content. Don't accept message: IBM® Lotus® Domino® rejects the message, but the Router does not generate a delivery failure report. Depending on the message source, the sender may or may not receive an NDR or other indication that the message was not sent. When Domino does not accept an incoming SMTP message it returns an SMTP "permanent error" code to the sending server, indicating that the message was rejected for policy reasons. SMTP permanent errors (500-series errors) indicate error types that will recur if the sender attempts to send to the same address again. Depending on the configuration of the sending client and server, the message originator may then receive a Delivery Failure report. For messages received over Notes routing, Domino returns a Delivery Failure Report indicating that the message violated a mail rule. For messages deposited by a Notes client, the sending client displays an error indicating that the message violated a mail rule. Don't deliver message: Domino accepts the message, but rather than sending it to its destination, it processes the message according to one of the following specified options: Silently delete - Domino deletes the message from MAIL.BOX with no indication to the sender or recipient. Send NDR - Domino returns the message to the sender. The MIME and Notes rich text versions of messages sent from a Notes client result in separate delivery failure reports. Change routing state: Domino accepts the message, but does not deliver the message. Instead, it marks it as held, changing the value of the RoutingState item on the message to HOLD. This change to the routing state of the message causes the Router to retain the message in MAIL.BOX indefinitely, pending administrative action.

Related information

Read more »

Posted in: Lotus administrator,Lotus Dominino,Lotus Notes,policy

How to restore contacts if deleted from Personal Address Book after synchronizing with mail file

Question

In Lotus Notes® Client a customer has synchronized his contacts with Lotus® Domino® Web Access (iNotes™ Web Access) by opening the mail file in Notes and selecting Actions > Synchronize Address Book. This procedure copies the contacts from the Personal Address Book database into the mail file for use with Domino Web Access (DWA).
The customer then inadvertently deletes the contacts from the Personal Address Book. In an attempt to retrieve the contacts from the mail file, the customer synchronizes again from the mail file in Notes, causing the removal of the contacts from the mail file as well. Is there any method of restoring the deleted contacts?

Answer

Once the contact documents are deleted from the Personal Address Book, any synchronization will remove them from the mail file as well, due to the deletion stubs.

A method for restoring the contacts in this scenario is as follows.

1. Retrieve a backup of the mail file containing the contacts, then open the mail file in Notes and select View from the menu.
2. Hold down the SHIFT + CTRL keys simultaneously and select Go To. This action adds many hidden views (indicated by parentheses) to the dialog box that pops up.
3. Scroll down and select the ($Contacts) view from the list.
4. You should see the contacts there.
5. Select Edit > Select All.
6. Select Edit > Copy
7. Open the Personal Address Book.
8. Select Edit > Paste.

The contacts should now appear in both the Personal Address Book and the mail file.

If the mail file is now synchronized, it will remove the set of contacts from the mail file and replace them with the copies in the Personal Address Book, so they will be synchronized again.

Related information

Cross reference information

Segment	Product	Component	Platform	Version	Edition
Messaging Applications	Lotus End of Support Products	Lotus Domino Web Access

Read more »

Posted in: Lotus administrator,Lotus Notes

Configure Postfix to Send Mail Using an External SMTP Server

There are many reasons why you would want to configure Postfix to send email using an external SMTP provider such as Google Apps (Gmail), Mandrill, SendGrid, Amazon SES, or any other SMTP server. One reason is to avoid getting your mail flagged as spam if your current server’s IP has been added to a spam list.
In this tutorial, you will learn how to install and configure a Postfix server to send email through Google Apps, Mandrill, or SendGrid.

Prerequisites

Before starting this tutorial, you should have:

• Debian 7 installed on your Linode
• Your fully qualified domain name (FQDN)
• All updates installed :
  

  1	sudo apt-get update

• A valid username and password for the SMTP mail provider, such as Google Apps, Mandrill, or SendGrid
• Make sure the libsasl2-modules package is installed and up to date:
  

  1	sudo apt-get install libsasl2-modules

This guide is written for a non-root user. Commands that require elevated privileges are prefixed with sudo. If you’re not familiar with the sudo command, you can check our Users and Groups guide.

Installing Postfix

In this section, you will install Postfix and set the domain and hostname.

1. Install Postfix with the following command:
   

   1	sudo apt-get install postfix

2. During the installation, a prompt will appear asking for your General type of mail configuration.
   
   Select Internet Site.
   
3. Enter the fully qualified name of your domain, fqdn.example.com.
   
   
4. Once the installation is finished, open the /etc/postfix/main.cf file with your favorite text editor:
   

   1	sudo nano /etc/postfix/main.cf

5. Make sure that the myhostname parameter is configured with your server’s FQDN:
   

   /etc/postfix/main.cf

   1	myhostname = fqdn.example.com

Configuring SMTP Usernames and Passwords

Usernames and passwords are generally stored in a file called sasl_passwd in the /etc/postfix/ directory. In this section, you’ll add your external mail provider credentials to this file and to Postfix.
If you want to use Google Apps, Mandrill, or SendGrid as your SMTP provider, you may want to reference the appropriate example while working on this section.

1. Open or create the /etc/postfix/sasl_passwd file, using your favorite text editor:
   

   1	sudo nano /etc/postfix/sasl_passwd

2. Add your destination (SMTP Host), username, and password in the following format:
   

   /etc/postfix/sasl_passwd

   1	[mail.isp.example] username:password

   If you want to specify a non-default TCP Port (such as 587), then use the following format:
   

   /etc/postfix/sasl_passwd

   1	[mail.isp.example]:587 username:password

3. Create the hash db file for Postfix by running the postmap command:
   

   1	sudo postmap /etc/postfix/sasl_passwd

If all went well, you should have a new file named sasl_passwd.db in the /etc/postfix/ directory.

Securing Your Password and Hash Database Files

The /etc/postfix/sasl_passwd and the /etc/postfix/sasl_passwd.db files created in the previous steps contain your SMTP credentials in plain text.
For security reasons, you should change their permissions so that only the root user can read or write to the file. Run the following commands to change the ownership to root and update the permissions for the two files:

1 2	sudo chown root:root /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db sudo chmod 0600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db

Configuring the Relay Server

In this section, you will configure the /etc/postfix/main.cf file to use the external SMTP server.

1. Open the /etc/postfix/main.cf file with your favorite text editor:
   

   1	sudo nano /etc/postfix/main.cf

2. Update the relayhost parameter to show your external SMTP relay host. Important: If you specified a non-default TCP port in the sasl_passwd file, then you must use the same port when configuring the relayhost parameter.
   

   /etc/postfix/main.cf

   1 2	# specify SMTP relay host relayhost = [mail.isp.example]:587

   Check the appropriate Google Apps, Mandrill, or SendGrid section for the details to enter here.
   

3. At the end of the file, add the following parameters to enable authentication:
   

   /etc/postfix/main.cf

   1 2 3 4 5 6 7 8 9 10

   # enable SASL authentication smtp_sasl_auth_enable = yes # disallow methods that allow anonymous authentication. smtp_sasl_security_options = noanonymous # where to find sasl_passwd smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd # Enable STARTTLS encryption smtp_use_tls = yes # where to find CA certificates smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

4. Save your changes.
5. Restart Postfix:
   

   1	sudo service postfix restart

Testing Postfix

The fastest way to test your configuration is to send an email to any unrelated email address, using the mail command:

1	echo "body of your email" | mail -s "This is a Subject" -a "From: you@example.com" recipient@elsewhere.com

Alternatively, you can use Postfix’s own sendmail implementation, by entering lines similar to those shown below:

1 2 3 4 5

sendmail recipient@elsewhere.com From: you@example.com Subject: Test mail This is a test email .

Examples of Postfix Configurations with Different Providers

This section shows you settings for some popular mail services you can use as external SMTP servers. You may have to do some fine-tuning on your own to avoid Postfix logins being flagged as suspicious.

Settings for Google Apps

Use these settings for Google Apps.

1. For /etc/postfix/sasl_passwd, use the following configuration with your own credentials:
   

   /etc/postfix/sasl_passwd

   1	[smtp.gmail.com]:587 <USERNAME@gmail.com>:PASSWORD

   If you are using Google Apps with your own domain, configure /etc/postfix/sasl_passwd with:
   

   /etc/postfix/sasl_passwd

   1	[smtp.gmail.com]:587 <USERNAME@yourdomain.com>:PASSWORD

2. For /etc/postfix/main.cf, use the following relayhost:
   

   /etc/postfix/main.cf

   1	relayhost = [smtp.gmail.com]:587

3. Create the hash db file for Postfix by running the postmap command:
   

   1	sudo postmap /etc/postfix/sasl_passwd

4. Restart Postfix:
   

   1	sudo service postfix restart

Settings for Mandrill

Use these settings for Mandrill.

1. For /etc/postfix/sasl_passwd, use the following configuration with your own credentials:
   

   /etc/postfix/sasl_passwd

   1	[smtp.mandrillapp.com]:587 USERNAME:API_KEY

2. For /etc/postfix/main.cf, use the following relayhost:
   

   /etc/postfix/main.cf

   1	relayhost = [smtp.mandrillapp.com]:587

3. Create the hash db file for Postfix by running the postmap command:
   

   1	sudo postmap /etc/postfix/sasl_passwd

4. Restart Postfix:
   

   1	sudo service postfix restart

Settings for SendGrid

Use these settings for SendGrid.

1. For /etc/postfix/sasl_passwd, use the following configuration with your own credentials:
   

   /etc/postfix/sasl_passwd

   1	[smtp.sendgrid.net]:587 USERNAME:PASSWORD

2. For /etc/postfix/main.cf, use the following relayhost:
   

   /etc/postfix/main.cf

   1	relayhost = [smtp.sendgrid.net]:587

3. Create the hash db file for Postfix by running the postmap command:
   

   1	sudo postmap /etc/postfix/sasl_passwd

4. Restart Postfix:
   

   1	sudo service postfix restart

Read more »

Posted in: Postfix

Use Telnet to test SMTP communication on Exchange servers(Copy: https://technet.microsoft.com/en-us/library/bb123686(v=exchg.160).aspx)

Exchange 2016

Other Versions

  Applies to: Exchange Server 2016
Topic Last Modified: 2016-08-09
Learn how to use Telnet to test SMTP connectivity and mail flow on Exchange servers.
You can use Telnet to test Simple Mail Transfer Protocol (SMTP) communication between messaging servers. SMTP is the protocol that's used to send email messages from one messaging server to another. Using Telnet can be helpful if you're having trouble sending or receiving messages because you can manually send SMTP commands to a messaging server. In return, the server will reply with responses that would be returned in a typical connection. These results can sometimes help you to figure out why you can't send or receive messages.
You can use Telnet to test SMTP communication to:

• Test mail flow from the Internet into your Exchange organization.
  
• Test mail flow from your Exchange to another messaging server on the Internet.
  

Tip:

Did you know that, instead of using Telnet to test SMTP connectivity, you can use the Microsoft Remote Connectivity Analyzer at https://testconnectivity.microsoft.com/? With the Remote Connectivity Analyzer, you can choose the connectivity test you want to do, in this case Inbound SMTP Email, and follow the instructions shown. It'll step you through the information you need to enter, run the test for you, and then give you the results. Give it a try!

What do you need to know before you begin?

• Estimated time to complete: 15 minutes
  
• Exchange permissions don't apply to the procedures in this topic. These procedures are performed in the operating system of the Exchange server or a client computer.
  
• This topic shows you how to use Telnet Client, which is included with Windows. Third-party Telnet clients might require syntax that's different from what's shown in this topic.
  
• The steps in this topic show you how to connect to an Internet-facing server that allows anonymous connections using TCP port 25. If you're trying to connect to this server from the Internet, you need to make sure your Exchange server is reachable from the Internet on TCP port 25. Similarly, if you're trying to reach a server on the Internet from your Exchange server, you need to make sure your Exchange server can open a connect to the Internet on TCP port 25.
  
• You might notice some Receive connectors that use TCP port 2525. These are internal Receive connectors and aren't used to accept anonymous SMTP connections.
  
• If you're testing a connection on a remote messaging server, you should run the steps in this topic on your Exchange server. Remote messaging servers are often set up to make sure the IP address where the SMTP connection is coming from matches the domain in the sender's email address.
  
• For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard shortcuts in the Exchange admin center.
  

Tip:
Having problems? Ask for help in the Exchange forums. Visit the forums at: Exchange Server, Exchange Online, or Exchange Online Protection.

How do you do this?

Step 1: Install the Telnet Client on your computer

On most versions of Windows, you'll need to install the Telnet client before you can use it. To install it, see Install Telnet Client.

Step 2: Find the FQDN or IP address of the destination SMTP server

To connect to an SMTP server by using Telnet on port 25, you need to use the fully-qualified domain name (FQDN) (for example, mail.contoso.com) or the IP address of the SMTP server. If you don't know the FQDN or IP address, you can use the Nslookup command-line tool to find the MX record for the destination domain.

Note:
Network policies might prevent you from using the Nslookup tool to query public DNS servers on the Internet. As an alternative, you can use one of the freely-available DNS lookup or MX record lookup web sites on the Internet.

1. At a command prompt, type nslookup, and then press Enter. This command opens the Nslookup session.
   
2. Type set type=mx, and then press Enter.
   
3. Type the name of the domain for which you want to find the MX record. For example, to find the MX record for the fabrikam.com domain, type fabrikam.com., and then press Enter.
   

   Note:
   When you use a trailing period ( . ), you prevent any default DNS suffixes from being unintentionally added to the domain name.

   The output of the command looks like this:
   
   fabrikam.com mx preference=10, mail exchanger = mail1.fabrikam.com
   fabrikam.com mx preference=20, mail exchanger = mail2.fabrikam.com
   mail1.fabrikam.com internet address = 192.168.1.10
   mail2 fabrikam.com internet address = 192.168.1.20
   

   You can use any of the host names or IP addresses that are associated with the MX records as the destination SMTP server. A lower value for preference (preference = 10 vs. 20) indicates a preferred SMTP server. Multiple MX records and different values of preference are used for load balancing and fault tolerance.
   
4. When you're ready to end the Nslookup session, type exit, and then press Enter.
   

Step 3: Use Telnet on Port 25 to test SMTP communication

In this example, we're going to use the following values. When you run the commands on your server, replace these values with ones for your organization's SMTP server, domain, etc.

• Destination SMTP server   mail1.fabrikam.com
  
• Source domain   contoso.com
  
• Sender's e-mail address   chris@contoso.com
  
• Recipient's e-mail address   kate@fabrikam.com
  
• Message subject   Test from Contoso
  
• Message body   This is a test message
  

Tip:

The commands in the Telnet Client aren't case-sensitive. The SMTP command verbs in this example are capitalized for clarity. You can't use the backspace key in the Telnet session after you connect to the destination SMTP server. If you make a mistake as you type an SMTP command, you need to press Enter, and then type the command again. Unrecognized SMTP commands or syntax errors result in an error message that looks like this: 500 5.3.3 Unrecognized command

1. Open a Command Prompt window, type telnet, and then press Enter.
   This command opens the Telnet session.
   
2. Type set localecho, and then press Enter.
   This optional command lets you view the characters as you type them, and it might be required for some SMTP servers.
   
3. Type set logfile <filename>, and then press Enter.
   This optional command enables logging and specifies the log file for the Telnet session. If you only specify a file name, the log file is located in the current folder. If you specify a path and file name, the path needs to be on the local computer, and you might need to enter the path and file name in the Windows DOS 8.3 format (short name with no spaces). The path needs to exist, but the log file is created automatically.
   
4. Type OPEN mail1.fabrikam.com 25, and then press Enter.
   
5. Type EHLO contoso.com, and then press Enter.
   
6. Type MAIL FROM:chris@contoso.com, and then press Enter.
   
7. Type RCPT TO:kate@fabrikam.com NOTIFY=success,failure, and then press Enter.
   The optional NOTIFY command specifies the particular delivery status notification (DSN) messages (also known as bounce messages, nondelivery reports, or NDRs) that the SMTP is required to provide. In this example, you're requesting a DSN message for successful or failed message delivery.
   
8. Type DATA, and then press Enter.
   
9. Type Subject: Test from Contoso, and then press Enter.
   
10. Press Enter again.
    A blank line is needed between the Subject: field and the message body.
    
11. Type This is a test message, and then press Enter.
    
12. Type a period ( . ), and then press Enter.
    
13. To disconnect from the SMTP server, type QUIT, and then press Enter.
    
14. To close the Telnet session, type quit, and then press Enter.
    

Here's what a successful session using the steps above looks like:

C:\Windows\System32> telnet

Microsoft Telnet> set localecho
Microsoft Telnet> set logfile c:\TelnetTest.txt
Microsoft Telnet> OPEN mail1.fabrikam.com 25

220 mail1.fabrikam.com Microsoft ESMTP MAIL Service ready at Fri, 5 Aug 2016 16:24:41 -0700
EHLO contoso.com
250-mail1.fabrikam.com Hello [172.16.0.5]
250-SIZE 37748736
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-X-ANONYMOUSTLS
250-AUTH NTLM
250-X-EXPS GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 XRDST
MAIL FROM: chris@contoso.com
250 2.1.0 Sender OK
RCPT TO: kate@fabrikam.com NOTIFY=success,failure
250 2.1.5 Recipient OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
Subject: test
   
This is a test message.
.
250 2.6.0 <c89b4fcc-3ad1-4758-a1ab-1e820065d622@mail1.fabrikam.com> [InternalId=5111011082268, Hostname=mail1.fabrikam.com] Queued mail for delivery
QUIT
221 2.0.0 Service closing transmission channel

Step 4: Success and error messages in the Telnet Session

This section provides information about the success and failure responses to the commands that were used in the previous example.

Note:
The three-digit SMTP response codes that are defined in RFC 5321 are the same for all SMTP messaging servers, but the text descriptions in the responses might be slightly different.

SMTP reply codes

SMTP servers respond to commands with a variety of numerical reply codes in the format of x.y.z where:

• X indicates whether the command was good, bad, or incomplete.
• Y indicates the kind of response that was sent.
• Z provides additional information about the command

When a response is received by the server that opened the connection, it can tell whether the remote server accepted the command and is ready for the next one, or if an error occurred.
The first digit (X) is particularly important to understand because it indicates the success or failure of the command that was sent. Here are its possible values, and their meanings.

 

Reply code	Meaning
2.y.z	The command that was sent was successfully completed on the remote server. The remote server is ready for the next command.
3.y.z	The command was accepted but the remote server needs more information before the operation can be completed. The sending server needs to send a new command with the needed information.
4.y.z	The command wasn't accepted by the remote server for a reason that might be temporary. The sending server should try to connect again later to see if the remote server can successfully accept the command. The sending server will continue to retry the connection until either a successful connection is completed (indicated by a 2.y.z code) or fails permanently (indicated by a 5.y.z code). An example of a temporary error is low storage space on the remote server. Once more space is made available, the remote server should be able to successfully accept the command.
5.y.z	The command wasn't accepted by the remote server for a reason that is isn't recoverable. The sending server won't retry the connection and will send a non-delivery report back to the user who sent the message. An example of an unrecoverable error is a message that's sent to an email address that doesn't exist.

The table above is based on information provided by RFC 5321 (Simple Mail Transfer Protocol), section 4.2.1. Additional information, including descriptions of the second (Y) and third (Z) digits of SMTP reply codes is included in this section, and in sections 4.2.2 and 4.2.3.

OPEN command

Successful response   220 mail1.fabrikam.com Microsoft ESMTP MAIL Service ready at <day-date-time>
Failure response   Connecting to mail1.fabrikam.com...Could not open connection to the host, on port 25: Connect failed
Possible reasons for failure

• The destination SMTP service is unavailable.
  
• Restrictions on the destination firewall.
  
• Restrictions on the source firewall.
  
• Incorrect FQDN or IP address for the destination SMTP server.
  
• Incorrect port number.
  

EHLO command

Successful response   250 mail1.fabrikam.com Hello [<sourceIPaddress>]
Failure response   501 5.5.4 Invalid domain name
Possible reasons for failure

• Invalid characters in the domain name.
  
• Connection restrictions on the destination SMTP server.
  

Note:

EHLO is the Extended Simple Message Transfer Protocol (ESMTP) verb that's defined in RFC 5321. ESMTP servers can advertise their capabilities during the initial connection. These capabilities include the maximum accepted message size and supported authentication methods. HELO is the older SMTP verb that is defined in RFC 821. Most SMTP messaging servers support ESMTP and EHLO. If the non-Exchange server that you're trying to connect to doesn't support EHLO, you can use HELO instead.

MAIL FROM command

Successful response   250 2.1.0 Sender OK
Failure response   550 5.1.7 Invalid address
Possible reasons for failure   A syntax error in the sender's e-mail address.
Failure response   530 5.7.1 Client was not authenticated
Possible reasons for failure   The destination server doesn't accept anonymous message submissions. You receive this error if you try to use Telnet to submit a message directly to a Mailbox server that doesn't have a Receive connector that's configured to accept anonymous connections.

RCPT TO command

Successful response   250 2.1.5 Recipient OK
Failure response   550 5.1.1 User unknown
Possible reasons for failure   The specified recipient doesn't exist.

Read more »

Posted in: Chec Mail,Exchange,Lotus Dominino,Lotus Notes

Reset Domain Administrator Password

The following method has been tested to work on both Server 2003 and Server 2008 Domain Controllers

• Download SRVANY and INSTSRV, which are part of the Windows 2003 Resource Kit
• Ensure you have the Directory Service Restore Mode Administrator password, restart the server in Directory Service Restore Mode, and log in as administrator
  • If you do not have have the Administrator Password, you can attempt to get it through one of these methods
• Create the folder: C:\reset\
  • Copy srvany.exe, instsrv, and cmd.exe(Located in C:\system32) to the C:\reset\
• Open a command prompt and enter the following commands
  • CD “C:\reset”
  • instsrv PassRecovery “C:\reset\srvany.exe”
• Run regedit.exe and navigate to HKLM\System\CurrentControlSet\Services\PassRecovery
• Create a subkey called: Parameters
  • Create a new string value (REG_SZ)
    1. Name: Application
    2. Value: C:\reset\cmd.exe
  • Create a new string value (REG_SZ) where <password> is the desired password (Must Meet Password Policy Requirements)
    1. Name: AppParameters
    2. Value: /k net user administrator <password> /domain
• Open Services and Open the Properties for the PassRecovery Service
  • On the General tab, ensure the startup type is Automatic
  • On the Log On tab, ensure the option is checked to: Allow service to interact with desktop
• Restart the server normally, and log in with the password you specified
• Uninstall SRVANY by entering the following commands at a command prompt:
  • net stop PassRecovery
  • sc delete PassRecovery
• Delete C:\reset\

Read more »

Posted in: Account Admin/Access Control,Active Directory

Lotus Notes 8.5: How to reset forgotten user id password

Lotus Notes 8.5: How to reset forgotten user id password

I am by no stretch of the imagination a Lotus Notes expert but I do have to support it on occasion as part of my system admin duties.  The other day one my users said he couldn’t log on to his Lotus Notes client.  Usually my first inclination is to assume the person forgot his password and to reset the user id password.  No big deal.  The thing is we had recently upgraded to Lotus Notes/Domino 8.5.1 from 8.0 and when I went to look for the familiar options in Lotus Domino something had changed.
I started reading the documentation and from what I gathered Lotus Notes 8.5 gives you two main methods to manage your user passwords.  The new method introduced in version 8.5 is the Notes ID Vault which is supposed to make managing user IDs much easier.  Since I didn’t have this option configured I had to do it ‘old school’.  But like I said earlier - something changed in Domino 8.5 (I hate it when IBM does that).  Again the documentation does explain how to do it but it was not as step-by-step as I would have liked.  Anyway, the following worked for me.

First, the Lotus Administrator has to:

• Run Lotus Domino Administrator
• Click Configuration tab, Extract Recovery Password

 

• Enter your admin password

• Select the user’s ID file

•   Lotus will generate a recovery password. Make note of password.

 

Second, the user has to:

• Run Lotus Notes
• Click Exit (Not very intuitive is it?).  (Author’s note: from what I read in the documentation if you enter the wrong password then click the ‘Log In’ button it is supposed to give you the ‘forgot password’ option but that does not work for the majority of my users)

• Select ‘Try to recover your password’ then click OK

• Enter the recovery password generated earlier in Lotus Admin

• Select the user’s ID file

• The user will be prompted to enter a new password

That’s it… if successful the user will be able to log in to Lotus Notes.

Read more »

Posted in: Lotus Dominino,Lotus Notes