Re: smtpd - help needed tranlsating to new virtual map syntax [FIXED]
On 2019-01-21 04:08, Gilles Chehade wrote: In this test case, my translations map had: What is a translation map ? There is no such thing in OpenSMTPD (as of today). A virtual map that happened to be called . You're feeding the virtual table with invalid values. Apparently, yes. 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. 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. 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. 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. 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. -Adam -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
RE: smtpd - help needed tranlsating to new virtual map syntax
I found the "-T" (trace) flag to smtpd(8), and it gives me this, which AFAICT confirms my suspicions: [...] rule #2 matched: match from src allowed-hosts for any => translate lookup: lookup "athom...@athompso.net" as ALIAS in table static:translations -> 0 lookup: lookup "athompso" as ALIAS in table static:translations -> 0 lookup: lookup "@athompso.net" as ALIAS in table static:translations -> 0 lookup: lookup "@" as ALIAS in table static:translations -> 0 expand: lka_expand: no aliases for virtual mproc: lka -> pony : 53 IMSG_SMTP_EXPAND_RCPT expand: 0x154201b89018: clearing expand tree imsg: pony <- lka: IMSG_SMTP_EXPAND_RCPT (len=53) smtp: 0x1127a72e6000: >>> 524 5.2.4 Mailing list expansion problem [...] complete output attached below, I've changed to @old.athompso.net and @new.athompso.net during testing since the last email. On the sending side, from another host (listed in ), I'm running: swaks --to athom...@athompso.net --from athom...@old.athompso.net --server which faithfully reports the 5.2.4 error. I'm slightly disappointed, I still like OpenSMTPd's concise configuration syntax. Postfix could still rewrite source addresses last time I checked, I hope it's still there - I do NOT want to run sendmail, thank you very much. -Adam Smtpd(8) trace output including invocation: ===from here to end of message=== bhs# smtpd -d -T all -v -d debug: init ssl-tree debug: init ca-tree debug: init ssl-tree debug: using "fs" queue backend debug: using "ramqueue" scheduler backend debug: using "ram" stat backend info: OpenSMTPD 6.4.0 starting debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ca-tree debug: init ca-tree debug: init ca-tree debug: init ca-tree debug: init ca-tree debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ca-tree debug: using "fs" queue backend debug: using "fs" queue backend debug: using "fs" queue backend debug: using "fs" queue backend debug: using "fs" queue backend debug: init ssl-tree debug: using "ramqueue" scheduler backend debug: using "ramqueue" scheduler backend debug: using "ramqueue" scheduler backend debug: using "ramqueue" scheduler backend debug: using "ramqueue" scheduler backend debug: using "fs" queue backend debug: using "ram" stat backend setup_peer: klondike -> control[63932] fd=4 setup_peer: klondike -> pony express[40666] fd=5 setup_done: ca[35575] done debug: using "ram" stat backend setup_peer: control -> klondike[35575] fd=4 setup_peer: control -> lookup[49698] fd=5 setup_peer: control -> pony express[40666] fd=6 setup_peer: control -> queue[21502] fd=7 setup_peer: control -> scheduler[14152] fd=8 setup_done: control[63932] done debug: using "ram" stat backend setup_peer: lookup -> control[63932] fd=4 setup_peer: lookup -> pony express[40666] fd=5 setup_peer: lookup -> queue[21502] fd=6 setup_done: lka[49698] done debug: using "ram" stat backend setup_peer: pony express -> control[63932] fd=4 setup_peer: pony express -> klondike[35575] fd=5 setup_peer: pony express -> lookup[49698] fd=6 setup_peer: pony express -> queue[21502] fd=7 setup_done: pony[40666] done debug: using "ram" stat backend setup_peer: queue -> control[63932] fd=4 setup_peer: queue -> pony express[40666] fd=5 setup_peer: queue -> lookup[49698] fd=6 setup_peer: queue -> scheduler[14152] fd=7 setup_done: queue[21502] done debug: using "ramqueue" scheduler backend debug: using "ram" stat backend setup_peer: scheduler -> control[63932] fd=4 setup_peer: scheduler -> queue[21502] fd=5 setup_done: scheduler[14152] done smtpd: setup done mproc: parent -> control: enabled mproc: parent -> lka: enabled mproc: parent -> queue: enabled mproc: parent -> ca: enabled mproc: parent -> pony: enabled debug: parent_send_config_ruleset: reloading mproc: parent -> lka : 0 IMSG_CONF_START mproc: parent -> lka : 0 IMSG_CONF_END debug: parent_send_config: configuring pony process mproc: parent -> pony : 0 IMSG_CONF_START mproc: parent -> pony : 0 IMSG_CONF_END debug: parent_send_config: configuring ca process mproc: parent -> ca : 0 IMSG_CONF_START mproc: parent -> ca : 0 IMSG_CONF_END setup_proc: klondike done setup_proc: control done setup_proc: lookup done setup_proc: pony express done setup_proc: queue done setup_proc: scheduler done mproc: ca -> control: enabled debug: bounce warning after 4h mproc: ca -> parent: enabled mproc: ca -> pony: enabled mproc: ca -> pony: disabled mproc: pony -> parent: enabled mproc: scheduler -> control: enabled imsg: ca <- parent: IMSG_CONF_START (len=0) mproc: lka -> parent: enabled mproc: pony -> queue: enabled mproc: scheduler -> queue: enabled scheduler: getting batch: mask=0x3f, count=10 debug: /--- ramqueue: scheduler_ram_batch() debug: \--- scheduler: got r=0, delay=-1, count=10 scheduler: sleeping imsg:
RE: smtpd - help needed tranlsating to new virtual map syntax
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
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
# 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 action translate # inbound mail
- hand it to LMTP, translating as we go
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.
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. :-(
(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.)
-Adam
-Original Message-
From: owner-m...@openbsd.org On Behalf Of Adam Thompson
Sent: Wednesday, January 16, 2019 8:26 AM
To: 'Edgar Pettijohn' ; m...@openbsd.org
Subject: Re: smtpd - help needed tranlsating to new virtual map syntax
As I said, I haven't tried anything yet as I don't want to break a working
system, and I don't have a good way to test this in parallel right now.
The manpage says "The local delivery methods support additional options: [...]
virtual" without specifying which delivery methods are "local". My assumption
was that only "mbox" and "mda" were local, as lmtp can, and often does, point
to another server.
Some brief experiments with a VM only got me syntax errors, so I didn't pursue
that very thoroughly before asking for clarification.
-Adam
-Original Message-
From: Edgar Pettijohn
Sent: Wednesday, January 16, 2019 8:12 AM
To: Adam Thompson ; m...@openbsd.org
Subject: Re: smtpd - help needed tranlsating to new virtual map syntax
It would be helpful if you show what you have tried.
Should be as simple as:
action "relay-01" lmtp /var/run/lmtp.sock virtual
match from src action "relay-01"
Edgar
On Jan 16, 2019 7:37 AM, Adam Thompson wrote:
>
> [Cross-posting here before I give up and switch to Postfix -Adam]
>
>
> I have an old instance that uses smtpd's virtual to rewrite *sender*
> addresses.
> Reading the 6.4-STABLE version of the smtpd.conf(5) manpage, I can't see how
> to accomplish my goal any more - it looks impossible.
>
> I don't want to upgrade a working mail relay server to something that might
> be broken, so I'm seeking assistance first.
>
> The purpose of this system is purely to relay mail from internal,
> semi-broken-ish systems out to our Office365 tenant, but I need to clean up
> bogus MAIL FROM / "From:" headers first, lest they be flagged as spam.
>
> In general, I think I'm asking how to use virtual with the "relay"
> action in the new syntax - the manual tells me this is impossible!?
>
> Thanks,
> -Adam
>
>
> Old smtpd.conf:
>
> ===start===
> listen on 0.0.0.0
> listen on ::
> table aliases db:/etc/opensmtpd/aliases.db table vmap
> db:/etc/opensmtpd/vmap.db table localnets { 192.168.10.0/24,
> 192.168.100.0/24, 192.168.157.0/24, 192.168.158.0/24,
> 192.168.101.0/24, 10.158.0.0/16 } accept from local
> for anyrelay via
> smtp://XXX-ca.mail.protection.outlook.com hostname remote.XXX.ca
> accept from source 192.168.158.63 for domain 192.168.158.63 virtual
> deliver to lmtp localhost:25 accept from source 192.168.100.63
> for domain 192.168.100.63 virtual deliver to lmtp localhost:25
> accept from source 192.168.158.63 for anyrelay via
> smtp://XXX-ca.mail.protection.outlook.com as sys...@xxx.ca hostname
> remote.XXX.ca accept from source 192.168.100.63 for any
> relay via smtp://XXX-ca.mail.protection.outlook.com as sys...@xxx.ca
> hostname remote.XXX.ca accept from source for any
help needed tranlsating to new virtual map syntax
I have an old instance that uses virtual to rewrite *sender*
addresses.
Reading the 6.4-STABLE version of the smtpd.conf(5) manpage, I can't see
how to accomplish my goal any more - it looks impossible.
I don't want to upgrade a working mail relay server to something that
might be broken, so I'm seeking assistance first.
THe purpose of this system is purely to relay mail from internal,
semi-broken-ish systems out to our Office365 tenant, but I need to clean
up bogus MAIL FROM / "From:" headers first, lest they be flagged as
spam.
In general, I think I'm asking how to use virtual with the "relay"
action in the new syntax - the manual tells me this is impossible!?
Thanks,
-Adam
Old smtpd.conf:
===start===
listen on 0.0.0.0
listen on ::
table aliases db:/etc/opensmtpd/aliases.db
table vmap db:/etc/opensmtpd/vmap.db
table localnets { 192.168.10.0/24, 192.168.100.0/24, 192.168.157.0/24,
192.168.158.0/24, 192.168.101.0/24, 10.158.0.0/16 }
accept from local for anyrelay via
smtp://XXX-ca.mail.protection.outlook.com hostname remote.XXX.ca
accept from source 192.168.158.63 for domain 192.168.158.63 virtual
deliver to lmtp localhost:25
accept from source 192.168.100.63 for domain 192.168.100.63 virtual
deliver to lmtp localhost:25
accept from source 192.168.158.63 for anyrelay via
smtp://XXX-ca.mail.protection.outlook.com as sys...@xxx.ca hostname
remote.XXX.ca
accept from source 192.168.100.63 for anyrelay via
smtp://XXX-ca.mail.protection.outlook.com as sys...@xxx.ca hostname
remote.XXX.ca
accept from source for anyrelay via
smtp://XXX-ca.mail.protection.outlook.com hostname remote.XXX.ca
===end===
old vmap:
===start===
ilom-alert@192.168.100.63: sys...@xxx.ca
sys...@xxx.ca: sys...@xxx.ca
sys...@ad.xxx.ca: sys...@xxx.ca
root@XXX.local: sys...@xxx.ca
===end===
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: How to adapt bogus email addresses?
On 06/24/2015 04:19 PM, Vijay Sankar wrote: # cat vmap ilom-alert@192.168.100.63: avantsys...@avant.ca Looks like there is a colon there -- could that be the problem? Not according to the makemap(8) manpage: The database key and value may optionally be separated by the colon character. The documentation on virtual domains is spotty enough that I might be invoking makemap wrong, or misinterpreting what it can do altogether... -Adam
TLS decode error
I'm seeing this in my logs, which prevents me from emailing my Dell reps: Feb 19 14:27:49 mail smtpd[10516]: smtp-out: Connecting to smtp+tls://143.166.224.193:25 (ps-smtp.us.dell.com) on session e622753fb14af8b3... Feb 19 14:27:49 mail smtpd[10516]: smtp-out: Connected on session e622753fb14af8b3 Feb 19 14:27:50 mail smtpd[10516]: smtp-out: Error on session e622753fb14af8b3: IO Error: error:1407741A:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert decode error Feb 19 14:27:50 mail smtpd[10516]: smtp-out: Disabling route [] - 143.166.224.193 (ps-smtp.us.dell.com) for 800s Feb 19 14:27:51 mail smtpd[10516]: smtp-out: No valid route for [connector:[]-[relay:Dell.com],0x0] Feb 19 14:28:00 mail smtpd[10516]: relay: TempFail for fe32cf29be63e5db: session=, from=athom...@athompso.net, to=bradley_ev...@dell.com, rcpt=-, source=-, relay=Dell.com, delay=6m51s, stat=Network error on destination MXs (I'm running smtpd from OpenBSD 5.6-STABLE.) How do I disable TLS for a single remote MX or domain? Thanks, -- -Adam Thompson athom...@athompso.net +1 (204) 291-7950 - cell +1 (204) 489-6515 - fax -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Support of Dovecot LDA for local delivery
On 14-11-02 01:09 AM, Mohammad H. Al Shami wrote: Hello, Yes OpenSMTPD can work with Dovecot via LDA, but from my experience LMTP is much faster. With LDA, the LDA process is spawned for every incoming connection. With LMTP, you have a single process listening which accepts connections via TCP. I've seen my server load drop significantly after switching from LDA to LMTP. Yes... I stopped using LMTP because it inexplicably refused to work over local TCP sockets. IIRC there was some other feature the command-line gave me that LMTP didn't, as well, but I haven't gone back and re-tested since I got it working - it's entirely possible it now works perfectly. Perhaps I was using deliver instead of relay, which would not be obvious. Agreed that LMTP over UNIX socket should, in theory, be the fastest/lowest-overhead way to deliver local mail through dovecot. -- -Adam Thompson athom...@athompso.net
Re: Support of Dovecot LDA for local delivery
On 14-11-01 02:27 AM, Eric Kom wrote:
Good day all,
I'm running a Mail server based on Dovecot and Postfix for 2 years now
without problem and would like to try OpenSMTPD instead of Sendmail.
Where can I find an user documentation?
It is possible for OpenSMTPD to support a MDA like LDA from Dovecot?
Absolutely.
In smtpd.conf, use something like:
delivery = mda \/usr/local/libexec/dovecot/dovecot-lda -a %{rcpt} -d
%{user.username} -e -f %{sender} -m INBOX\
then:
accept from local for local alias aliases deliver to $delivery
(etc.)
RTFM: man smtpd.conf
--
-Adam Thompson
athom...@athompso.net
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: dual separator?
On 14-09-01 03:33 AM, Gilles Chehade wrote: Hi, On Fri, Aug 22, 2014 at 12:17:54PM -0500, Adam Thompson wrote: On 14-08-22 12:09 PM, Claus Assmann wrote: On Fri, Aug 22, 2014, Adam Thompson wrote: I have a large number of email tags, but use both + and - as a separator. So far, I'm entering all the - ones into aliases; is there a better way to do this? In postfix, I was able to use a regex to manipulate incoming addresses to There is currently no way of specifying the delimiter, it can only be + someone opened a ticket on our tracker and after we discuss it it might change On a related note... there's no publicly-visible link (that I can find) on www.opensmtpd.org to www.opensmtpd.org/reporting.html. Google knows about it somehow, but I had no other (obvious) way of finding that information. -- -Adam Thompson athom...@athompso.net -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
