well the mails must find their way somehow and even if it can be be set up to work without problems, sending emails with the form user@IP_ADDRESS is not ideal.. So yes, you propably will need to set up a domain.
That doesn't mean that you will necessarily need a DNS server. Although it is technically a violation of the standards to not use MX record for your domain, most servers will not complain if they can simply resolve the domain into an IP address with an A record (i.e. by checking the /etc/hosts table). However it is not something recommended, especially since dns is a simple service to set up (if you really intend to use sendmail, bind's set up would seem like children homework in comparison) and it is obvious a much more scallable solution.
can i use a fakedomain name ?
Since we are talking about your network, you are making the rules, so it's obviously up to you to choose a domain name. The only important thing is it will have to be resolveable from all the hosts of your network, or else there will be a problem.
About the EHLO command here's the specification:
4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
These commands are used to identify the SMTP client to the SMTP
server. The argument field contains the fully-qualified domain name
of the SMTP client if one is available. In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is
available), the client SHOULD send an address literal (see section
4.1.3), optionally followed by information that will help to identify
the client system. y The SMTP server identifies itself to the SMTP
client in the connection greeting reply and in the response to this
command.
A client SMTP SHOULD start an SMTP session by issuing the EHLO
command. If the SMTP server supports the SMTP service extensions it
will give a successful response, a failure response, or an error
response. If the SMTP server, in violation of this specification,
does not support any SMTP service extensions it will generate an
error response. Older client SMTP systems MAY, as discussed above,
use HELO (as specified in RFC 821) instead of EHLO, and servers MUST
support the HELO command and reply properly to it. In any event, a
client MUST issue HELO or EHLO before starting a mail transaction.
These commands, and a "250 OK" reply to one of them, confirm that
both the SMTP client and the SMTP server are in the initial state,
that is, there is no transaction in progress and all state tables and
buffers are cleared.
Syntax:
ehlo = "EHLO" SP Domain CRLF
helo = "HELO" SP Domain CRLF
Normally, the response to EHLO will be a multiline reply. Each line
of the response contains a keyword and, optionally, one or more
parameters. Following the normal syntax for multiline replies, these
keyworks follow the code (250) and a hyphen for all but the last
line, and the code and a space for the last line. The syntax for a
positive response, using the ABNF notation and terminal symbols of
[8], is:
ehlo-ok-rsp = ( "250" domain [ SP ehlo-greet ] CRLF )
/ ( "250-" domain [ SP ehlo-greet ] CRLF
*( "250-" ehlo-line CRLF )
"250" SP ehlo-line CRLF )
ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127)
; string of any characters other than CR or LF
ehlo-line = ehlo-keyword *( SP ehlo-param )
ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
; additional syntax of ehlo-params depends on
; ehlo-keyword
ehlo-param = 1*(%d33-127)
; any CHAR excluding <SP> and all
; control characters (US-ASCII 0-31 inclusive)
Although EHLO keywords may be specified in upper, lower, or mixed
case, they MUST always be recognized and processed in a case-
insensitive manner. This is simply an extension of practices
specified in RFC 821 and section 2.4.1.
