> 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.
>
See, that is what I don't understand. Imagine you have three domains,
domain1/2/3.tld.
all of them could have an MX entry like this:
IN MX 10 server.yetanotherdomain.org
and that would be 100% correct and compliant with the RFCs.
You can then add the IP of that server to those domains SPF record, add
domainkeys and whatnot.
IF any receiving mail server has a problem with server.yetanotherdomain.org
sending in the name of either of your three domains, then I would argue that
that receiving mail server does not conform to the RFCs in question.
Granted, if, for any reason, someone explicitly wants that sort of setup where
the MX for domain1.tld is of that domain, then that is a different story. But
that is just a (valid) subset of the more generic (also 100% valid) way this
can be implemented.
So, I guess it really comes down to a decision of: Do you want to comply with
the, let's say "not really necessary, but of course valid" request of your
clients or do you fall back on the more generic way the RFCs specify how mail
works?
Or in other words: To my knowledge, there is nothing in the RFCs that prevents
you from doing what I described above. Of course, it's still your choice.
Martin
---------------------------------------------------------------------------------
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
