Chapter 2
2-1
2.1 Basic Function
2.1.1 Authentication at TX
0020-7895
When the mail server is set on the internet, you need to prevent from Third Party Mail Relay that the third party uses the false name. Third Party Mail Relay means
that the third party sends large amount of spam mails using the mail server which other people are operating. If you do not take any measures for this, resources
like server and network lines are exhausted and at the same time, you will get the claim from the user who received the spam mail. As a measure, the authentication
operation when SMTP transmission is prepared.
In case of the inner network (LAN), you can prevent from Third Party Mail Relay by restricting the IP address and the domain name. In order to send from the
outside domain using the mail address or securely use the mail server set on the internet which the provider prepares, the authentication is indispensable at the
transmission. This machine uses two authentication methods, POP Before SMTP and SMTP AUTH and they enable to send i-FAX and e-mail to SMTP server
which requests the sender's authentication.
POP before SMTP
With this method, before SMTP transmission is performed, the POP server is logged into. SMTP transmission can only be continued once the POP server has
confirmed the IP address of the connected client as authorized within a specific period of time. After user authentication is carried out at the POP server, the au-
thenticated client IP address is relayed to the SMTP server, where it is processed. The process requires a certain amount of time. Taking this processing time into
consideration, there is an idle period of 300msec, from POP authentication to the start of SMTP transmission. If a POP before SMTP transmission is generated
during POP reception, POP authentication is made to wait until the reception is finished and then POP authentication and SMTP transmission are performed. Errors
occurring while the POP server is connected are treated as transmission errors.
With regard to the actual programming, all that is necessary is for
System Settings > Network Settings > E-Mail/ I-Fax > Authent./ Encryption > POP Authen-
tication bofore Sending
to be set to ON.
Related new user error codes are #810 and #813. For details, refer to Troubleshooting.
SMTP AUTH
In SMTP AUTH, user authentication is performed when the SMTP server is connected, so that mail can only be received from registered users. This method was
standardized in March, 1999, as RFC2554. SMTP AUTH uses ESMTP protocol, which is an extension of SMTP, and uses the SASL (Simple Authentication and
Security Layer) authentication mechanism, standardized as RFC2222, to authenticate the user by sending the user name and password information in response to
the server challenge data.
<Authentication mechanisms>
The SMTP server can have multiple authentication mechanisms and the most suitable authentication mechanism is programmed in accordance with the security
policy decided by the SMTP server administrator. The client E-Mail client application selects the authentication algorithm from among the available authentication
mechanisms and performs authentication upon transmission.
This model supports the following five types of authentication mechanism.
CRAM-MD5
Challenge-Response Authentication Mechanism, computed by using the key-protected MD5 algorithm by HMAC-MD5 (RFC2104)
NTLM
Windows NT authentication method
User name must be set in the form 'username@NTdomainname'
E.g.:
Windows2000 or earlier: username\\CANON (domain name may be omitted, depending on the environment)
Windows2000: [email protected] (domain name may be omitted, depending on the environment)
GSSAPI
Authentication system using Kerberos Version 5 (RFC1510)
User name must be set in the form 'username@realmname'.
(In Exchange2000, realm name = domain name)
PLAIN
Assumes that user name and password are sent as plain text (BASE64 encoded) and the communication packet is encoded. (RFC2595) Allows secure authentica-
tion when used in combination with the encoded transmission described later.
LOGIN
Sends the user name and password as plain text (BASE64 encoded). Actual transaction is the same as with PLAIN. Similarly, allows secure authentication when
used in combination with encoded transmission.
<SMTP AUTH transmission operation>
Even if the unit is programmed for transmission with SMTP AUTH, if the mail server does not support SMTP AUTH and the encoding system supported by the
server does not match that supported by this model, SMTP AUTH transmission will not be possible. In that case, even if SMTP AUTH is programmed, transmission
will be by normal SMTP and there will be no transmission error generated. If an unauthenticated mail transmission is attempted to a server that will not allow such
transmission, subsequent SMTP protocols will generate an error in the mail server. Unauthenticated mail can be transmitted to a server that will accept such trans-
mission. These security policies are determined by the server so, even if SMTP AUTH is not programmed, it is impossible to tell whether transmission is possible
without checking with the customer's server administrator.
<Authentication protocol>
Examples of transmission protocol using SMTP AUTH are given below.
The EHLO response from the client tells whether SMTP AUTH is supported by the server and the authentication algorithm being used at that time is described. In
the event that there are multiple authentication algorithms, multiple algorithm names are described. The client selects one of the relayed authentication algorithms
and then relays it on to the server. Server challenge data come from the server and coded data made up from the server challenge data, user name and password are
returned in response for authentication. In general, the authentication algorithm to be used can be selected on the server side and PLAIN and LOGIN authentication
and others which are undesirable from the perspective of security can be blocked by the server setting. (Security policy is determined by the server.)
Server:220 smtp.example.com ESMTP server ready
Client(iR):EHLO ifax.example.com
S: 250-smtp.example.com
S: 250-DSN
S: 250-EXPN
S: 250 AUTH CRAM-MD5 DIGEST-MD5 : <- server declares authentication algorithm
C: AUTH CRAM-MD5 : <- client selects CRAM-MD5
S: 334 : <- server response (subsequently, authentication begins with CRAM-MD5.)
S: PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
S: 235 Authentication successful.
<Authorisation algorithm selection>
Summary of Contents for Color Universal Send Kit-Q1
Page 1: ...SERVICE MANUAL Color Universal Send Kit Q1 JANUARY 21 2009 ...
Page 2: ......
Page 6: ......
Page 9: ...Chapter 1 Specifications ...
Page 10: ......
Page 12: ......
Page 17: ...Chapter 2 Functions ...
Page 18: ......
Page 20: ......
Page 43: ...Chapter 3 Installation ...
Page 44: ......
Page 46: ......
Page 59: ...Chapter 4 Maintenance ...
Page 60: ......
Page 62: ......
Page 94: ......
Page 95: ...Jan 21 2009 ...
Page 96: ......