[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Federated, decentralised communication on the internet (was: domain names, was: hostname)

On Wed 21 Mar 2018 at 16:21:44 (-0400), Greg Wooledge wrote:
> On Wed, Mar 21, 2018 at 02:53:47PM -0500, David Wright wrote:
> >       HELO dotlessdomainname
> >       HELO dotcontaining.home
> > 
> > I want someone to explain to me why having a dot is better then not
> > having a dot in deciding whether a submitter is genuine. And
> > without the politics.
> My understanding: the SMTP receiver will use whatever heuristics it
> finds appropriate to avoid receiving spam.
> One heuristic that is commonly used is to reject all messages where
> the HELO doesn't even syntactically qualify as a valid FQDN -- in other
> words, has no dot in it.
> Another heuristic that is commonly used is to perform a DNS query on
> the HELO string, and reject it if it's not a valid FQDN based on DNS.
> The first heuristic is much less expensive to perform, as it does not
> involve sending a DNS query and waiting for the response.  The test
> is simply a syntactic scan of the input string that it already has.
> Of course, a given receiver may choose to perform BOTH tests.

Sure, so in my case, I'd be forced to find out what my router's
hostname is so that I can quote a hostname that will resolve to the
address that I woud be posting on. Currently this appears to be
but it changes at random times governed by I know not what.
But wait: to post from any of my machines, they all have to have
ip70-179-161-106.fv.ks.cox.net in /etc/hosts so that exim uses it
as the HELO string. This to an ISP that knows which wire I'm
connected to at their end.

And what's achieved by this when the next step is AUTH?

> For the person who is trying to send legitimate outgoing mail, obviously
> you don't want your messages to be rejected as spam.  So it behooves you
> to make sure your message complies with not only the applicable standards
> (SMTP = RFC 2821, etc.), but also with the known practices of potential
> receivers.  Which means, among other things, having a HELO string that
> won't cause your message to be dropped as probable spam.

Naturally. The smarthost I use is not bothered about the HELO, only
the login/password pair that follows in the conversation. That's
its known practice.


Reply to: