Filters guidance request
Namaste misc, I was wondering whether the absence of filters on the 6.5 [1] and current smtpd.conf(5) [2] manpages along with the modest OpenSMTPD 6.5.0 release notes [3] should be read into. In other words, are filters ready for general use? Dhanyavaad. Regards, ab [1] - https://man.openbsd.org/OpenBSD-6.5/smtpd.conf [2] - https://man.openbsd.org/smtpd.conf [3] - https://www.openbsd.org/65.html -|-|-|-|-|-|-|-- -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Thoughts and queries (n=1) on the filter API
Bonjour Monsieur Gilles,
> To reject a session based only on reporting events, you should subscribe
> to the relevant events in order to gather the info you want, then to one
> filter event to actually perform the action of rejecting.
>
> For example, I could subscribe to tx-connect, tx-helo and tx-ehlo to get
> source address, rdns, fcrdns and helo name from reporting events, but to
> reject the session based on this information I must decide when I want a
> rejection (do i want to reject at MAIL FROM ? RCPT TO ? DATA ? COMMIT ?)
> and register for appropriate filter event to actually reject a session.
>
> Builtin filters are a bit special because we are going to be VERY, VERY,
> VERY selective about them. Anything that can be done with a builtin, can
> be done with a proc filter and proc filters don't run in the same memory
> space so ... a good approach is to write a proc filter and if we find it
> makes sense to convert to a builtin, it can be discussed.
Understood. To be transparent on my side as well, I am primarily
interested in the Postfix filters listed in Craig Skinner's mail on
openbsd-misc [1].
An example is reject_unknown_helo_hostname, "Reject the request when
the HELO or EHLO hostname has no DNS A or MX record" - one might want
to add "DNS " to it.
This filter could reject the connection at helo/ehlo with "I had you at
helo", but as an external filter, will have to wait till one of the
filter phases.
> > > > 3) Are there time limits for a filter to return response?
> > > >
> > >
> > > time limits are not implemented yet, but yes there will be a time limit,
> > > very likely related to the SMTP session timeouts.
> > >
> > > it's not tricky to implement, it'll be a notification sent to the filter
> > > that the last query timed-out and it shouldn't respond anymore.
> > >
> > > this will result in a Temporary Failure in the SMTP session, filters are
> > > not allowed to exceed that timeout.
> >
> > So if in a chain {f1,f2,f3}, if f2 takes too much time to respond, both
> > f1 and f3 will be notified of the session timeout.
> >
>
> yes, definitely.
>
> in filter chains, all filters always receive all _reporting_ events.
>
> this is a reason why report and filters are separate, if you look at the
> connect phase, all filters will receive the tx-connect report event THEN
> the connect filter event is triggered and all filters may not receive it
> because first filter may reject. if it rejects, then the reporting event
> tx-disconnected is sent to all filters.
>
> the action of a filter will never prevent all filters from receiving the
> report events.
Thanks. That is great to know.
> > > > 7) In lka_filter.c, if a filter feeds back more than LINE_MAX, should
> > > > we handle that?
> > > >
> > > > (void)strlcpy(buffer, line, sizeof buffer);
> > > >
> > >
> > > that's an interesting question.
> > >
> > > LINE_MAX is not the correct value but we need to have a maximum value
> > > for the line and filters will need to ensure they don't produce lines
> > > bigger than these.
> >
> > Understood. I based the LINE_MAX on the following within lka_filter.c:
> > int
> > lka_filter_process_response(const char *name, const char *line)
> > {
> > ...
> > char buffer[LINE_MAX];
> > ...
> > (void)strlcpy(buffer, line, sizeof buffer);
> >
>
> yes, I had to start with something.
>
> to be very transparent my goal was to get behaving filters to fully work
> before the end of the year, then jan/feb/mar will be to ensure smtpd can
> cope with misbheaving filters.
>
> the areas we know need to be improved:
>
> - all kinds of timeouts: smtp session timeout, filters timeout, ...
> - all kinds of DATA issues: filter responding with end of message, while
> client hasn't responded with end of message yet, ...
> - all kinds of exhaustions: failure to allocate filter sessions, failure
> to send data to filters because the pipe is exhausted, ...
> - all kinds of filters fuckup: filters responding with bad phases or bad
> sessions or bad action, etc... some are bugs, some are legit, ...
>
> now that we know filters work, including in chains, we can focus on what
> is needed to make them rock solid for April :-)
Completely understand. My queries were from the perspective of getting
to understand the interfaces, and also as a defensive measure against
misbehaving filters. And since volks will write misbehaving filters, we
would need to guard against them.
Dhanyavaad.
Regards,
ab
[1] - https://marc.info/?l=openbsd-misc&m=153804263417563&w=2
-|-|-|-|-|-|-|--
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Thoughts and queries (n=1) on the filter API
Bonjour Monsieur Gilles,
Merci beaucoup for your exhaustive explanations.
> > 1) What is the difference between the "report" and "filter" prefixes?
> > My current understanding is that "report" is oriented towards reporting
> > and "filter" is oriented towards writing filters.
> >
>
> very simple:
>
> - event reporting lets smtpd notify filters of any event that leads to
> a change in the SMTP session, they are informative and do not accept
> any answer.
>
> - event filtering lets smtpd notify filters of any event that leads to
> a decision in the SMTP session, they are decisive and require that a
> filter provides a decision.
>
> report lines are one way from smtpd to filters, filters must not reply
>
> filter lines are two way between smtpd and filters, for any request an
> answer is required.
>
> both reporting and filtering are "subscribed" so filters will only get
> the events they subscribed to.
So in case one wants to reject a session based only on reporting events,
one still has to wait till the filter events start coming in. Or one
could write a built-in like fcrdns. Is this correct?
> > 3) Are there time limits for a filter to return response?
> >
>
> time limits are not implemented yet, but yes there will be a time limit,
> very likely related to the SMTP session timeouts.
>
> it's not tricky to implement, it'll be a notification sent to the filter
> that the last query timed-out and it shouldn't respond anymore.
>
> this will result in a Temporary Failure in the SMTP session, filters are
> not allowed to exceed that timeout.
So if in a chain {f1,f2,f3}, if f2 takes too much time to respond, both
f1 and f3 will be notified of the session timeout.
> > 5) Could we have the filter builtin for helo be different from the
> > ehlo? It might be instructional to understand that the client asked
> > for ehlo.
> > { FILTER_EHLO, "ehlo", filter_builtins_helo },
>
> it is already the case, helo and ehlo are different filter hooks:
>
>filter foo1 builtin helo [...]
>filter foo1 builtin ehlo [...]
>
> the same applies for proc filters, they can subscribe to helo and ehlo
> as different filtering events.
I may be wrong here, but I was unable to find a filter_builtins_ehlo in
the code. From lka_filter.c
..
static int filter_builtins_notimpl(struct filter_session *, struct filter
*, uint64_t, const char *);
static int filter_builtins_connect(struct filter_session *, struct filter
*, uint64_t, const char *);
static int filter_builtins_helo(struct filter_session *, struct filter *,
uint64_t, const char *);
static int filter_builtins_mail_from(struct filter_session *, struct
filter *, uint64_t, const char *);
static int filter_builtins_rcpt_to(struct filter_session *, struct filter
*, uint64_t, const char *);
..
{ FILTER_CONNECT, "connect", filter_builtins_connect },
{ FILTER_HELO, "helo", filter_builtins_helo },
{ FILTER_EHLO, "ehlo", filter_builtins_helo },
{ FILTER_STARTTLS, "starttls", filter_builtins_notimpl },
..
> > 7) In lka_filter.c, if a filter feeds back more than LINE_MAX, should
> > we handle that?
> >
> > (void)strlcpy(buffer, line, sizeof buffer);
> >
>
> that's an interesting question.
>
> LINE_MAX is not the correct value but we need to have a maximum value
> for the line and filters will need to ensure they don't produce lines
> bigger than these.
Understood. I based the LINE_MAX on the following within lka_filter.c:
int
lka_filter_process_response(const char *name, const char *line)
{
...
char buffer[LINE_MAX];
...
(void)strlcpy(buffer, line, sizeof buffer);
Dhanyavaad.
Regards,
ab
-|-|-|-|-|-|-|--
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Thoughts and queries (n=1) on the filter API
Bonjour Monsieur Gilles,
To start with, Merci Beaucoup for all the effort and patience.
I think there might an inadvertent interchanging of the comments
in your blog post titled "more on OpenSMTPD filters" [1]:
..
listen on all filter# not filtered
listen on socket# filtered
..
If I am not wrong, the first comment might be "filtered" and the second
might be "not filtered".
In terms of the filter API, I base my thoughts and queries on the python
API, blog posts, rspamd filter and the committed code in CVS.
1) What is the difference between the "report" and "filter" prefixes?
My current understanding is that "report" is oriented towards reporting
and "filter" is oriented towards writing filters.
2) How would one handle failures within external filters? Is there a
mechanism to signal to the SMTP filter chain to remove oneself?
3) Are there time limits for a filter to return response?
4) Suppose there are three filters {f1,f2,f3} in a chain. If f3 rejects
the connection, do f1 and f2 get notified?
5) Could we have the filter builtin for helo be different from the
ehlo? It might be instructional to understand that the client asked
for ehlo.
{ FILTER_EHLO, "ehlo", filter_builtins_helo },
6) Could we add the reason for rollback in tx-rollback? If I am not
wrong, a client can rollback using RSET, QUIT or HELO/EHLO within a
transaction.
7) In lka_filter.c, if a filter feeds back more than LINE_MAX, should
we handle that?
(void)strlcpy(buffer, line, sizeof buffer);
8) What if the SMTP input/output or the filter input/output contains "|"
as a character - would the separator processing still work?
I am not sure all my queries above are relevant or correct, so in case
they do not make sense, I apologize.
Dhanyavaad.
Regards,
ab
[1] - https://poolp.org/posts/2018-12-19/more-on-opensmtpd-filters/
[2] - https://poolp.org/posts/2018-11-09/opensmtpd-reporting-update/
-|-|-|-|-|-|-|--
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: FCrDNS check implemented
> > i) Resolve 29.3.20.19 to the set of hostnames. If no hostname is > > returned, reject connection. > > > > Yes, however it is not recommended to use multiple PTR records for an IP > address, and the behavior is unspecified by the RFC as far as I know. If > you specify multiple PTR records, things will not work as you want. This > is not an OpenSMTPD thing but a DNS thing. I was not aware of the behaviour being unspecified in case of multiple PTR records for an IP. Merci beaucoup Gilles for pointing it out. > > In case I have understood this incorrectly, I apologize. I have based > > this flow on my understanding of the "reject_unknown_client_hostname" > > feature of Postfix [1]. > > > > Yes, they are alike. Understood. If I may ask, are there other similar filters that you plan to implement? I did gather from the FAQ mail thread that the functionality of dkim-proxy may be implemented as an in-built filter. Dhanyavaad. Regards, ab -|-|-|-|-|-|-|-- -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: FCrDNS check implemented
Monsieur Gilles,
> helo misc@,
>
> I wrote an article a few days ago:
>
> https://poolp.org/posts/2018-12-06/opensmtpd-proc-filters-fc-rdns/
>
>
> Since then, I implemented the check-fcrdns builtin filter allowing us to
> filter incoming sessions that do not have a valid FCrDNS.
>
> How does it work ?
>
> 1- configure your listener to be filtered
> 2- add a filter hook on whatever phase you want to trigger the check on
>
>[...]
>listen on all filter
>
>filter smtp-in connect check-fcrdns disconnect "550 GO AWAY, PUNK"
>[...]
>
> This will result in smtpd replacing the welcome banner with the message,
> then dropping the client connection if they don't have a reverse DNS and
> a matching forward DNS. You can apply the check at further phases if you
> need to log more details, this is up to you.
Thank you for the check-fcrdns filter. Would it be possible for you to
please share your thoughts on the filter, specifically the checks that
the filter performs.
Given a client IP 29.3.20.19 trying to send email, which of these
checks will the filter perform?
i) Resolve 29.3.20.19 to the set of hostnames. If no hostname is
returned, reject connection.
ii) Suppose 29.3.20.19 resolves to { brexit.eu, reunite.uk }. Next
resolve the set of hostnames to a set of IP addresses. If no IP address
is returned for any of the hostnames, reject connection.
iii) Suppose some hostnames do resolve to a set of IP addresses. If
29.3.20.19 is not present in the set of IP addresses, reject connection.
In case I have understood this incorrectly, I apologize. I have based
this flow on my understanding of the "reject_unknown_client_hostname"
feature of Postfix [1].
Merci Beaucoup / Danke Schön / Arigatou Gozaimasu / Dhanyavaad.
Regards,
ab
[1] - http://www.postfix.org/postconf.5.html
-|-|-|-|-|-|-|--
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: FAQ gone?
Hi Gilles, Thank you for your elaborate response. > if someone steps up to do the work, I will happily welcome the FAQ again > but it needs to be someone who commits to that work, not someone that'll > write the pages dump them once and disappear. >From what I understand, the primary requirement for a -current FAQ is consistent maintenance of the FAQ. A secondary requirement is to constantly evaluate the need of / interaction with external software components viz. spamd, dkim-proxy, dovecot et al. Currently I am not in a position to pick up the FAQ maintainership or contribute in a meaningful way. I am sorry for that. Having said that, just in case someone thinks they could take up the FAQ maintainership, would it be possible for you to please share the outline of the expectations from an FAQ maintainer? Dhanyavaad. Regards, ab -|-|-|-|-|-|-|-- -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: FAQ gone?
Hi Gilles, > On Wed, Dec 12, 2018 at 06:39:59PM +, mabi wrote: > > Hi, > > > > I was wondering where did the FAQ section on the opensmtpd.org website > > disappear? > > > > It had useful setup examples with LMTP and Dovecot if I remember > > correctly... > > > > The FAQ was inaccurate and no one step and committed to maintain it. > > This resulted in people mailing me in private all the time to ask why an > example from the FAQ was not working for them. > > Not opposed to having a FAQ but I can't be the one maintaining it and it > needs to be _actively_ maintained up-to-date, not just created once then > forgotten, otherwise this means additional work for me. Would it be correct to say that the reason for the FAQ going out of sync with the code is the set of changes to the grammar? If that is the case, I propose the following OpenSMTPD operating procedure: When the grammar changes start, hide the FAQ. Once the grammar changes are stabilized, update FAQ, unhide FAQ. If I am not wrong, the new grammar is likely to persist for the foreseeable future. As such, once the new grammar stabilizes, the need for maintaining/rewriting the FAQ would be minimal. To generalize even more: When wholesale breaking changes start, hide FAQ. When changes are stable, update FAQ, unhide FAQ. An analogy would be svn lock and svn unlock once changes are committed. This would balance the need to constantly update the FAQ with the usefulness of the FAQ in helping volks in getting started with OpenSMTPD. Dhanyavaad. Regards, ab -|-|-|-|-|-|-|-- -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Opensmtpd failover
Hello Craig, > > But why? Just deliver it and be done. Can't see many drawbacks in > > that. > > > > Backup MX servers don't have any mail storage, nor IMAP/POP daemon. > > They are another hop along the delivery path to the primary MX servers. > > > > Backup MX machines are not the message's final destination;- > > Pretend you are going to the world's biggest party, which is held every > New Year's Eve in Edinburgh, so you board an aeroplane to Edinburgh. > > But the snow hits Scotland, so your aeroplane lands in London. England > is not your final destination. It is a backup airport in a different > country. You have not travelled to the party capital. So you wait/spool > in London until Edinburgh airport is receiving traffic. Then then you > get the next flight to your final destination & Hogmanay for 3 days. Thank you for the excellent analogy. I will now never forget that Edinburgh is The Party Capital. And that Scotland is a different country than England :) . Regards, ab -|-|-|-|-|-|-|-- -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Vacation with smtpd doesn't work in 6.4
-m...@openbsd.org +misc@opensmtpd.org [ Original mail thread - https://marc.info/?t=15422935034&r=1&w=2 ] Thank you Penty for pointing out the relevant RFC section. I was unaware of STARTTLS being optional. So I tried to understand the RFC requirement. > RFC 2487: > > A publicly-referenced SMTP server MUST NOT require use of the > STARTTLS extension in order to deliver mail locally. This rule > prevents the STARTTLS extension from damaging the interoperability of > the Internet's SMTP infrastructure. A publicly-referenced SMTP server > is an SMTP server which runs on port 25 of an Internet host listed in > the MX record (or A record if an MX record is not present) for the > domain name on the right hand side of an Internet mail address. RFC 2487 was written in Jan 1999. RFC 3207, which obsoletes RFC 2487, was written in Feb 2003. Both of these contain the above text. >From a purely security perspective, a mail received over TLS is preferable over a mail received in the clear. At the same time, there is a non-negligible risk [1] of dropping incoming mails, if one adopts the "tls-require" posture. Is there a mechanism in OpenSMTPD by which mails delivered in the clear can be identified/logged/reported/flagged? The idea is to extract a list of domains from these mails. These domains can then be contacted and encouraged to adopt STARTTLS. This domain list will be specific for every mail server. If a domain chooses to adopt STARTTLS, future mails from that domain will be delivered over TLS. If a domain chooses to not adopt STARTTLS, the mail server administrator can choose to either do nothing or take some action. This action could be to contact the end-users and educate them or to block mail from this particular domain in case the mails are of a sensitive nature. At some point in future, a significant majority of incoming mails for the mail server could be delivered over TLS. If this problem has already been/could be solved in a better way, I would request you to please share the mechanism. Thanks. Regards, ab [1] - https://transparencyreport.google.com/safer-email/overview -|-|-|-|-|-|-|-- -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
bgp-spamd mailing list
Hi Postmasters, This is not directly related to OpenSMTPD, so I apologize in advance. For me, from https://www.bgp-spamd.net/mail.html: 1) Clicking on http://mailman.theapt.org/listinfo/bgp-spamd list page leads to 404. 2) Clicking on http://mailman.theapt.org/pipermail/bgp-spamd archive page leads to 404. 3) Sending a blank message to bgp-spamd-subscribe at bgp-spamd dot net does not result in any subscription response email from the mailing list. So, could someone please confirm: 1) Is the bgp-spamd.net mailing list active? 2) Are there any publicly accessible archives of this mailing list? Thanks. Regards, ab -|-|-|-|-|-|-|-- -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: smtpd new config
> > 2) If I may ask, does this new release incorporate the smtpfd filter > > redesign that you mentioned on the "Rework filters" GitHub issue [2] > > and the EuroBSDCon 2017 presentation ? > > > > the next issue being 6.4 in October / November, it depends on how much > progress has been done with smtpfd by then. > > there is a chance we have some poc by then, there's a chance we're too > close to release and prefer to skip it. > > it's too early to know what we'll have by the end of this summer Thank you Gilles for your helpful reply. I completely understand. I hope that smtpfd makes it along with the new config - that would be an awesome release. Also, this mail thread in a way validates that the new config OpenSMTPD works. I look forward to using it in -current, as and when it lands. Regards, ab. -|-|-|-|-|-|-|-- -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: smtpd new config
Hi Gilles, In your blog post introducing the new config OpenSMTPD, you have mentioned that the new release will be hitting -current in a few days/weeks [1]. 1) In order to prepare for this change, it would be great if you could please share whether OpenSMTPD-Extras will work with this release? 2) If I may ask, does this new release incorporate the smtpfd filter redesign that you mentioned on the "Rework filters" GitHub issue [2] and the EuroBSDCon 2017 presentation ? Merci Beaucoup. Regards, ab [1] - https://poolp.org/posts/2018-04-30/opensmtpd-new-config/ [2] - https://github.com/OpenSMTPD/OpenSMTPD/issues/773 -|-|-|-|-|-|-|-- -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: AW: Greylist-like support
>From my limited understanding reading the GitHub issues, OpenSMTPD is being modified in a way that will help resolve certain problems that OpenSMTPD was facing. [1][2][3] Monsieur Gilles Chehade has tweeted that he has a version with the newer configuration file format. [4] On this list, I have requested for some information on the newer version this week. Specifically, the distribution mechanism of the snapshots, the suitability for production and the feasibility to use the OpenSMTPD-extras with the newer version. For an overview, please refer to the excellent talk titled "OpenSMTPD, current state of affairs" by Monsieur Gilles Chehade. [5][6] Regards, ab [1] - https://github.com/OpenSMTPD/OpenSMTPD/issues/773 [2] - https://github.com/OpenSMTPD/OpenSMTPD/issues/772 [3] - https://github.com/OpenSMTPD/OpenSMTPD/milestone/5 [4] - https://twitter.com/PoolpOrg/status/973318245812985857 [5] - https://www.openbsd.org/papers/eurobsdcon2017-opensmtpd.pdf [6] - https://www.youtube.com/watch?v=wnhvn1rsXR8 -|-|-|-|-|-|-|-- Sent: Saturday, April 07, 2018 at 11:12 AM From: "Reio Remma" To: misc@opensmtpd.org Subject: Re: AW: Greylist-like support Unfortunately (message from Gilles): FILTERS ARE NOT READY. THEY ARE EXPERIMENTAL. THEY ARE MEANT FOR DEVELOPERS, NOT USERS. IF YOU RUN A FILTER, YOU'RE ON YOUR OWN. :) Reio On 07.04.2018 10:38, Michael Taubert wrote: e.g. https://github.com/ajdiaz/opensmtpd-filter-spam additional filters can be found here https://github.com/OpenSMTPD/OpenSMTPD-extras/tree/751c7b6b56a13a2381485daf0f97dd7fc0da289e/extras/filters[https://github.com/OpenSMTPD/OpenSMTPD-extras/tree/751c7b6b56a13a2381485daf0f97dd7fc0da289e/extras/filters] Best regards, Michael Von: Reio Remma[mailto:r...@mrstuudio.ee] Gesendet: Samstag, 7. April 2018 09:35 An: misc@opensmtpd.org[mailto:misc@opensmtpd.org] Betreff: Re: Greylist-like support On 07.04.2018 3:49, Christopher van de Sande wrote: > Been managing my personal email on my own for a good 10 years now > using Postfix, and recently I've come to learn about OpenSMTPD. I've > installed it on a test domain and am quite pleased with it. I'm > thinking about switching over it for my main email. > > One thing I've come to learn that is critical to spam management is > greylisting. Even the act the "slowing down" a spam message by 60 > seconds gives DNSBL's time to get updated, so by the time SpamAssassin > checks the message, it correctly labels it as spam. The combination of > postgrey and spamassassin has been fantastic for me for the last few > years. > > I'm looking for either a greylist solution or anything that can delay > an email for a short time. I know it will work with OpenBSD's spamd, > but I was hoping I could find a linux solution. > > Thanks, > Chris I've been pondering the exact same thing the last few days. I've been looking at rspamd, but I'm not keen on switching, since I just migrated from an old QMail system and am using amavisd-new/spamassassin now. A little disappointed that amavisd-new doesn't have greylisting built in. Good luck, Reio -- You received this mail because you are subscribed to misc@opensmtpd.org[mailto:misc@opensmtpd.org] To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org[mailto:misc+unsubscr...@opensmtpd.org] -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
New OpenSMTPD Snapshots
Hi Gilles, I understand that you are running the OpenSMTPD version with the new config file format, and plan to release snapshots of the same [1]. 1) Would it be possible for you to please share the possible distribution mechanism for the OpenSMTPD snapshots? Would these be available in OpenBSD -current after the 6.3 release? 2) Would you recommend running this new version from the snapshots in production? 3) Would functionality from OpenSMTPD-Extras work with this new version out-of-the-box or would it require changes? Thanks. Regards, ab [1] - https://twitter.com/PoolpOrg/status/973318245812985857 -|-|-|-|-|-|-|-- -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
