[qmailtoaster] Re: smtp greeting banner frustration
On 10/28/2010 03:31 AM, Edward Finlayson wrote: Hi Everyone, I was wondering if any list member would be able to help. I have a number of domains, on separate IP addresses but whenever a server connects to the server it receives the same SMTP greeting: 220 *cpa2.localdomain* - Welcome to Qmail Toaster Ver. 1.3 SMTP Server ESMTP Whereas the hostname should only be the one which reverse resolves in DNS i.e. mail.domain.com Not exactly true. Does anyone know how I would go about enabling this compliance with RFC821 4.3 and RFC2821 4.3.1 Any help will be gratefully received, Fin What RFC 2821 says is this: An SMTP server MAY verify that the domain name parameter in the EHLO command actually corresponds to the IP address of the client. However, the server MUST NOT refuse to accept a message for this reason if the verification fails: the information about verification failure is for logging and tracing only. So you see, the name in the EHLO message merely needs to be resolvable. Change the name in your /var/qmail/control/smtpgreeting file to be any one of your valid hosts (an MX name is good), and you should have no problem. -- -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] 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
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. 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
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: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
RE: [qmailtoaster] Re: smtp greeting banner frustration
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:mar...@waschbuesch.de] Sent: 28 October 2010 17:46 To: qmailtoaster-list@qmailtoaster.com 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: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: smtp greeting banner frustration
. ... 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. - 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
RE: [qmailtoaster] Re: smtp greeting banner frustration
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:e...@shubes.net] Sent: 28 October 2010 19:13 To: qmailtoaster-list@qmailtoaster.com 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
[qmailtoaster] Re: smtp greeting banner frustration
Hey Edward, I'm not seeing any real RFC violations in those links. Spamcop claims that MS isn't following the RFC, but I believe that is a false claim. I don't believe there's anything in an RFC about how headers are *displayed*. I also googled it, and came up with nothing. I don't believe that any of the big mailers are in violation of any RFCs pertaining to email. That's not to say that they haven't implemented non-standard methods to mitigate spam. My point here is that your requirement is not a matter of RFC compliance. There is nothing in an RFC that says such. It may be a requirement for isolation and for your clients, but it is not a requirement for RFC compliance. -- -Eric 'shubes' On 10/28/2010 11:42 AM, Edward Finlayson wrote: 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:e...@shubes.net] Sent: 28 October 2010 19:13 To: qmailtoaster-list@qmailtoaster.com 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? - 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
