On Sun, Jan 20, 2019 at 04:14:05PM -0600, Adam Thompson wrote:
> As it turns out, no, that doesn't work.
> Trying to fix up broken sender mail domain-parts only simply gets me a "5.2.4
> Mailing list expansion problem" error, with no debug output to suggest why.
>
> In this test case, my translations map had:
>
> @bad.athompso.net @good.athompso.net
>
What is a translation map ?
There is no such thing in OpenSMTPD (as of today).
> in it. Obviously, this is a test setup :).
> Smtpd.conf itself consisted of:
>
> listen on all received-auth
> smtp max-message-size 100M
> table translations file:/etc/mail/translations # ORIG->NEW
> mappings
> table allowed-hosts file:/etc/mail/allowed-hosts # Who can
> connect? (bare IP addresses or CIDR subnets)
> action translate lmtp "/var/run/lmtp.sock" virtual <translations>
> # 1st pass on allowed rewrite mail
> action forward forward-only
> # and now it's not our problem anymore
> match for any from local action forward # 2nd pass for
> reinjected mail, this time just forward it
> match for any from src <allowed-hosts> action translate # inbound mail
> - hand it to LMTP, translating as we go
>
>
from table(5):
then tell the first people who attempts to help that yu/uuuu///yyyyyyyyyyyy
Aliasing tables
Aliasing tables are mappings that associate a recipient to one or many
destinations. They can be used in two contexts: primary domain aliases
and virtual domain mapping.
[...]
In a virtual domain context, the key is either a user part, a full email
address or a catch all, following selection rules described in
smtpd.conf(5), and the value is one or many recipients as described in
aliases(5):
user1 otheruser
us...@example.org otheruser1,otheruser2
@example.org otheru...@example.com
@ catch...@example.com
You're feeding the virtual table with invalid values.
Also, this is a recipient translation mechanism, similar to aliases, and
not a sender rewriting mechanism which we do not have at this point.
> A cursory glance at the source code (yikes, it's been a long time since I was
> a programmer) suggests that virtual now only works on recipients, not
> senders. Which is too bad for me, as that means I'll have to switch at least
> one box to use Postfix.
>
virtual _now_ only works on recipients, not senders ?
the virtual code hasn't changed, it works the way it always did.
there is no way it could ever do what you're describing or attempting to
do given that it doesn't operate at all anywhere near the message. there
is no way it has ever parsed:
@bad.athompso.net @good.athompso.net
and the only thing that changed is that such errors are now visible from
the session as:
5.2.4 Mailing list expansion problem
instead of an invalid recipient error like it probably did in 6.3
> I'm not convinced the new smtpd.conf grammar improves anything at all, but I
> assume it must help someone or it wouldn't have changed... but I believe my
> use case got thrown out with the bathwater, so to speak. Oh, well. :-(
>
This is bullshit.
The grammar doesn't reduce the functional scope, it can only expand it.
What you are describing has never existed in smtpd, there's never been
code to translate sender addresses and there's a good reason for that:
it not considered doable before the grammar change...
But sure, blame it on the grammar.
> (If anyone cares, the bad sender addresses are mostly alerts coming from
> older Sun ALOMs and at least one Lexmark printer that also sends email with
> broken From addresses.)
>
I may sound a bit harsh, but starting a thread with "this is my last try
or I'll switch"
Aliasing tables
Aliasing tables are mappings that associate a recipient to one or many
destinations. They can be used in two contexts: primary domain aliases
and virtual domain mapping.
[...]
In a virtual domain context, the key is either a user part, a full email
address or a catch all, following selection rules described in
smtpd.conf(5), and the value is one or many recipients as described in
aliases(5):
user1 otheruser
us...@example.org otheruser1,otheruser2
@example.org otheru...@example.com
@ catch...@example.com
You're feeding the virtual table with invalid values.
Also, this is a recipient translation mechanism, similar to aliases, and
not a sender rewriting mechanism which we do not have at this point.
> A cursory glance at the source code (yikes, it's been a long time since I was
> a programmer) suggests that virtual now only works on recipients, not
> senders. Which is too bad for me, as that means I'll have to switch at least
> one box to use Postfix.
>
virtual _now_ only works on recipients, not senders ?
the virtual code hasn't changed, it works the way it always did.
there is no way it could ever do what you're describing or attempting to
do given that it doesn't operate at all anywhere near the message. there
is no way it has ever parsed:
@bad.athompso.net @good.athompso.net
and the only thing that changed is that such errors are now visible from
the session as:
5.2.4 Mailing list expansion problem
instead of an invalid recipient error like it probably did in 6.3
> I'm not convinced the new smtpd.conf grammar improves anything at all, but I
> assume it must help someone or it wouldn't have changed... but I believe my
> use case got thrown out with the bathwater, so to speak. Oh, well. :-(
>
This is bullshit.
The grammar doesn't reduce the functional scope, it can only expand it.
What you are describing has never existed in smtpd, there's never been
code to translate sender addresses and there's a good reason for that:
it not considered doable before the grammar change...
But sure, blame it on the grammar.
> (If anyone cares, the bad sender addresses are mostly alerts coming from
> older Sun ALOMs and at least one Lexmark printer that also sends email with
> broken From addresses.)
>
I may sound a bit harsh, but starting a thread with "this is my last try
or I'll switch"
Aliasing tables
Aliasing tables are mappings that associate a recipient to one or many
destinations. They can be used in two contexts: primary domain aliases
and virtual domain mapping.
[...]
In a virtual domain context, the key is either a user part, a full email
address or a catch all, following selection rules described in
smtpd.conf(5), and the value is one or many recipients as described in
aliases(5):
user1 otheruser
us...@example.org otheruser1,otheruser2
@example.org otheru...@example.com
@ catch...@example.com
You're feeding the virtual table with invalid values.
Also, this is a recipient translation mechanism, similar to aliases, and
not a sender rewriting mechanism which we do not have at this point.
> A cursory glance at the source code (yikes, it's been a long time since I was
> a programmer) suggests that virtual now only works on recipients, not
> senders. Which is too bad for me, as that means I'll have to switch at least
> one box to use Postfix.
>
virtual _now_ only works on recipients, not senders ?
the virtual code hasn't changed, it works the way it always did.
there is no way it could ever do what you're describing or attempting to
do given that it doesn't operate at all anywhere near the message. there
is no way it has ever parsed:
@bad.athompso.net @good.athompso.net
and the only thing that changed is that such errors are now visible from
the session as:
5.2.4 Mailing list expansion problem
instead of an invalid recipient error like it probably did in 6.3
> I'm not convinced the new smtpd.conf grammar improves anything at all, but I
> assume it must help someone or it wouldn't have changed... but I believe my
> use case got thrown out with the bathwater, so to speak. Oh, well. :-(
>
This is bullshit.
The grammar doesn't reduce the functional scope, it can only expand it.
What you are describing has never existed in smtpd, there's never been
code to translate sender addresses and there's a good reason for that:
it not considered doable before the grammar change...
But sure, blame it on the grammar.
> (If anyone cares, the bad sender addresses are mostly alerts coming from
> older Sun ALOMs and at least one Lexmark printer that also sends email with
> broken From addresses.)
>
I may sound a bit harsh, but starting a thread with "this is my last try
or I'll switch"
Aliasing tables
Aliasing tables are mappings that associate a recipient to one or many
destinations. They can be used in two contexts: primary domain aliases
and virtual domain mapping.
[...]
In a virtual domain context, the key is either a user part, a full email
address or a catch all, following selection rules described in
smtpd.conf(5), and the value is one or many recipients as described in
aliases(5):
user1 otheruser
us...@example.org otheruser1,otheruser2
@example.org otheru...@example.com
@ catch...@example.com
You're feeding the virtual table with invalid values.
Also, this is a recipient translation mechanism, similar to aliases, and
not a sender rewriting mechanism which we do not have at this point.
> A cursory glance at the source code (yikes, it's been a long time since I was
> a programmer) suggests that virtual now only works on recipients, not
> senders. Which is too bad for me, as that means I'll have to switch at least
> one box to use Postfix.
>
virtual _now_ only works on recipients, not senders ?
the virtual code hasn't changed, it works the way it always did.
there is no way it could ever do what you're describing or attempting to
do given that it doesn't operate at all anywhere near the message. there
is no way it has ever parsed:
@bad.athompso.net @good.athompso.net
and the only thing that changed is that such errors are now visible from
the session as:
5.2.4 Mailing list expansion problem
instead of an invalid recipient error like it probably did in 6.3
> I'm not convinced the new smtpd.conf grammar improves anything at all, but I
> assume it must help someone or it wouldn't have changed... but I believe my
> use case got thrown out with the bathwater, so to speak. Oh, well. :-(
>
This is bullshit.
The grammar doesn't reduce the functional scope, it can only expand it.
What you are describing has never existed in smtpd, there's never been
code to translate sender addresses and there's a good reason for that:
it not considered doable before the grammar change...
But sure, blame it on the grammar.
> (If anyone cares, the bad sender addresses are mostly alerts coming from
> older Sun ALOMs and at least one Lexmark printer that also sends email with
> broken From addresses.)
>
I may sound a bit harsh, but starting a thread with "this is my last try
or I'll switch"
Aliasing tables
Aliasing tables are mappings that associate a recipient to one or many
destinations. They can be used in two contexts: primary domain aliases
and virtual domain mapping.
[...]
In a virtual domain context, the key is either a user part, a full email
address or a catch all, following selection rules described in
smtpd.conf(5), and the value is one or many recipients as described in
aliases(5):
user1 otheruser
us...@example.org otheruser1,otheruser2
@example.org otheru...@example.com
@ catch...@example.com
You're feeding the virtual table with invalid values.
Also, this is a recipient translation mechanism, similar to aliases, and
not a sender rewriting mechanism which we do not have at this point.
> A cursory glance at the source code (yikes, it's been a long time since I was
> a programmer) suggests that virtual now only works on recipients, not
> senders. Which is too bad for me, as that means I'll have to switch at least
> one box to use Postfix.
>
virtual _now_ only works on recipients, not senders ?
the virtual code hasn't changed, it works the way it always did.
there is no way it could ever do what you're describing or attempting to
do given that it doesn't operate at all anywhere near the message. there
is no way it has ever parsed:
@bad.athompso.net @good.athompso.net
and the only thing that changed is that such errors are now visible from
the session as:
5.2.4 Mailing list expansion problem
instead of an invalid recipient error like it probably did in 6.3
> I'm not convinced the new smtpd.conf grammar improves anything at all, but I
> assume it must help someone or it wouldn't have changed... but I believe my
> use case got thrown out with the bathwater, so to speak. Oh, well. :-(
>
This is bullshit.
The grammar doesn't reduce the functional scope, it can only expand it.
What you are describing has never existed in smtpd, there's never been
code to translate sender addresses and there's a good reason for that:
it not considered doable before the grammar change...
But sure, blame it on the grammar.
> (If anyone cares, the bad sender addresses are mostly alerts coming from
> older Sun ALOMs and at least one Lexmark printer that also sends email with
> broken From addresses.)
>
I may sound a bit harsh, but starting a thread with "this is my last try
or I'll switch"
Aliasing tables
Aliasing tables are mappings that associate a recipient to one or many
destinations. They can be used in two contexts: primary domain aliases
and virtual domain mapping.
[...]
In a virtual domain context, the key is either a user part, a full email
address or a catch all, following selection rules described in
smtpd.conf(5), and the value is one or many recipients as described in
aliases(5):
user1 otheruser
us...@example.org otheruser1,otheruser2
@example.org otheru...@example.com
@ catch...@example.com
You're feeding the virtual table with invalid values.
Also, this is a recipient translation mechanism, similar to aliases, and
not a sender rewriting mechanism which we do not have at this point.
> A cursory glance at the source code (yikes, it's been a long time since I was
> a programmer) suggests that virtual now only works on recipients, not
> senders. Which is too bad for me, as that means I'll have to switch at least
> one box to use Postfix.
>
virtual _now_ only works on recipients, not senders ?
the virtual code hasn't changed, it works the way it always did.
there is no way it could ever do what you're describing or attempting to
do given that it doesn't operate at all anywhere near the message. there
is no way it has ever parsed:
@bad.athompso.net @good.athompso.net
and the only thing that changed is that such errors are now visible from
the session as:
5.2.4 Mailing list expansion problem
instead of an invalid recipient error like it probably did in 6.3
> I'm not convinced the new smtpd.conf grammar improves anything at all, but I
> assume it must help someone or it wouldn't have changed... but I believe my
> use case got thrown out with the bathwater, so to speak. Oh, well. :-(
>
This is bullshit.
The grammar doesn't reduce the functional scope, it can only expand it.
What you are describing has never existed in smtpd, there's never been
code to translate sender addresses and there's a good reason for that:
it not considered doable before the grammar change...
But sure, blame it on the grammar.
> (If anyone cares, the bad sender addresses are mostly alerts coming from
> older Sun ALOMs and at least one Lexmark printer that also sends email with
> broken From addresses.)
>
I may sound a bit harsh, but starting a thread with "this is my last try
or I'll switch" (as if it actually matters) right before telling someone
who wants to help you that you actually tried _nothing_ then blaming the
code improvements for a use-case that could have never worked because it
not only uses the wrong _documented_ mechanism but also because the code
to make your use-case work has never existed, kinds of irritates me.
I don't get royalties on smtpd install, please install whatever software
fits your use case, this is how proper engineering works.
--
Gilles Chehade @poolpOrg
https://www.poolp.org tip me: https://paypal.me/poolpOrg
