Well take the appropriate RFC: 2821.

"These commands are used to identify the SMTP client to the SMTP
server. The argument field contains the fully-qualified domain name
of the SMTP client if one is available. In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is
available), the client SHOULD send an address literal (see section
4.1.3), optionally followed by information that will help to identify
the client system."

Well I think this is enough specific. But you always have to create a email policy for your or your customer needs. So I think the discussion is senseless because mail server configuration is a very individual thing...

True, I took the old one... But here there you also have the exception. There are situations in which it is legal to not send a fqdn... I know of some mailservers (that I leave unnamed ^^) that don't send a fqdn because they belong to a lan and don't have a reverse domain entry. Seems to be standard practice for small office setups. Or maybe it's just a large regional company that gets it wrong...

It is true that you should always do that, but the reality looks a bit different. The question is what the ispcp team thinks would be the best default config for the admin that doesn't check everything as he should. And be it just to prevent them from spaming the forums/ticket system

my opinion about this is. When someone is not able to configure his mail server according to this best practise he should relay through his isps server.

But your are right, thats not a absolute requierement. I've made the experience in Switzerland that most of the administrators are very cooperative. Most of them simply don't know about this whole dns / helo stuff. We offer help to correct the config or to configure the mailserver for using a relay server.

But I think the default config is OK....

I agree totaly with rbtux.
If someone dont want this, he could change this easily.

the sad story...

I'm a big fan of "stick with the standards"-behaviour in most cases. In the discussion here, where the standard install template of postfix is included, I would prefer a more fault tolerant solution. Most big providers in Germany (e.g. Freenet and T-Online) don't use a standards-conform HELO. So would you rather have every single admin change the two lines after installation, or wouldn't it be better to do something like that in the install template:

I agree to that. Like some of us noticed, it's a problem if very big isps dont stick to the standards. It wouldn't help anyone if big isps like t-online, freenet or others can't send emails to a ipscp server just because ispcp (postfix) requires a valid HELO as default setting. And like rbtux wrote... most of the people actually don't know what a HELO is. A lot of them have problems installing ispCP, so why should we rely on people knowing how to change the settings? Imho a valid HELO shouldn't be required by defaullt.

Tseng

You can see how important that setting is to me when you take a look at my profile: I'm registered since Dez 2006 - this was the first post I wrote

Hm, I get sometimes mails from T-Online and I never had problems. Aren't they using something like "mailout04.sul.t-online.com"?

These restrictions are filtering a big amount of spam. If a providers sends a wrong HELO/EHLO the customers should complain that they can not send mails and finally they will fix it. For those without a FQDN there are address literals, which postfix also accepts with these restrictions.

or whitelist system which cannot send you emails...