EHLO command returns all bunch of 250- data, even when the hooks returns otherwise

[cnicodeme]

EHLO command returns all bunch of 250- data, even when the hooks returns otherwise

[waynew]

Just trying to understand here - is there a case where you would want to return a different response to the EHLO and still succeed?

I know personally I haven't had a need for that, but I'm not sure what the valid use cases are.

[waynew]

I just did some searching and I haven't been able to find a really great reason that EHLO should be returning anything besides a 250.

The only reason I can think of that you might be returning something different is that you've got some kind of broken setup - which indicates that you need to fix your code, not that there's an issue here.

But if there's some case that I have considered, I'd love to hear about it!

[cnicodeme]

Hi @waynew ! I do have an example :)

When the server connects to the SMTP daemon, the HELO/EHLO command can allow many checks that can lead to refusal:

1. checking if the IP has a PTR record
2. checking that the hostname matches the PTR of that the SPF records allow the IP to send emails
3. Checking that the sending IP is not on a blacklist (Spamhaus for instance)

If one of those checks fails, you can return a 4xx/5xx to refuse the connection, before going further.

But with the EHLO command, aiosmtpd has already returned 250-* messages before sending that 4xx/5xx code, so it's not good.

Hope that makes sense :)

[waynew]

Hey @cnicodeme yeah, thanks! That definitely makes sense. Do you have any ideas about how we would want to change this? Pull requests of course are always welcome :)

[cnicodeme]

I've sent a PR (#157). Let me know what you think.

The PR also kind of join the idea of having None returned for the hooks instead of MISSING. (see #154 )

[agronholm]

If there is no way to override the 250 response, how can I test that my SMTP client can fall back to HELOwhen EHLO fails?

[agronholm]

Answering my own question, overriding smtp_EHLO() is the only way.