Antw: Re: From adress must match the smtp clients DNS domain

[Gregory Sloop]

GR> Hi Curtis,

GR> thanks for your suggestion but it seems not to realize my idea. I'll try to describe it better:

GR> When a smtp client with the IP address 1.2.3.4 and the DNS
GR> hostname host1.mydomain delivers messages to my postfix/amavis MTA
GR> with tcp/25, all the messages must have from-headers and
GR> envelope-from-addresses of the form any_user at host1.mydomain. I
GR> want to configure my MTA to apply this policy only to the IP 1.2.3.4 or the subnet 1.2.3.0/24

GR> Is there any other advice?

GR> Best regards
GR> Gerhard Rappenecker

You do realize that this will cause you a LOT of pain, unless your inbound mail is incredibly unusual, right?

For example - the reverse on my VPS server is, say, mail.xyz.com. But I host mail for many domains - like abc.com, def.com ghi.com etc. [Not to mention, the mail server will likely identify as mail.xyz.com - but my mail will be from the 2nd level domain, xyz.com - and you'd block that too!]

So, if you implement [at least what I think I understand] what you're trying to do you'll block all mail that isn't from xyz.com coming from my VPS, even though there could be many, many legitimate other domains.

If you don't care about blocking mail in those conditions, or if you don't get mail from most of the real world, then I suppose what you want works. But I suspect that's not the case - and implementing your design will break email for your entire server. [And I'm not aware of any way any MTA would implement this "out-of-the-box" anyway.]

What I think you want is more likely to be accomplished with SPF. SPF certainly isn't universally used, so it's of limited utility. But it's the closest workable concept to what you put forward above that's likely to not break/cripple your mail server.

But to reiterate - what you've described above [at least how I read it] is so completely unworkable, if you accept mail from the rest of the world, it's simply going to block a vast amount of legitimate mail.

-Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.amavis.org/pipermail/amavis-users/attachments/20160622/68c436ce/attachment.html>