Re: [PATCH] Control received lines via hide-received and mask-received
On Tue, May 28, 2013 at 05:45:06PM +0200, Jason A. Donenfeld wrote: > Oh, I see: > > case HOOK_CONNECT: > m_get_sockaddr(&m, (struct > sockaddr*)&q_connect.local); > m_get_sockaddr(&m, (struct > sockaddr*)&q_connect.remote); > m_get_string(&m, &q_connect.hostname); > m_end(&m); > filter_dispatch_connect(id, qid, &q_connect); > break; > > > So basically, a filter writer has to note the local/remote sockaddr > and connect it up with its qid, store that state information > somewhere, and then re-correlate the qid on the dataline situation? > Blah, that sounds a bit tedious -- I wouldn't enjoy programming for > it. Well, we won't force you to. > Also -- this exposes local and remote sockaddrs and the connect > hostname, but not much else, such as labels, authentication status, > tls status, etc. Are there plans to introduce a better state > mechanism? Also, as a nitpick, sockaddr is size-less, so the filter > can't know with total certainty which size to cast it back to. The plan is to eventually have something powerful, efficient and easy to use, just as the rest of the daemon. But as gilles said already we have to focus on other tasks at the moment. Eric. -- You received this email because you are subscribed to mailing list: misc@opensmtpd.org To unsubscribe, send mail with subject: [misc@opensmtpd.org] unregister
Announce: OpenSMTPD 5.3.3 released
OpenSMTPD 5.3.3 has just been released and the archives are available at our main site: www.OpenSMTPD.org OpenSMTPD is a FREE implementation of the SMTP protocol with some common extensions. It allows ordinary machines to exchange e-mails with systems speaking the SMTP protocol. It implements a fairly large part of RFC5321 and can already cover a large range of use-cases. It runs on OpenBSD, NetBSD, FreeBSD, DragonFlyBSD, OSX and Linux. We would like to thank the OpenSMTPD community for their help in testing the snapshots, reporting bugs, contributing code and packaging for other systems. This is a bugfix and reliability release, no new feature. BugFixes: = * fix a bug causing possible timeouts of incoming SSL sessions * fix a case-folding issue when looking up keys in static tables * plug several memory leaks in the MTA engine * while there, fix a use-after-free in debug traces Checksums: == SHA256 (opensmtpd-5.3.3.tar.gz) = 01c4f22cdc5b4f04205f2b1490e275fba2c2265c9eb586f5c259dd3ecb6271b0 SHA256 (opensmtpd-5.3.3p1.tar.gz) = 34f0e208e6fdde5c5c25bb11f468436c4d6148a8b640c32117869cad140b823c Support: You are encouraged to register to our general purpose mailing-list: http://www.opensmtpd.org/list.html The "Official" IRC channel for the project is at: #OpenSMTPD @ irc.freenode.net Reporting Bugs: === Please read http://www.opensmtpd.org/report.html Security bugs should be reported directly to secur...@opensmtpd.org Other bugs may be reported to b...@opensmtpd.org OpenSMTPD is brought to you by Gilles Chehade, Eric Faurot and Charles Longeau. -- You received this email because you are subscribed to mailing list: misc@opensmtpd.org To unsubscribe, send mail with subject: [misc@opensmtpd.org] unregister
Re: SMTPD_VERSION should not contain SMTPD_NAME in snapshots
On Tue, Jun 11, 2013 at 09:47:35AM +0200, Gilles Chehade wrote:
> On Tue, Jun 11, 2013 at 01:42:15AM +0200, Jason A. Donenfeld wrote:
> > zx2c4@thinkpad ~/opensmtpd-201306071637p1 $ grep -R SMTPD_VERSION
> > smtpd/smtpd.h:#define SMTPD_VERSION"opensmtpd-201306071637p1"
> > smtpd/smtpd.c: log_info("info: %s %s starting", SMTPD_NAME, SMTPD_VERSION);
> >
> >
> > It should just be
> >
> > #define SMTPD_VERSION"201306071637p1"
> >
>
> Eric needs to have a look at this as it may impact the releng branch
It will be fixed in the next snapshots.
Eric.
--
You received this email because you are subscribed to mailing list:
misc@opensmtpd.org
To unsubscribe, send mail with subject:
[misc@opensmtpd.org] unregister
Re: OpenSMTPD pid file
On Tue, Jun 11, 2013 at 05:00:17PM +0200, Gilles Chehade wrote: > eric ? > > the releng script fuckedup :-) I just fixed it. upcoming snapshots should be ok. Eric. -- You received this email because you are subscribed to mailing list: misc@opensmtpd.org To unsubscribe, send mail with subject: [misc@opensmtpd.org] unregister
Re: Crash with virtual domains
On Mon, Jun 17, 2013 at 10:04:20PM +0100, Zé Loff wrote:
> Hi all
>
> I'm running version 5.3.3 on -current OpenBSD and smtpd shutdowns upon
> receiving a mail for a virtual domain recipient (which doesn't get
> delivered). Delivery for local users works as it should.
>
> $ egrep -v "^#|^$" /etc/smtpd.conf
> listen on lo0
> table aliases db:/etc/mail/aliases.db
> table users { foo }
> accept for local alias deliver to mbox
> accept for domain foo.bar virtual deliver to mda "/usr/bin/false"
> accept for any relay
>
> When sending a mail to f...@foo.bar smtpd shutdowns right after RCPT TO:
> is issued, and logs a string of warnings about the pipes closing.
>
> This is on a completely clean install of OpenBSD on a virtual machine,
> with the only change being those referred to on smtpd's man page.
>
> Am I doing something wrong?
Your "users" table must be a mapping from virtual users (or catch-all)
to local user or forward addresses. Try to fix that and see if it
works better. We shoudl not be crashing on this though. I'll have a
look.
Eric.
--
You received this email because you are subscribed to mailing list:
misc@opensmtpd.org
To unsubscribe, send mail with subject:
[misc@opensmtpd.org] unregister
Re: ipv4 / ipv6 mx order
On Fri, Jun 21, 2013 at 04:48:22AM +0600, Denis Fateyev wrote: > >Hello there, >Is there an option to select MX type order for outgoing messages (IPv4 >first, then IPv6, or vice versa), and/or entirely disable IPvX usage >for outgoing sessions? >For example, I have a bunch of machines that don't have IPv6 support, >so while sending mails to @[1]gmail.com 'smtp-out' always starts from >IPv6 MX which produces only faulty connection attempts and wastes time. >I haven't found an option in program to force IPv4 using. >More general: is there an option in global scope which controls allowed >protocols? I can think of two ways to do that at the moment. One way is to add "family inet4" to your resolv.conf. I think it is only officially supported on OpenBSD, but smtpd will handle it fine, whatever system you run. A drawback is that it is a global setting, but if you don't have ipv6 on those machines it should be fine. Of course, the biggest problem is that you need a resolver option that might not be available on your system, which is maybe not desirable, from an admin point of view. An other way is to add an explicit source address (or table) on your relay rules: "accept for any relay source aaa.bbb.ccc.ddd". This way smtpd will only attempt to connect to host on their v4 address. The problem is that you have to hard-code your IP in the config file. It might be acceptable though, at least as a temporary workaround. I would say use the first option on OpenBSD. Otherwise either ignore the failures, or use the second option for now. Eric. -- You received this email because you are subscribed to mailing list: misc@opensmtpd.org To unsubscribe, send mail with subject: [misc@opensmtpd.org] unregister
Re: [OpenSMTPD] portable snapshot opensmtpd-201306211627p1 available
On Sat, Jun 22, 2013 at 03:25:36AM +0600, Denis Fateyev wrote: > >Hello Gilles, >On Fri, Jun 21, 2013 at 8:28 PM, gilles <[1]gil...@poolp.org> wrote: > > User gilles has just rebuilt a portable snapshot, available from: > > [2]http://www.OpenSMTPD.org/archives/opensmtpd-201306211627p1.tar.gz > A summary of the content of this snapshot is available below. > Please test and let us know if it breaks something! > >1) First of all, I see that two latest snapshots are already >"bootstrapped" and don't contain "bootstrap" script, is it default >behavior since the previous snapshot? I'm asking because previous >snapshots (earlier than Jun 07) and latest stable release (5.3.3p1) >contain "bootstrap". Right, we started to ship tarballs with a configure script. >2) PID subsystem is working fine, tested on RHEL 5 and 6, Debian 6 and >Ubuntu 12.04. but I've noticed that .sock file still present after >service stop. I believe this behavior has been broken somewhere in >snapshots between the latest stable release and the latest snapshot. I don't think it got broken, it probably never worked actually. I'll have a look. >3) Process names are now correct (please check that if I'm wrong): >- previous behavior (stable version) - >Jun 21 14:07:03 ovz1-i386 smtpd[623]: info: OpenSMTPD 5.3.3p1 starting >Jun 21 14:07:03 ovz1-i386 smtpd[624]: info: startup >Jun 21 15:40:34 ovz1-i386 eduler[633]: info: scheduler handler exiting >Jun 21 15:40:34 ovz1-i386 nsfer[631]: info: mail transfer agent exiting >Jun 21 15:40:34 ovz1-i386 kup[628]: info: lookup agent exiting >Jun 21 15:40:34 ovz1-i386 ue[632]: info: queue handler exiting >Jun 21 15:40:34 ovz1-i386 trol[627]: info: control process exiting >Jun 21 15:40:34 ovz1-i386 ter[630]: info: mail filter exiting >Jun 21 15:40:34 ovz1-i386 ivery[629]: info: mail delivery agent exiting >Jun 21 15:40:34 ovz1-i386 p[634]: info: smtp server exiting >Jun 21 15:40:34 ovz1-i386 iv][624]: warn: parent terminating >- current behavior (latest snapshot) - >Jun 21 15:41:09 ovz1-i386 smtpd[2505]: info: OpenSMTPD 201306211627p1 >starting >Jun 21 15:41:09 ovz1-i386 smtpd[2506]: info: startup >Jun 21 15:41:33 ovz1-i386 smtpd[2514]: info: scheduler handler exiting >Jun 21 15:41:33 ovz1-i386 smtpd[2512]: info: mail filter exiting >Jun 21 15:41:33 ovz1-i386 smtpd[2513]: info: mail transfer agent >exiting >Jun 21 15:41:33 ovz1-i386 smtpd[2515]: info: smtp server exiting >Jun 21 15:41:33 ovz1-i386 smtpd[2511]: info: mail delivery agent >exiting >Jun 21 15:41:33 ovz1-i386 smtpd[2510]: info: lookup agent exiting >Jun 21 15:41:33 ovz1-i386 smtpd[2508]: info: queue handler exiting >Jun 21 15:41:33 ovz1-i386 smtpd[2509]: info: control process exiting >Jun 21 15:41:33 ovz1-i386 smtpd[2506]: warn: parent terminating Yes, I finally managed to fix that. >4) "smtpscript" binary is now missing (I compared to latest stable >release but haven't check with previous snapshot). Is it correct? It got removed for some reason. I liked to have it though. Well... >5) During message relay: I see that "smtp-out" tries to connect to >several MX servers simultaneously. For one outgoing example, it tries >to open several sessions in a short time. What happens if all >connections are established properly and are ready for accepting mail? >Would one message be sent through them all? Can "smtp-out" handle this >situation correctly? The connection strategy is a bit complicated, but it should work well enough for a large variety of use-case. The idea is that the MTA establishes and maintains a set of connections when it receives messages to send. When a connection is ready, it will dequeue the next message from the wait queue and send it. So a message will not be sent twice by different connections. >At least, I've noticed, that after successful relay through one session >"smtp-out" doesn't close others for the same message. >You can look at a piece of log below: here we have a successful relay >through one session (00038ae32e21), but another one >(0002cf237b1e) for the same message still open until connection >timeout. I think all the sessions (regardless of their validity or >state) should be closed forcefully after succeeded message relay >through one of them? >- cut - >Jun 21 16:44:07 ovz1-i386 smtpd[3985]: smtp-in: New session >b829a2ca from host 0@localhost [local] >Jun 21 20:44:07 ovz1-i386 smtpd[3985]: smtp-in: Accepted message >b829a2ca on session b829a2ca: >from=<[3]r...@ovz1-i386.xx.com>, size=279, nrcpts=1, proto=ESMTP >Jun 21 20:44:07 ovz1-i386 smtpd[3985]: smtp-in: Closing session >b829a2ca >Jun 21 16:44:07 ovz
Re: Compatibility patch idea
On Wed, Jul 17, 2013 at 12:43:23AM +0200, Gilles Chehade wrote: > > --- a/contrib/lib/libc/asr/asr_debug.c2013-07-15 21:14:05.0 > > +0600 > > +++ b/contrib/lib/libc/asr/asr_debug.c2013-07-17 00:26:40.0 > > +0600 > > @@ -286,8 +286,12 @@ > > PRINTOPT(RES_STAYOPEN, "STAYOPEN"); > > PRINTOPT(RES_DNSRCH, "DNSRCH"); > > PRINTOPT(RES_NOALIASES, "NOALIASES"); > > +#ifdef RES_USE_EDNS0 > > PRINTOPT(RES_USE_EDNS0, "USE_EDNS0"); > > +#endif > > +#ifdef RES_USE_DNSSEC > > PRINTOPT(RES_USE_DNSSEC, "USE_DNSSEC"); > > +#endif > > if (o) > > fprintf(f, " 0x%08x", o); > > fprintf(f, "\n"); > > eric ? See below > > -- < cut here > -- > > > > 1) There are only SSL_OP_NO_TICKET, RES_USE_EDNS0 and RES_USE_DNSSEC > > options presence checks. If they are declared (in modern OSes, by default) > > they are used, otherwise they are omitted. > > > > 2) SSL_OP_NO_TICKET was introduced in openssl-0.9.9, and thus isn't > > supported on RHEL5 and such platforms. I've tested TLS and SSL local > > connections on RHEL5, and they work fine. Although I haven't tested > > outgoing TLS connections yet, but I doubt they would fail. > > > > I'm ok with that, what I'm not happy with is adding ifdef's to the code > when not absolutely necessary :-) > > > > 3) RES_USE_EDNS0 and RES_USE_DNSSEC options are missed in old GLIBC. They > > prescript to use DNSSEC for security reasons, but their using or dismissing > > won't break the program's core functionality. > > > > eric ? I agree that we should not add too many #ifdef in the code. It's better to define them to 0 (or whatever unused values) in config.h and leave the code untouched. Eric. -- You received this email because you are subscribed to the "misc@opensmtpd.org" list To unsubscribe, send mail with subject: [misc@opensmtpd.org] unregister
Re: How to send to a local user and a foreign address ?
On Wed, Aug 21, 2013 at 08:08:14PM +0200, Denis Fondras wrote:
> Hello all,
>
> I'm trying to migrate my Postfix setup to OpenSMTPd.
> I'm using opensmtpd-latest.tar.gz on OpenBSD 5.3.
>
> Here is my setup :
>
> -- /etc/mail/smtpd.conf :
> listen on all
>
> table mydomains { domain.fr, domain.org }
> table myaddress "/etc/mail/vusers.txt"
>
> accept from any for domain virtual deliver to
> lmtp "/usr/local/var/run/dovecot/lmtp"
>
> accept from { 127.0.0.0/8 192.168.20.254/32 ::1/128
> 2001:7A8:B5AD:20::1000/128 } for any relay
> --
>
> -- /etc/mail/vusers.txt
> t...@domain.fr de...@domain.fr
> de...@domain.fr denis,u...@domain.net
> --
>
> What I'm trying to do and what I get :
>
> --
> $ telnet ::1 25
> Trying ::1...
> Connected to ::1.
> Escape character is '^]'.
> 220 kreator.ledeuns.net ESMTP OpenSMTPD
> ehlo coco
> 250-kreator.ledeuns.net Hello coco [IPv6:::1], pleased to meet you
> 250-8BITMIME
> 250-ENHANCEDSTATUSCODES
> 250-SIZE 36700160
> 250 HELP
> mail from:
> 250 Ok
> rcpt to:
> 550 Invalid recipient
> --
>
> The server logs :
> --
> [..]
> debug: aliases_virtual_get: 'de...@domain.fr' resolved to 2 nodes
> smtp-in: Failed command on session 3d74c32d: "rcpt
> to:" => 550 Invalid recipient
> [..]
> --
>
> If I remove u...@domain.net from /etc/mail/vusers.txt the mail is
> accepted. If I replace u...@domain.net with a local user, it works.
>
> What am I doing wrong ?
Your problem is that there is no rule that handles u...@domain.net, so
the whole expansion fails. You might want to add a catch-all relay
rule.
> PS. It seems OpenSMTPd handle the "accept" rules in the order they
> appear in the config file.
Yes, that's on purpose: the rule is "first match wins"
Eric.
--
You received this email because you are subscribed to the "misc@opensmtpd.org"
list
To unsubscribe, send mail with subject: [misc@opensmtpd.org] unregister
Re: How to send to a local user and a foreign address ?
On Wed, Aug 21, 2013 at 08:48:43PM +0200, Denis Fondras wrote:
> Hi Eric !
>
> > Your problem is that there is no rule that handles u...@domain.net, so
> > the whole expansion fails. You might want to add a catch-all relay
> > rule.
> >
>
> Ok, I thought "accept from { 127.0.0.0/8 192.168.20.254/32 ::1/128
> 2001:7A8:B5AD:20::1000/128 } for any relay" was that catch-all rule.
I didn't see that in your config.
All you need is an "accept for any ..." rule at the end of your config
file. This matches all mails originating from this machine, including
forwarded mails (aliases and .forward). It also matches mails enqueued
on authenticated sessions.
So if you also want to relay for other networks or addresses, I advise
you to make it another rule explicitely. It is a lot more cleaner and
less error-prone.
> Won't a more open rule change my server into an open-relay ?
Not as long as you don't specify "accept from any for any", or
"accept from any_publically_reachable_iface_or_address for any".
Eric.
--
You received this email because you are subscribed to the "misc@opensmtpd.org"
list
To unsubscribe, send mail with subject: [misc@opensmtpd.org] unregister
Re: Configuration update
On Thu, Aug 22, 2013 at 11:15:27AM +0200, Denis Fondras wrote:
> Hello all,
>
> It is me again :)
>
> I have two questions about OpenSMTPd configuration update.
> First is about updating tables.
>
> I have a table named "mytable". When I do :
>
> # smtpctl update table mytable
> command succeeded
> # smtpctl update table mytaable
> command succeeded
>
> For the latter, I get "warn: Lookup table not found: "mytaable"" in the
> logs.
> Shouldn't smtpctl notify that the table is inexistent ?
I have started to fix that for some commands, but it's not done yet.
> My second question is about re-scheduling an envelope after a
> configuration change. Let's say I have such a smtpd.conf :
> --
> listen on all
> accept for domain "example.com" deliver to mbox
> accept for any relay
> --
>
> I send a mail to de...@example.org, it will get relayed. If the
> destination server is down, the mail will enqueued and retried later.
>
> Then I decide that example.org is local, I reload OpenSMTPd with this
> smtpd.conf :
> --
> listen on all
> accept for domain { example.com, example.org } deliver to mbox
> accept for any relay
> --
>
> If I launch "smtpctl schedule all", OpenSMTPd will try to send it
> remotely again.
> How to tell OpenSMTPd it should deliver it locally now ?
Currently you can't (except by hand-editing the envelopes).
The ruleset is only evaluated on incoming mails, and the routing
parameters are hard-coded in the envelope.
Eric.
--
You received this email because you are subscribed to the "misc@opensmtpd.org"
list
To unsubscribe, send mail with subject: [misc@opensmtpd.org] unregister
Re: first-time user feedback
On Sat, Aug 24, 2013 at 11:11:34AM +1200, Richard Procter wrote:
> Hi guys,
>
> Thanks for opensmtpd! Gratifying to see sharp guys
> writing good, and well documented, software.
Thanks!
> Just wanted to give some feedback having sat down this
> morning to play with opensmtpd for the first time.
>
> I started with:
>
> listen on internal port submission tls-require tag submit
> accept tagged submit for domain foo.bar \
>virtual { richard = localusername } deliver to maildir
>
> , which is wonderfully legible and concise.
>
> I expected the accept line to match for tls connections
> to my internal interfaces, but sending to rich...@foo.bar
> was rejected:
>
> smtp-in: New session 0001ce65d943 from host orchid.internal
> [192.168.1.65]
> debug: session_start_ssl: switching to SSL
> smtp-in: Started TLS on session 0001ce65d943: version=TLSv1/SSLv3,
> cipher=AES128-SHA, bits=128
> smtp-in: Failed command on session 0001ce65d943: "RCPT
> TO:" => 550 Invalid recipient
> smtp-in: Closing session 0001ce65d943
> debug: smtp: 0x85d03000: deleting session: done
>
> I would have taken less time to diagnose the problem if
>
> # smtpctl trace rules
>
> explicitly mentioned when no rules matched.
Matching on the tag is not enough if "internal" is not the local machine.
As it is written, your rule matches only locally enqueued mails. What you
want is maybe something like:
listen on internal port submission tls-require
accept from any for domain foo.bar virtual { richard = localusername } \
deliver to maildir
The tag is not necessary in that case, since you only have one listener.
You could also restrict to "from internal", but that won't work directly
unless you specify an IP directly (or set of IPs), because hostnames are
not resolved in the "from" clause.
Eric.
--
You received this email because you are subscribed to the "misc@opensmtpd.org"
list
To unsubscribe, send mail with subject: [misc@opensmtpd.org] unregister
Re: CONFIG PR0N !?
On Thu, Oct 03, 2013 at 04:50:27PM +0200, Gilles Chehade wrote:
> OHAI !
>
> Today is CONFIG PR0N !? day
>
> Please share your config files in this thread ;-)
===
table aliases "/etc/mail/aliases"
table secrets "/etc/mail/secrets"
table relays { poolp.org, opensmtpd.org }
listen on lo0
accept for local alias deliver to mbox
accept for domain relay
accept for any relay via tls+auth://ne...@smtp-av.nerim.net auth
===
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Memory Leaks
On Mon, Oct 21, 2013 at 02:31:49PM +0200, Jason A. Donenfeld wrote: > >Hi, >I am now on bad terms and have a bit of a tarnished reputation with >family, friends, and importantly, with clients. OpenSMTPD leaks. I >don't know exactly where or how, but it does. I've been running it on a >system with 256megs of ram, and seemingly randomly, it will eat up all >the ram and then OOM. I've now put it on a system with a gig and a half >of memory and written some auto restarter scripts. But this shouldn't >be required. A gig and a half and fancy restarter scripts for an MTA? >C'mon. I'm not sure how I should even go about debugging this to be >constructive, as it's running on a mission critical production server. >So, can we plug these? How can we plug these? What do we do? This >problem is serious and lots of people are furious at me, and I can't >just keep apologizing. >Jason Thank you so much for the quality of your bug report. So here is an idea to plug the leak: take a piece of paper, write the license on it, roll it, and stick it up some sphincter on your server. Seriously... -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Invalid backend configuration error
On Fri, Jan 03, 2014 at 01:04:33PM -0800, Scott Vanderbilt wrote: > When I try to check my configuration file on a relay server, I get the > following error: > >/etc/mail/smtpd.conf:10: invalid backend configuration for >table secrets > > The secrets files looks okay. At least, it consists of one line which > conforms to the model "label username:password". > > Permissions of the secrets.db file are root:_smptd and mode is 640. > > My smtpd.conf file is as follows: > > listen on all > > table aliases db:/etc/mail/aliases.db > table domains file:/etc/mail/domains > table secrets db:/etc/mail/secrets.db > > accept for local alias deliver to mbox > accept from any for domain relay backup \ > relay.example.com > > Can someone please enlighten me as to what I am doing wrong that is causing > this error? Thank you. Are you sure /etc/mail/secrets.db really a db file, created with makemap? Anyway, you should consider using a plain text file for a simple table like this. Eric. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Understanding the table API
On Thu, Jan 09, 2014 at 01:39:27AM +0100, Michael Neumann wrote:
> Hi there,
Hi!
> I have a question regarding the table API for external services like
> Postgresql etc.
> Please correct me if I am wrong. So far I understand the purpose of the
> callbacks as follows:
>
> * UPDATE - recheck configuration file
>
> * CHECK - just check for the existence of a key. Only returns -1, 0 or 1,
> i.e. failure, not found, found.
>
> * LOOKUP - that returns actual data, e.g. "user_id:password" etc.
>
> * FETCH - *That's where I am not sure*. It caches the rows of a table within
> a dictionary (which it
>updates every once in a while) and returns tuple after tuple upon each
> call to e.g.
>table_postgres_fetch. I.e. this function is called many times. This is
> only used for K_SOURCE, i.e.
>netaddr tables. This kind of lookup fails for a large number of entries.
>
> I was planning to add support for redis tables to opensmtpd and use it to
> reject based upon the sender's IP,
> similarily to what DNSRBL is doing. But this seems to be not possible with
> netaddr tables right now, unless
> it's rewritten a bit, i.e. to first issue a CHECK to the table, followed by
> a FETCH. Would a change like that
> be accepted, is it useful?
I am not sure to understand what do you mean. FETCH is only used by
the mta to retrieve an ip address to use when connecting.
It is currently not possible to do IP filtering at the connection level.
We need finish the filter API (yeah, we slacked a bit on this).
For now, you can also solve your problem with something like:
table redis-bl redis:
reject from source
or
accept from source for any virtual { "@" "error: 550 Sorry,
you are blacklisted" }
The only issue is that filtering occurs at SMTP transaction time, not at
connection time.
But that's probably a good compromise.
Eric.
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Building snapshots on 5.5-stable?
On Tue, May 06, 2014 at 10:17:01AM +0100, John Cox wrote: > Hi > > Is it possible to build snapshots on OpenBSD-5.5-Stable (built from > source because as far as I can tell the release ISO still contains > Heartbleed)? > > Neither the OpenBSD or the Portable version works for me. I can > understand that the OpenBSD version tracks current and may fail to > build at any point, but I was hopeful theat the portable vsrsion might > be more portable... > > I'd like to follow this project and maybe help if I ever have the time > (which is, at the moment, I admit, unlikely) but I really don't have > the time to try and follow OpenBSD-current > > Many thanks > > John Cox Hi, Sorry for the breakage. The new snapshot should now work on both current and stable. Please try it out. Eric. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: 550 message rejected with -latest
On Tue, May 13, 2014 at 09:33:08AM +0200, Gilles Chehade wrote: > On Mon, May 12, 2014 at 11:08:37AM -0700, Barbier, Jason wrote: > > So now my sqlite tables all work \o/ but the filter agent rejects mail, any > > ideas? > > > > May 12 18:04:22 mail2 smtpd[21150]: smtp-in: New session 54c8e10f508ce2ba > > from host localhost > > [127.0.0.1] > > May 12 18:04:22 mail2 smtpd[21150]: filter: new query QT_EVENT EVENT_CONNECT > > May 12 18:04:22 mail2 smtpd[21150]: filter: draining query > > 54c8e1108ba80a3e[QT_EVENT,EVENT_CON > > NECT] > > May 12 18:04:22 mail2 smtpd[21150]: filter: new query QT_QUERY QUERY_CONNECT > > May 12 18:04:22 mail2 smtpd[21150]: filter: draining query > > 54c8e1119e9b4811[QT_QUERY,QUERY_CON > > May 12 18:04:48 mail2 smtpd[21150]: filter: query 54c8e114eb41f10d done: > > status=FILTER_OK code > > =0 response="(null)"2 smtpd[21150]: filter: query 54c8e1119e9b4811 done: > > status=FILTER_OK code > > May 12 18:04:49 mail2 smtpd[21150]: filter: new query QT_QUERY QUERY_DATA > > May 12 18:04:49 mail2 smtpd[21150]: filter: draining query > > 54c8e115f4baf319[QT_QUERY,QUERY_DAT > > A]y 12 18:04:28 mail2 smtpd[21150]: filter: draining query > > 54c8e1129ff84e50[QT_QUERY,QUERY_HEL > > May 12 18:04:49 mail2 smtpd[21150]: filter: query 54c8e115f4baf319 done: > > status=FILTER_OK code > > =0 response="(null)"2 smtpd[21150]: filter: query 54c8e1129ff84e50 done: > > status=FILTER_OK code > > May 12 18:04:49 mail2 smtpd[21150]: filter: chain input is 6 > > May 12 18:04:51 mail2 smtpd[21150]: filter: new query QT_QUERY QUERY_EOML > > May 12 18:04:51 mail2 smtpd[21150]: filter: draining query > > 54c8e116d4b1227e[QT_QUERY,QUERY_EOM > > ]=kusur...@serversave.us] > > May 12 18:04:51 mail2 smtpd[21150]: filter: datalen mismatch on session > > 54c8e10f508ce2ba: 186/ > > 181: No such file or directory > > May 12 18:04:51 mail2 smtpd[21150]: smtp-in: Failed command on session > > 54c8e10f508ce2ba: "data > > " => 530 Message rejectedpd[21150]: filter: draining query > > 54c8e114eb41f10d[QT_QUERY,QUERY_RCP > > May 12 18:04:55 mail2 smtpd[21150]: smtp-in: Received disconnect from > > session 54c8e10f508ce2ba > > > > Eric ? > > > May 12 18:04:51 mail2 smtpd[21150]: filter: datalen mismatch on session > > 54c8e10f508ce2ba: 186/181: No such file or directory > > This looks similar to something we had already fixed before changing the > master branch and losing the changes no ? I'll investigate. The current code should work when no filter is plugged. At least that's what happen here.. Eric. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: All messages on localhost bein rejected!
On Tue, May 13, 2014 at 07:53:51PM -0700, Barbier, Jason wrote: > >It seems to be wide spread eirc did you get a chance to look at it. Sorry about that. I'll try to have a look today. Eric. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: All messages on localhost bein rejected!
On Tue, May 13, 2014 at 07:53:51PM -0700, Barbier, Jason wrote: > >It seems to be wide spread eirc did you get a chance to look at it. Hi, I (hopefully) fixed it. It will be in the next snapshots. Eric. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: [OpenSMTPD] master snapshot opensmtpd-201405142324 available
On Thu, May 15, 2014 at 09:21:04AM +0100, John Cox wrote: > Hi > > It almost works for me on OpenBSD5.5-stable. > > Compiles, runs, delivers and then dies > > Many thanks > > John Cox Hi, I can reproduce your crash. It should be fixed shortly. Eric. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: iobuf strategy when reading vs writing
On Thu, Jul 17, 2014 at 06:31:14PM +0200, Vincent Gross wrote: > Hi folks, > > I have to implement a buffer mechanism in a daemon I'm writing, and I am > reading various pieces of high-quality software (that all happen to be > part of openbsd source tree (yes I am lazy)) to compare how it's done. > That includes of course OpenSMTPd. > > I took a look at iobuf.c, and as I understand it when they are used to > read data you use realloc(3) to extend the size of a single char array, > but to write you chain several char arrays into an iovec. > > Why did it end up this way ? More precisely, are there any drawbacks in > using an iovec to read inbound data ? It ended up like this because it's convenient. It is much easier for the API user to read input data from a single linear buffer. In smtpd we want to split lines on "\r\n" so we don't need to write contorted code to deal with lines potentially spanning several buffers. And since you always want to limit the amount of input data buffered it's not a big problem to have that space allocated once. The only drawback is that you sometimes (when you need more data to consume what's there) have to move pending data back to the start of the buffer (iobuf_normalize). It could indeed be avoided by using that buffer as a ring buffer fed with an iovec, but again, the user we would have to deal with non-linear data. In smtpd we would probably re-linearize that anyway for processing. Eric. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: %{rcpt.user} in virtual table?
On Fri, Sep 19, 2014 at 01:22:33AM +0200, Peter Henning wrote:
> Hello
>
> Can the %{..} expansions be used in a "virtual " table? I'm
> trying to rewrite the domain part of incoming mail for a virtual
> domain, so that mail received for b...@a.com is mapped to b...@b.com
> and then relayed to B.local, like this:
>
> $ cat /etc/mail/smtpd.conf
> #
> table virtdomains file:/etc/mail/virtdomains
> table virtusers file:/etc/mail/virtusers
> #
> accept from any domain virtual
> accept from any for domain "B.com" relay via smtp://B.local
>
> $ cat /etc/mail/virtdomains
> A.com
>
> $ cat /etc/mail/virtusers
> @A.com %{rcpt.user}@B.com
>
> (Tested using 5.4.2p1 on Ubuntu). Doesn't work, the %{rcpt.user} is
> sent literally and not replaced with the original user-part of the
> mail.
>
> If there's a mistake or a better way please give me a clue?
>
> Thanks,
> Peter.
Hi Peter.
It doesn't work because format expansion only happens for the mda path.
But your suggestion is interresting. Maybe we can generalize it a bit.
Can you file a ticket on the tracker?
Thanks,
Eric.
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Announce: OpenSMTPD 5.4.4 released
> SHA256 (opensmtpd-5.4.4p1.tar.gz) = > 1118330aa54e9a8a30914a1f2e129a83f2954a5956300eade522a1396f6d8ebd Note that the portable version of OpenSMTPD now requires libasr: Oddly enough, it was just released a few days ago! https://www.opensmtpd.org/announces/libasr-1.0.0.txt Eric. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Announce: libasr 1.0.1 released
On Tue, Feb 03, 2015 at 12:04:51AM +0600, Denis Fateyev wrote: > >Just a small nit-picking. Once was a discussion about "license" >filename spelling. >[1]https://www.mail-archive.com/misc@opensmtpd.org/msg01513.html >Not a problem at all, but *might* be a small cleanup. My understanding is that LICENCE is a noun that refers to the "legal" document, while LICENSE is a verb that means "grant permission". Eric. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: opensmtpd 5.4.4 in freebsd 9 jail
On Tue, Feb 24, 2015 at 11:42:32AM +0100, Cedric Berger wrote: > Hello, > > Since I upgraded my freebsd 9 jail with the latest opensmtpd 5.4.4_1,1 port, > smtp-out refuse to send any email to the outside world. > > I've seen a similar issue reported by "Meutel" here, but with no apparent > solution: > > http://blog.gmane.org/gmane.mail.opensmtpd.general/day=20150211, 2nd post. > > Based on ktrace analysis, I believe the faulty code starts at line 210 of > getaddrinfo_async.c in libasr: > > https://github.com/OpenSMTPD/libasr/blob/libasr-1.0.1/src/getaddrinfo_async.c > > This code returns EAI_NONAME if there is no non-loopback interface > configured > in the jail. This is my case, as a jail by default has only loopback > interfaces configured (this doesn't prevent connecting to the outside > world). > > If my analysis is correct, I believe that if no non-loopback interface is > found, the code should also (in a second step) consider loopback interfaces > when selecting IPv4 versus IPv6, instead of just bailing out. > > That would make the code more robust. Hello. I'll think how asr can be improved in the way you suggest. In the meantime, the regression you see is actually due to the following change in smtpd. Try without it. Note that it will also retreive inet6 addresses, so you might want to add "limit mta inet4" in smtpd.conf if inet6 is not routable on your system. Eric. diff --git a/smtpd/dns.c b/smtpd/dns.c index fc8bce6..ea5d430 100644 --- a/smtpd/dns.c +++ b/smtpd/dns.c @@ -448,6 +448,7 @@ dns_lookup_host(struct dns_session *s, const char *host, int preference) s->refcount++; memset(&hints, 0, sizeof(hints)); + hints.ai_flags = AI_ADDRCONFIG; hints.ai_family = PF_UNSPEC; hints.ai_socktype = SOCK_STREAM; as = getaddrinfo_async(host, NULL, &hints, NULL); -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: MDA command buffer length
On Mon, Oct 05, 2015 at 02:15:55PM +1300, Holger Jahn wrote:
> Hi there,
>
> After playing with MDA delivery in smtpd.conf on two servers, I found that
> there seems to be an internal command line buffer overflow after 256 bytes.
>
> Consider the following MDA config setting:
>
> deliver to mda "echo '%{sender}' '%{sender.user}' '%{sender.domain}' %{rcpt}
> '%{rcpt.user}' '%{rcpt.domain}' '%{dest}' '%{dest.user}' '%{dest.domain}'
> '%{user.username}' '%{user.directory}' >> /tmp/mX-cmd.tmp"
>
> However, all that will be executed is this part:
>
> echo '%{sender}' '%{sender.user}' '%{sender.domain}' %{rcpt} '%{rcpt.user}'
> '%{rcpt.domain}' '%{dest}' '%{dest.user}' '%{dest.domain}'
> '%{user.username}' '%{user.directory}' >> /tmp/mX
>
> i.e. there will be a file with the crippled name "/tmp/mX" after triggering
> the MDA command.
>
> Since I had a similar MDA command set up on another machine that worked, I
> figured that the buffer overflow must be happening AFTER format specifier
> expansion. When I filled in the values by hand I ended up with the magical
> number of 256 after which my command execution was clipped.
>
> So, here is my question, is this a feature or a bug? ;-)
This is indeed a regression in OpenSMTPD 5.7.*
We are working on a fix.
Thanks for the report.
Eric.
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: The OpenSMTPD audit, a debrief
On Fri, Oct 09, 2015 at 07:40:42PM +0200, Gilles Chehade wrote: > EHLO folks, > Nice write-up! I have often told you I'm impressed by your natural ability to justify the body of your mails, but today you clearly reached a new level, and your mastering of that art has moved from genius to perversion... :) Eric. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: please test upcoming release
On Thu, May 12, 2016 at 06:09:20PM +0200, Gilles Chehade wrote: > On Thu, May 12, 2016 at 06:01:10PM +0200, Gilles Chehade wrote: > > Hi, > > > > As you probably now, we've spent tons of time sync-ing back our github > > repository to OpenBSD to end up with a single working branch there. > > > > We wanted to sync our releases with OpenBSD, however this year the May > > release came up early and we weren't ready in time for portable. > > > > I'd like to make a release, hopefully next week, so both OpenBSD users > > and users of other systems can run the most recent release including a > > lot of improvements, a couple reliability fixes and a much more secure > > offline enqueuer. > > > > Please test these tarballs, make sure that they build and work for you > > and that you'd be happy if I released this as a followup to 5.7.3, and > > keep in mind that it is not a feature release, don't expect lot of new > > stuff, it's just a cleaner release codewise, one that fixes bugs which > > may bite some users, and a way to get back to OpenBSD release cycle to > > start working on new features. > > > > OpenBSD version: > > http://poolp.org/~gilles/opensmtpd-5.9.2-rc1.tar.gz > > > > Portable version: > > http://poolp.org/~gilles/opensmtpd-5.9.2p1-rc1.tar.gz > > > > > > Do test asap, the longer we lock on 5.9.2, the longer we are not doing > > new OpenSMTPD work. > > > > Feel free to reply to this thread with a short message telling us which > distro/system you used, if build was ok and if you could run basic test > with it. > > I already had feedback for FreeBSD OK and Gentoo OK, keep 'em coming. seems ok on a debian 8.3 Eric. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: util.c patch
On Sat, Sep 24, 2016 at 08:42:25PM -0500, Edgar Pettijohn wrote:
> Enforce stricter rfc helo compliance.
> --
> Edgar Pettijohn
I am pretty sure res_hnok already does that check.
Eric.
> Index: util.c
> ===
> RCS file: /cvs/src/usr.sbin/smtpd/util.c,v
> retrieving revision 1.128
> diff -u -p -u -r1.128 util.c
> --- util.c31 Aug 2016 10:18:08 - 1.128
> +++ util.c25 Sep 2016 01:41:34 -
> @@ -495,6 +495,9 @@ valid_domainpart(const char *s)
> struct in6_addr ina6;
> char*c, domain[SMTPD_MAXDOMAINPARTSIZE];
> const char *p;
> + size_t len;
> +
> + len = strlen(s);
>
> if (*s == '[') {
> if (strncasecmp("[IPv6:", s, 6) == 0)
> @@ -519,8 +522,9 @@ valid_domainpart(const char *s)
> return 0;
> }
>
> - if (*s == '\0')
> + if (*s == '\0' || s[0] == '.' || s[len - 1] == '.') {
> return 0;
> + }
>
> return res_hnok(s);
> }
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Old clients fail to establish SSL Connection to 6.9
On Fri, May 07, 2021 at 01:42:52AM +0200, Markus Julen wrote: > Hi all! > > Having just moved a small "outgoing only" mailserver to 6.9, I started to > receive error messages: > > > 80008bb60b9428ed smtp connected address=X.X.X.X host=z.z.z > > 80008bb60b9428ed smtp disconnected reason="io-error: handshake failed: > > error:1402610B:SSL routines:ACCEPT_SR_CLNT_HELLO:wrong version number" > > No filters, nothing, just plain smtpd. 6.8 worked flawlessly. > > Has anyone managed to tweak the "cipher" option to the "listen" directive? > Any other options to try? > > Telling everyone to upgrade their mail client is probably no option as of > now... Hello. Have a look at the tls_config_set_protocols(3) manpage for the protocols and ciphers options. You can try with something like: listen on ... tls protocols "legacy" ciphers "compat" Eric.
