erik quanstrom <quans...@quanstro.net> wrote:
|On Wed Nov 5 13:20:02 EST 2014, sdao...@yandex.com wrote:
|> Anthony Sorace <a...@9srv.net> wrote:
|>|> I've been looking through the documentation and
|>|> the 9fans archive but I can't get a clear answer on
|>|> what to replace localhost.localdomain with.
|>|
|>|If the recipient's mail server is being strict (but within
|>|the bounds of the RFCs), that name is expected to be
|>|the real, externally-resolvable DNS name of the
|>|system you're sending from. The RFCs used to be more
|>|lax on that point, and some servers still are, but you
|>|shouldn't assume you'll be able to send to arbitrary
|>|endpoints unless you satisfy that.
|>
|> gmail.com shouldn't care at all, so it must be his own SMTP server.
|> (All i know in respect to this is Yandex.(ru|com), which requires
|> that the hostname in the SMTP FROM:<> command _is_ a Yandex
|> address, i.e., _no mismatch_ with _who_ you claim to be, which is
|
|that's not what anthony claimed. he said that if you say
| HELO example.com
|that the following must be true
|(a) dns return an a record for the query example.com, and
Yes -- i think (or say, i'm sure that) gmail.com doesn't take care
for that at all. Neither does Yandex. (Never tried any other
free mail provider, i think they all depend on user
authentication.)
|(b) the ip returned must have a ptr record pointing to example.com
|(this is less enforced these days due to the difficulty of \
|maintaining pointer
|records.)
..So reverse lookups don't even come into play here.
I'm no longer sure wether old-school really hates not to be able
to perform sender verification via DNS, today a lot of pretty
prominent people use those providers themselve.
|i think this is compatible with what you're saying. this doesn't make
|sense to me. i don't do this:
|
|> why i had to invent a *smtp-hostname* variable for the mailer
|> i maintain in order to address the SMTP FROM:<> content directly:
|
|perhaps you're conflating the envelope with the message?
Puh Erik, maybe -- you know, i'm a boche :)
Flying over an official document is the maximum i can handle, just
enough to hammer the most important facts into some long-time
cells, so please excuse possible distortion of terms.
Indeed, looking into RFC 5321 (i have it even in my arena):
o The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of
Section 4.1.4.
o The reserved mailbox name "postmaster" may be used in a RCPT
command without domain qualification (see Section 4.1.1.3) and
MUST be accepted if so used.
So huch! SMTP communication how it actually happens in between me
and the public mail providers is invalid, evil and yuck.
I think i just wanted to add some value to what Anthony said.
Regarding *smtp-hostname*: i think one cannot expect from what
i call a normal user to understand just about anything regarding
any protocol etc. internals -- for no other reasons but missing
context information and maybe add lack of interest. In fact, like
i said above, the same is true for me. Given that this BSD Mail
derivative already has a variable called *hostname*, and that BSD
/ Linux systems have a hostname(1) command (even though POSIX only
specifies uname(1) and documents "the name of this node within an
implementation-defined communications network"; but POSIX.. well)
i decided to name the capability to overwrite the hostname that is
used in the SMTP "MAIL FROM:<>" command *smtp-hostname* (but not
that the manual is really user friendly sofar).
So now i'm stuck with it. But since Matt uses Google the address
used in "MAIL FROM:<>" cannot be the problem anyway, since Google
doesn't care wether the addresses in the messages' From: header
and the SMTP "MAIL FROM:<>" command match or not (the last time
i tried; i admit that the Google message i've posted doesn't
really make sense in this context; oops..).
--steffen
