On Mon, Jan 21, 2019 at 01:04:16PM -0600, Adam Thompson wrote:
>
> > Also, this is a recipient translation mechanism, similar to aliases, and
> > not a sender rewriting mechanism which we do not have at this point.
> > [...]
> > 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:
>
> This is all very surprising to hear. The existing system works (somehow).
> So I am apparently misunderstanding what is happening, because with the
> configuration as shown, telling the various broken email senders to use that
> box as their mailhost _somehow_ fixes the bogus From: headers and envelopes.
>
the entire virtual expansion happens between the client sending RCPT TO,
and the server responding Ok to that RCPT TO. virtual does not know of a
sender, never, and it is done before the message is actually received so
it doesn't know headers, which is why i'm 100% confident there isn't one
chance it could ever do what you describe.
> Oh, this just occurred to me as I'm writing: I really hope I didn't switch
> to a different MTA on that system years ago, and then just forgot to check
> which MTA was actually running. If that's the case, I'm not going to bother
> posting an update, because I'll be busy banging my head on the wall and then
> hiding in shame.
>
that is a more likely possibility.
> > > 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.
>
> I'm taking your word for it - you will know far better than I do!
>
>
> > 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:
>
> Good reasons aside, I still need to accommodate other vendor's broken mail
> implementations, because I can't fix them. I know of multiple reasons
> source rewriting is a bad idea, in general, but I get paid to make stuff
> work, not just say that it's broken.
>
oh, don't get me wrong, i'm not saying there's a good reason not to have
this rewriting, what i was saying is that there was a good reason why it
was not doable before the grammar change.
it is a useful feature which is part of my todo and which i will work on
as time allows.
> > it not considered doable before the grammar change...
> > But sure, blame it on the grammar.
>
> I believed that the grammar change had rendered my use case impossible
> because was now limited to local delivery methods. Clearly I was
> wrong... and not even in the way I thought I might be wrong.
>
yes, that's true.
using 'virtual' on relay rules didn't transform anything whatsoever, the
code had an explicit check to not enter the transformation lookups if we
were in a relay rule.
the new grammar just made it clear that what you were trying to do could
not work rather than accepting the criteria and disregarding it.
> > 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)
>
> My apologies - that was meant to sound more like "I have a plan B so if this
> isn't possible, that's OK but I've wasted so much time on this I'm kinda
> running out of time, please tell me if I should just stop now and switch".
> I know *exactly* how much OpenBSD devs care if I use their code or not! I
> do not want to be "that asshole", although it seems I've succeeded again -
> sorry.
>
> Thank you for taking the time to reply. Now I'm going to go check that mail
> server a 7,000,000th time, this time to see what MTA is actually *running*,
> not just *configured*. I'm not sure whether I want it to be such a blatant
> mistake on my part or not... if yes, this all makes sense but I'm an idiot,
> whereas if no, then WTF, how is it working at all?
>
> FWIW: I am much happier with OpenSMTPd than with other MTAs because of its
> forward-declarative configuration syntax. Thank you for your work on
> bringing a modern, lean, secure(-er) MTA into existence.
>
np ;-)
--
Gilles Chehade @poolpOrg
https://www.poolp.org tip me: https://paypal.me/poolpOrg
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
