Hi Eric, Please check out the following urls, hotmail for example simultaneously choose to treat the RFCs a standards and guidelines and simply cherry pick the ones they like:
http://mail.live.com/mail/policies.aspx http://www.spamcop.net/fom-serve/cache/22.html Also it is common knowledge that Yahoo flout the RFCs in so much as the 'spam avoidance' techniques are concerned. Simply Google it. Your final point, there can only be one primary domain: quite true, a Primary domain Per IP Address... really the point is moot. As I said before, I need to support multiple email domains FULLY WITHIN THE RFC on a single machine. To that end I am simply going to install multiple smtpd Daemons, job done. Thanks for the input however, it was interesting. Fin -----Original Message----- From: Eric Shubert [mailto:[email protected]] Sent: 28 October 2010 19:13 To: [email protected] Subject: [qmailtoaster] Re: smtp greeting banner frustration You say you have a "requirement to be able to prove isolation of domains". That's a pretty broad term, meaning what exactly? Is "isolation of domains" defined anywhere? I think that using DNSStuff to verify isolation is pretty lame, and I expect you'd agree. Depending on how much isolation is really required, the use of virtual domains might not be acceptable. This requirement appears to "fly in the face" of virtual domains. In order for any host to be able to do what you're saying in order to pass the "DNSStuff test", there would (of course) need to be a mapping of some sort defined between an interface and domain. How else would the server know which name to use? There's no other bit of data (that I know of) which could be used to tell which domain the message (with no address yet identified) will be sent to. Some custom coding would be required to accomplish this. I think the best solution for your situation is to set up a QMT VM for each domain with such (lame as they may be) requirements. And be sure to charge a premium for such a configuration. ;) Regarding RFCs, I disagree that they are 'guidelines'. I'd like to see any official document from Hotmail, Yahoo, Google et al that says otherwise. Also, you quote RFC2821 section 4.3.1: > 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. Notice that it says *primary* domain name. There can be only one *primary* domain name, no? -- -Eric 'shubes' On 10/28/2010 09:34 AM, Edward Finlayson wrote: > 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:[email protected]] > Sent: 28 October 2010 16:36 > To: [email protected] > 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. > ---------------------------------------------------------------------------- ----- 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]
