Re: [9fans] Setting up Mail in Acme on the Raspberry Pi.

[Mats Olsson <plan9.meo@gmail.com>]

Hi again!

The DNS problem only occurs when I try to send from the gmail account
I'm using now to the Swedish domain: "spray.se". An empty message
comes through ending with a dot . and that's it. Thanks for all your
effort to help me out!

Kind Greetings,
Mats

2014-11-06 20:12 GMT+01:00, Steffen Nurpmeso <sdaoden@yandex.com>:
> erik quanstrom <quanstro@quanstro.net> wrote:
>  |On Wed Nov  5 13:20:02 EST 2014, sdaoden@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
>
>