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
