Question : SMTP banner

What should I use as the SMTP banner and as a reply to the HELO command during the header negotiation?

Say my domain name was microsoft.com and my incoming mail was handled by maila.microsoft.com. Should I set my banner to read maila.microsoft.com or to read securityrisk.noinfo.com or to expose my internal DNS structure by bannering with "220 inet-imc-02.redmond.corp.microsoft.com Microsoft.com ESMTP Server Fri, 8 Mar"?

Why have they hidden the type/version number of the product in the banner, is it a security risk to expose the type/version of your mailserver? Even if you wrote it???
                       

Answer : SMTP banner

This form of identification is from simpler friendlier days when there were less users, and -- less abusers. Where you can identify yourself as personal choice, make it personal as in friendly, not as in identifiable to abusers.

For SMTP there are a number of methods available AND used to better assess the parties involved, identity and validity.

For messaging, the main supplemental implementation of servers is to run a reverse dns lookup on sender. If you ain't in both tables, your stuff just won't fly. Note, this is not rule, but rule of thumb for many.  Similarly, caching is used. Once a few messages look good, the servers will only pass along the cached route, using cached ID info, so saving some time on the dns lookups, and avoiding recent hacks and dodging hijacks along the way.

I don't know just what vulnerabilities there are, re:helo specifically, and we shouldn't have too much in open text anyway. General rule of thumb tho': The more you tell, the more vulnerable you get. Think minimally about eSpammers, who want to collect lists of servers, and then lists of recipients. Then revisit your questions based on defending just that.

> to expose my internal DNS structure by bannering

I doubt it, mostly because there are other more reliable methods to retrieve the info more completely. You have to have identifiable routes, or you don't get communication working.

> is it a security risk to expose the type/version of your mailserver?

Sure. Rather simply, if someone had evil packet for one OS, and evil packet for another OS, the more that they know about platforms at other end, the more they can tune in on those vulnerable. This applies to version levels as well.

> Even if you wrote it???

Less of a problem, but there is remaining the underlying OS or, the shared theories used in building what you wrote, for likely your effort was not entirely unique (thus words like buffer overflow can become common, regardless of mfr, it is techniques used, in common, or the underlying lower level SW, or even accompanying SW such as unrelated pieces of an OS)

One could, say, go to CERT and look up all vulnerabilities, then for any that apply, make sure that their free-text headers/banners contain claims to be vulnerable.   Thinking on that, thus the better approach is the opposite; where the less know and told, the better. As far as vulnerabilies go.