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 <virtual> 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

Reply via email to