Hi Eric,
Please don't take this the wrong way but we appear to be talking at cross
purposes. You reference the EHLO string which is of course the outbound
string, used to identify a server to the recipient host. I am referring to
the SMTP Greeting String used to identify the local Receiving sever to the
remotely connecting sending server. It is also called the SMTP Banner
depending upon the tech used. The EHLO String, in operational terms, has to
be both correctly authorised for the sending domain (present in SPF and/or
listed as an MX server) and reverse resolvable to the same FQDN. I agree
that this is not in the RFCs but it is certainly affecting sending
reputation when this is not the case. Therefore the sending 'servers' for a
given domain, if they are themselves within that domain, in practical terms,
must forward and reverse resolve mirroring each other and offer both the
correct banner greeting EHLO and SMTP Greeting in order to be considered
complete within the domain space itself.
I am not saying that my requirement is either right or wrong; workable,
practical or even sensible. I concur that the vast majority of clients, my
own included, would never even look at these factors, let alone understand
them. However I have to get this resolved in order to eliminate the
perceived 'issue'.
This is a classic case of business requirement over practicality. I fully
agree with all that has been said with regard to what is possible. However,
I simply have a requirement to be a able to prove isolation of domains for
my clients. Therefore, I have to support what 'should' be possible i.e.
dedicated IP addresses within a name space and the correct identification of
servers at an 'operational level'. This means that I have to have the
correct SMTP greeting for incoming connections. Outbound are in fact already
supported on the system in question via domain dependant EHLO strings.
With regard to your comment re the RFCs, yes I aware of what they state
(otherwise, wouldn't have quoted them myself). However, as these are only
'guidelines' according to Hotmail, Yahoo, Google et al and each tend to
selectively choose which and how to implement them; it is better therefore
to comply as much as possible. to that end RFC821 4.3 specifically states:
4.3. SEQUENCING OF COMMANDS AND REPLIES
The communication between the sender and receiver is intended to
be an alternating dialogue, controlled by the sender. As such,
the sender issues a command and the receiver responds with a
reply. The sender must wait for this response before sending
further commands.
One important reply is the connection greeting. Normally, a
receiver will send a 220 "Service ready" reply when the connection
is completed. The sender should wait for this greeting message
before sending any commands.
Note: all the greeting type replies have the official name of
the server host as the first word following the reply code.
For example,
220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF>
And RFC2821 4.3.1 details:
Note: all the greeting-type replies have the official name (the
fully-qualified primary domain name) of the server host as the first word
following the reply code. Sometimes the host will have no meaningful name.
...
For example,
220 ISIF.USC.EDU Service ready
or
220 mail.foo.com SuperSMTP v 6.1.2 Service ready
...
It is for this reason that I have found myself having to look for a way to
implement this and installation of separate machines is not financially
feasible.
Please note that I am discussing the SMTP Greeting String here not the EHLO
string.
My core problem is that this is stupidly simple for my clients to prove out,
as they are using DNSStuff.com for validation of configuration and this is
the last item that is being highlighted as an 'issue' for them.
Sorry if this mail is a bit long and tiresome, it reflects my own
frustration with the situation.
Regards to all,
Fin
-----Original Message-----
From: Eric Shubert [mailto:e...@shubes.net]
Sent: 28 October 2010 16:36
To: qmailtoaster-list@qmailtoaster.com
Subject: [qmailtoaster] Re: smtp greeting banner frustration
On 10/28/2010 06:58 AM, Edward Finlayson wrote:
> Hi Martin,
>
> Thanks for your response.
>
> Unfortunately, I'm unable to have common mx servers. My clients have to
have
> 'isolation' from one another and insist that all their 'servers' are
within
> their own namespace / IP range. This means that I have to have inbound
SMTP
> servers (mx) within the same domain as everything else and that the IPs
used
> for the servers resolve in both directions. This in turn means, of course,
> that the IPs have to be dedicated to purpose. The knock on effect is that
I
> have to have the SMTP greeting banner for a given IP address match the
> domain to which it is associated in order to comply fully with the RFCs
and
> best practice.
>
This is simply not true. See my previous post on RFC2821.
--
-Eric 'shubes'
----------------------------------------------------------------------------
-----
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
----------------------------------------------------------------------------
-----
Please visit qmailtoaster.com for the latest news, updates, and
packages.
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
