Hi again Martin, Indeed they could, and I would advocate this very approach myself. However, at the risk of sounding like a broken record: a typical domain that I MUST be able to prove to these clients would look this the DNS snippet below:
########################################## # ========== mydomain.co.uk ========= # ########################################## # Name server records for domain # The format used here does NOT create A or SOA records but does NS Zmydomain.co.uk:ns1.mydomain.co.uk:hostmaster.mydomain.co.uk:2010030401:3600 :1800:1209600:2560 &mydomain.co.uk::ns1.mydomain.co.uk &mydomain.co.uk::ns2.mydomain.co.uk &mydomain.co.uk::ns3.mydomain.co.uk # Mail exchanger data for domain @mydomain.co.uk::mail.mydomain.co.uk.:10:3600 ^104.1.1.127.in-addr.arpa:mail.mydomain.co.uk.:3600 # Alias Records For The Domain +mydomain.co.uk:127.1.1.157:86400 +ftp.mydomain.co.uk:127.1.1.157:86400 +www.mydomain.co.uk:127.1.1.157:86400 +mail.mydomain.co.uk:127.1.1.104:1800 +ns1.mydomain.co.uk.:127.1.1.161:3600 +ns2.mydomain.co.uk.:127.1.1.187:3600 +ns3.mydomain.co.uk.:10.1.1.187:3600 # TYPE 99 SPF # In the record below '\65' is an octal 'byte' representing the length of the string between and including 'v=...' and '...-all:':mydomain.co.uk:99:\65v=spf1 a mx ptr mx\072mail.mydomain.co.uk -all:3600 'mydomain.co.uk:v=spf1 a mx ptr mx\072mail.mydomain.co.uk -all 'mydomain.co.uk:v=spf2.0/pra mx mx\072mail.mydomain.co.uk -all .... As can be seen from the above all the mail service for this domain are within the domain itself, and it is this very format the I must prove to the client via DNSStuff.com which additionally checks the SMTP Greeting banner. Which in turn is WHY I need to have this set to the corresponding value from above before my clients will sign off. Regards, Fin -----Original Message----- From: Martin Waschbüsch [mailto:[email protected]] Sent: 28 October 2010 17:46 To: [email protected] Subject: Re: [qmailtoaster] Re: smtp greeting banner frustration > 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: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------------------- 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: [email protected] For additional commands, e-mail: [email protected]
