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 <sdao...@yandex.com>: > 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 > >
