of the daemon.
Eric.
Index: ioev.c
===
RCS file: /cvs/src/usr.sbin/smtpd/ioev.c,v
retrieving revision 1.28
diff -u -p -r1.28 ioev.c
--- ioev.c 17 Nov 2016 07:33:06 - 1.28
+++ ioev.c 17 Nov 2016 14:01:28 -
; Index: ioev.c
> ===
> RCS file: /cvs/src/usr.sbin/smtpd/ioev.c,v
> retrieving revision 1.27
> diff -u -p -r1.27 ioev.c
> --- ioev.c16 Nov 2016 21:30:37 - 1.27
> +++ ioev.c16 Nov 2016 21:56:25 -
> @@ -118,7 +118,6 @@ io_s
This diff removes the IO_TLSVERIFIED which is not a io event, and
inlines the necessary code where the callback functions are called
for this event.
Eric.
Index: ioev.c
===
RCS file: /cvs/src/usr.sbin/smtpd/ioev.c,v
retrieving
On Wed, Nov 16, 2016 at 09:13:40PM +0100, Eric Faurot wrote:
> Hi,
>
> I'm working on improving the async io interface in smtpd, make it simpler
> to use and less error-prone.
>
> The short-term goal is to make the io structure opaque.
>
> With this first diff, th
On Wed, 16 Nov 2016 21:13:40 +0100, Eric Faurot wrote:
> With this first diff, the user pointer is passed as parameter to the io
> callback instead of having the user dereference the io structure. There
> are places where the callback function is triggered outside of the io
> layer. It's not
Hi,
I'm working on improving the async io interface in smtpd, make it simpler
to use and less error-prone.
The short-term goal is to make the io structure opaque.
With this first diff, the user pointer is passed as parameter to the io
callback instead of having the user dereference the io
ut admin
> > deciding to do so.
> >
> > Then, we have changed permissions only twice in about 9 years of smtpd.
> > Both times we only required a one-time fix, kind of a flag day, to make
> > the transition and never hear about it again. It doesn't make sense for
> &g
> On Sat, Nov 05, 2016 at 10:03:32AM +0200, li...@wrant.com wrote:
> > Hi tech@,
> >
> > While investigating missing system mail, I found out the messages were in
> >
> > /var/spool/smtpd/offline
> >
> > One of them actually contai
On Sat, Nov 05, 2016 at 10:03:32AM +0200, li...@wrant.com wrote:
> Hi tech@,
>
> While investigating missing system mail, I found out the messages were in
>
> /var/spool/smtpd/offline
>
> One of them actually contains the explanation for why these were missing:
>
Hi tech@,
While investigating missing system mail, I found out the messages were in
/var/spool/smtpd/offline
One of them actually contains the explanation for why these were missing:
==
/etc/mtree/4.4BSD.dist diffs (-OLD +NEW)
==
--- /var/backups/etc_mtree_4.4BSD.dist.current Thu Sep
fix a bug where the specified family was ignored if the listener
> is given as a hostname.
>
>
i like it, ok
please commit soon so people get a chance to spot any error we didn't
gilles
> Index: parse.y
> ======
ing an if_listener.
>
> - fix a bug where the specified family was ignored if the listener
> is given as a hostname.
>
>
> Comments?
I like that. ok jung@
> Eric.
>
> Index: parse.y
> ===
> RCS file:
: parse.y
===
RCS file: /cvs/src/usr.sbin/smtpd/parse.y,v
retrieving revision 1.189
diff -u -p -r1.189 parse.y
--- parse.y 31 Aug 2016 15:24:04 - 1.189
+++ parse.y 9 Sep 2016 11:11:54 -
@@ -138,15 +138,14 @@ static struct
t;
> This makes the shutdown sequence much saner.
>
ok
> Index: ca.c
> ===
> RCS file: /cvs/src/usr.sbin/smtpd/ca.c,v
> retrieving revision 1.24
> diff -u -p -r1.24 ca.c
> --- ca.c 4 Sep 2016 16:10:31 - 1.24
> +++ ca.c 6 Sep 2016 19:33:4
o stop now. When doing so, they log as "debug" instead
of "info" because useless logs are useless.
This makes the shutdown sequence much saner.
Eric.
Index: ca.c
===
RCS file: /cvs/src/usr.sbin/smtpd/ca.c,v
retri
On Sun, Sep 04, 2016 at 05:02:07PM +0200, Eric Faurot wrote:
>
> The smtpd processes are not expected to ever leave their event loop.
> So stop pretending that the *_shutdown() functions could ever be called
> in this context, and just fatal() if event_dispatch() returns.
>
ok
On Sun, Sep 04, 2016 at 05:02:07PM +0200, Eric Faurot wrote:
>
> The smtpd processes are not expected to ever leave their event loop.
> So stop pretending that the *_shutdown() functions could ever be called
> in this context, and just fatal() if event_dispatch() returns.
>
> Eric.
Ok sunil@
On Sun, Sep 04, 2016 at 05:02:07PM +0200, Eric Faurot wrote:
>
> The smtpd processes are not expected to ever leave their event loop.
> So stop pretending that the *_shutdown() functions could ever be called
> in this context, and just fatal() if event_dispatch() returns.
>
The smtpd processes are not expected to ever leave their event loop.
So stop pretending that the *_shutdown() functions could ever be called
in this context, and just fatal() if event_dispatch() returns.
Eric.
Index: ca.c
===
RCS
On Mon, Aug 22, 2016 at 11:10:28PM +0300, Pavel Korovin wrote:
> Dear all,
>
> I have local patch which implements IP/hostname logging for all SMTP
> operations.
> It simplifies log processing for me since I don't have to keep reference
> between session ids and IPs/hostnames and check it every
nks ;-)
>
I like the diff and proper testing is on my todo list for g2k16 as well.
Cheers
Giovanni
>
>> Index: usr.sbin/smtpd/mta.c
>> ===
>> RCS file: /cvs/src/usr.sbin/smtpd/mta.c,v
>> retrieving re
and check it every time I need to check
> who's originating given SMTP transaction.
> Does it make sense for anybody else?
>
Yes, I'll take care of this during the general hackathon next week, thanks ;-)
> Index: usr.sbin/smtpd/mta.c
> =
sense for anybody else?
--
With best regards,
Pavel Korovin
Index: usr.sbin/smtpd/mta.c
===
RCS file: /cvs/src/usr.sbin/smtpd/mta.c,v
retrieving revision 1.201
diff -u -p -r1.201 mta.c
--- usr.sbin/smtpd/mta.c22 May 2016 16:31
On 08/20/16 10:03, Anthony La Porte wrote:
On Sat, 20 Aug 2016, Eric Faurot wrote:
Can you guys try this diff?
With this hostname and message-id are back.
Thanks!
+1 - cheers.
- C
On Sat, 20 Aug 2016, Eric Faurot wrote:
> Can you guys try this diff?
>
> Eric.
With this hostname and message-id are back.
Thanks!
>
> Index: rfc2822.c
> ===
> RCS file: /cvs/src/usr.sbin/smtpd/rfc2822.c,v
le: /cvs/src/usr.sbin/smtpd/rfc2822.c,v
> retrieving revision 1.7
> diff -u -p -r1.7 rfc2822.c
> --- rfc2822.c 4 Feb 2016 22:35:17 - 1.7
> +++ rfc2822.c 20 Aug 2016 10:53:27 -
> @@ -138,6 +138,7 @@ rfc2822_parser_init(struct rfc2822_pa
Can you guys try this diff?
Eric.
Index: rfc2822.c
===
RCS file: /cvs/src/usr.sbin/smtpd/rfc2822.c,v
retrieving revision 1.7
diff -u -p -r1.7 rfc2822.c
--- rfc2822.c 4 Feb 2016 22:35:17 - 1.7
+++ rfc2822.c 20 Aug 2016
As -r1.285 does for authentication events, log address and host for
failed-command events too.
Regards,
--
Ant
Index: usr.sbin/smtpd/smtp_session.c
===
RCS file: /cvs/src/usr.sbin/smtpd/smtp_session.c,v
retrieving revision 1.285
On Tue, 9 Aug 2016, Chris Turner wrote:
> However, in OpenSMTPD 6.0, mails are delivered as:
>
> From: Charlie Root <r...@workstation-hostname.company.net>
> To: root < >
>
I've noticed that for mail sent by any user on the local machine to another
local user. In add
Hello -
Just installed a 6.0 snapshot (from yesterday, though then rebuilt),
and noticed what seemed to be a possible regression (or otherwise PEBCAK)
in smtpd for my specific dumb-host configuration -
Basically, configuration is as follows:
- configuration:
- Host is test VM behind
On Sun, Jun 05, 2016 at 12:43:14PM +0200, Gilles Chehade wrote:
> On Thu, Jun 02, 2016 at 05:18:21PM +0300, Pavel Korovin wrote:
> > Dear all,
> >
> > Could you consider quoting the space-containing values in smtpd log
> > messages?
> >
> > I like t
On Thu, Jun 02, 2016 at 05:18:21PM +0300, Pavel Korovin wrote:
> Dear all,
>
> Could you consider quoting the space-containing values in smtpd log
> messages?
>
> I like the latest smtpd log format improvements, but it's hard to parse
> space-separated key-value pai
Dear all,
Could you consider quoting the space-containing values in smtpd log
messages?
I like the latest smtpd log format improvements, but it's hard to parse
space-separated key-value pairs if they have space-containing values :)
Please see the patch attached.
--
With best regards,
Pavel
Hi all,
Given that (after changes to tables and makemap[0]) /usr/libexec/smtpd
directory is now empty, the below patch might be appropriate - this is,
of course, assuming the directory won't be reused in the near future.
Regards,
Raf
[0] http://www.openbsd.org/faq/current.html
Index: faq
On Wed, Oct 21, 2015 at 10:41:16PM +0200, Gregor Best wrote:
> Nice to see rubber duck debugging working. The attached patch seems to
> be enough
>
Thanks.
There is work in progress to shring the pledge list but I have
committed this meanwhile to fix the immediate issue.
--
Gilles Chehade
Nice to see rubber duck debugging working. The attached patch seems to
be enough
--
Gregor
--
Index: smtpd.c
===
RCS file: /home/cvs/src/usr.sbin/smtpd/smtpd.c,v
retrieving revision 1.250
diff -u -p -u -r1.250 smtpd.c
"/home/gbe/Maildir",
mode=448)
at /usr/src/usr.sbin/smtpd/smtpd/../util.c:223
#2 0x1d7c727471d0 in delivery_maildir_open
(deliver=0x7f7dd0d0) at
/usr/src/usr.sbin/smtpd/smtpd/../delivery_maildir.c:99
#3 0x1d7c7273dd1e in parent_imsg (p=0x1d7e87f6a000,
imsg=Vari
smtpd needs to pledge unix to support delivery_backend_lmtp to a socket.
Config example:
accept for domain "mydomain.com" alias deliver to lmtp
"/var/dovecot/lmtp"
Tim.
Index: smtpd.c
===
RCS file: /cv
On Sat, October 17, 2015 12:59 pm, trondd wrote:
>
> smtpd needs to pledge unix to support delivery_backend_lmtp to a socket.
>
And now that I am getting email, I see this was fixed just minutes after I
had updated my cvs checkout. :)
Carry on.
Tim.
On Fri, Oct 02, 2015 at 05:17:39AM +0200, Gilles Chehade wrote:
> During the last few months, researchers from Qualys Security have done
> an audit of smtpd and have identified multiple reliability and security
> issues.
>
> The issues affect 5.6, 5.7 and forthcoming 5.8 releas
During the last few months, researchers from Qualys Security have done
an audit of smtpd and have identified multiple reliability and security
issues.
The issues affect 5.6, 5.7 and forthcoming 5.8 release.
Patches are available. Apply the patch, rebuild smtpd and restart the
daemon.
5.6:
http
Hi,
On Sat, Aug 15, 2015 at 05:54:55AM -0400, Geoff Steckel wrote:
The included patch allows smtpd/filter_api.c to compile. I know it's
This is not ok, this file is not meant to be linked in the daemon.
It is meant to be linked against filters which will communicate with the
daemon through
Patches are now available for 5.6 and 5.7 which fix an smtpd errata.
5.6 errata 25 and 5.7 errata 8:
Fix multiple reliability issues in smtpd:
a local user can cause smtpd to fail by writing an invalid imsg to control
socket.
a local user can prevent smtpd from serving new requests by exhausting
On Sat, May 02, 2015 at 12:27:46PM +0800, Nathanael Rensen wrote:
The smtpd enqueue -S option does not take an argument.
committed, thanks
--
Gilles Chehade
https://www.poolp.org @poolpOrg
The smtpd enqueue -S option does not take an argument.
An email enqueued offline with only the -t option (e.g. vi recovery)
results in the options -S -t passed to smtpd enqueue. The -t is
ignored resulting in:
debug: smtpd: scanning offline queue...
debug: smtpd: enqueueing offline message
/var
On Thu, Feb 05, 2015 at 09:30:12PM -0600, Abel Abraham Camarillo Ojeda wrote:
On Tue, Dec 9, 2014 at 1:40 AM, Gilles Chehade gil...@poolp.org wrote:
Now, if you auth using another mechanism (ie: listen [...] auth table)
in theory we do not have the same limitation but I think it will fail as
On Tue, Dec 9, 2014 at 1:40 AM, Gilles Chehade gil...@poolp.org wrote:
Now, if you auth using another mechanism (ie: listen [...] auth table)
in theory we do not have the same limitation but I think it will fail as
we share some code path and we probably have a check in there. I'll have
a look
On Tue, Jan 06, 2015 at 07:24:45PM +0100, Jonas 'Sortie' Termansen wrote:
On 01/06/2015 12:11 PM, Gilles Chehade wrote:
Index: smtp_session.c
===
RCS file: /cvs/src/usr.sbin/smtpd/smtp_session.c,v
retrieving revision 1.221
: /cvs/src/usr.sbin/smtpd/smtp_session.c,v
retrieving revision 1.221
diff -u -p -r1.221 smtp_session.c
--- smtp_session.c17 Dec 2014 15:49:23 - 1.221
+++ smtp_session.c5 Jan 2015 22:36:55 -
@@ -315,7 +315,9 @@ header_append_domain_buffer(char *buffer
: smtp_session.c
===
RCS file: /cvs/src/usr.sbin/smtpd/smtp_session.c,v
retrieving revision 1.221
diff -u -p -r1.221 smtp_session.c
--- smtp_session.c 17 Dec 2014 15:49:23 - 1.221
+++ smtp_session.c 5 Jan 2015 22:36:55
On 01/06/2015 12:11 PM, Gilles Chehade wrote:
Index: smtp_session.c
===
RCS file: /cvs/src/usr.sbin/smtpd/smtp_session.c,v
retrieving revision 1.221
diff -u -p -r1.221 smtp_session.c
--- smtp_session.c17 Dec 2014 15:49:23
I was reading through the smtpd code and found some whitespace
inconsistencies. Diff below to fix.
Index: usr.sbin/smtpd/dns.c
===
RCS file: /cvs/src/usr.sbin/smtpd/dns.c,v
retrieving revision 1.79
diff -u -p -r1.79 dns.c
This program uses fparseln's default delimiters, which can be replaced by
NULL.
WARNING: I only compiled with this patch applied, I didn't actually run the
resulting binary.
Index: makemap.c
===
RCS file: /cvs/src/usr.sbin/smtpd
On Sun, Dec 07, 2014 at 07:43:11PM -0600, Abel Abraham Camarillo Ojeda wrote:
ping
[...]
I'm ok with the syntax error message, but should large usernames work?
Thank you very much.
When authenticating using the default backend, it shouldn't work no, the
username is limited by how
with length larger than 31 chars allowed?
(this usernames do work on our current mail systems)
if they are not allowed, shouldn't smtpd complain when loading such table?
As for the Syntax Error on large usernames, I'll think of a better way
to phrase it, this is the default Enhanced Status Code
-in: Failed command on session fd98324226959da6: AUTH [...] =
501 5.5.2 Syntax error: Syntax error
expected:
# smtpd -dv
debug: init ssl-tree
info: loading pki information for test.verlet.org
info: OpenSMTPD 5.4.3 starting
debug: bounce warning after 4h
debug: using fs queue backend
)
if they are not allowed, shouldn't smtpd complain when loading such table?
As for the Syntax Error on large usernames, I'll think of a better way
to phrase it, this is the default Enhanced Status Code message for this
kind of errors, we should probably override with a more descriptive error.
I'm ok with the syntax
AGNvcnJlby12b3otMDEwQGFiY2RlZi5naGlqa2xtbm9wAGV4YW1wbGU=
-- 501 5.5.2 Syntax error: Syntax error
Are usernames on auth tables with length larger than 31 chars allowed?
(this usernames do work on our current mail systems)
if they are not allowed, shouldn't smtpd complain when loading such table?
As for the Syntax Error
- auth longemailabcde@abcdef.ghijklmnop:
smtp-in: Failed command on session fd98324226959da6: AUTH [...] =
501 5.5.2 Syntax error: Syntax error
expected:
# smtpd -dv
debug: init ssl-tree
info: loading pki information for test.verlet.org
info: OpenSMTPD 5.4.3 starting
debug: bounce warning after 4h
@abcdef.ghijklmno:
smtp-in: Authentication failed for user
longemailabcde@abcdef.ghijklmno on session 9b03fc72ca051521
got - auth longemailabcde@abcdef.ghijklmnop:
smtp-in: Failed command on session fd98324226959da6: AUTH [...] =
501 5.5.2 Syntax error: Syntax error
expected:
# smtpd -dv
/usr.sbin/smtpd/table_api.c,v
retrieving revision 1.4
diff -u -p -u -r1.4 table_api.c
--- table_api.c 4 Feb 2014 13:55:34 - 1.4
+++ table_api.c 9 Jul 2014 08:36:17 -
@@ -108,6 +108,7 @@ table_msg_dispatch(void)
char res[4096];
int
thanks, will be fixed shortly
as a side note this is not built and will be removed from smtpd
to be shipped as an external backend
On Fri, Jul 11, 2014 at 05:39:02AM +, Doug Hogan wrote:
socket() returns -1 on error.
Index: usr.sbin/smtpd/table_socketmap.c
socket() returns -1 on error.
Index: usr.sbin/smtpd/table_socketmap.c
===
RCS file: /cvs/src/usr.sbin/smtpd/table_socketmap.c,v
retrieving revision 1.4
diff -u -p -d -r1.4 table_socketmap.c
--- usr.sbin/smtpd/table_socketmap.c8
by table_sqlite_lookup.
The patch below initializes this memory and fixes the bug for me.
Index: table_api.c
===
RCS file: /cvs/src/usr.sbin/smtpd/table_api.c,v
retrieving revision 1.4
diff -u -p -u -r1.4 table_api.c
--- table_api.c 4
checked the code but the following passes a check
with smtpd -n
listen on iwn0 tls auth
listen on em0 tls auth-optional
so it seems to be a valid syntax.
it's why i added the word optional to the description. the syntax
[table] is really ugly, and is hard to understand.
we could do
smtpd.conf(5) gives the impression that authtable is
mandatory. I haven't checked the code but the following passes a check
with smtpd -n
listen on iwn0 tls auth
listen on em0 tls auth-optional
so it seems to be a valid syntax.
it's why i added the word optional to the description
in this
table.
but reading the new smtpd.conf(5) gives the impression that authtable is
mandatory. I haven't checked the code but the following passes a check
with smtpd -n
listen on iwn0 tls auth
listen on em0 tls auth-optional
so it seems to be a valid syntax.
it's why i added the word
fixes to smtpd since 5.5
release. If you're using smtpd on 5.5, you probably want to apply them.
(My plan is to commit to stable eventually, but since it's very
important not to introduce regressions, I'm asking for a little help
testing the backport.)
++
fix writing of multiline To and Cc
There have been some rather important fixes to smtpd since 5.5
release. If you're using smtpd on 5.5, you probably want to apply them.
(My plan is to commit to stable eventually, but since it's very
important not to introduce regressions, I'm asking for a little help
testing the backport
as a
parameter. When provided, credentials are looked up in this
table.
but reading the new smtpd.conf(5) gives the impression that authtable is
mandatory. I haven't checked the code but the following passes a check
with smtpd -n
listen on iwn0 tls auth
listen on em0 tls auth
haven't checked the code but the following passes a check
with smtpd -n
listen on iwn0 tls auth
listen on em0 tls auth-optional
so it seems to be a valid syntax.
Index: usr.sbin/smtpd/smtpd.conf.5
===
RCS file: /cvs/src/usr.sbin
Hi,
here's a new version for the manpage bug Creamy mentioned.
Frank.
Index: usr.sbin/smtpd/smtpd.conf.5
===
RCS file: /cvs/src/usr.sbin/smtpd/smtpd.conf.5,v
retrieving revision 1.117
diff -u -r1.117 smtpd.conf.5
--- usr.sbin/smtpd
===
RCS file: /cvs/src/usr.sbin/smtpd/smtpd.conf.5,v
retrieving revision 1.117
diff -u -r1.117 smtpd.conf.5
--- smtpd.conf.516 Feb 2014 21:59:34 - 1.117
+++ smtpd.conf.514 May 2014 22:13:44 -
@@ -109,7 +109,7 @@
.Ic from
.Op Ic
are
intended to be literally included, or whether they are just
markup in the man page to indicate, 'name of table'.
And it's going to fix itself? Don't think so...
Index: smtpd.conf.5
===
RCS file: /cvs/src/usr.sbin/smtpd
Shouldn't that be:
+.Op Ic auth | auth-optional | auth Aq Ar authtable Aq | Ic auth-optional Ar
authtable
??? Looks like it fixed itself incorrectly :-)))
:-P
But you're right, the fix was wrong, missed that one. But it doesn't
work your way either. If I understand mdoc(7) correctly
Hi,
So, now that smtpd is due to replace sendmail as the default mailer,
it would be nice if it actually worked correctly...
First of all, the man page for smtpd.conf states that directives
'from source' and 'senders' take the name of a table as an argument,
which is not true.
For example
Le 10/05/2014 17:54, Creamy a écrit :
table creamy db:/etc/mail/creamy.db
table secrets db:/etc/mail/secrets.db
accept sender creamy for domain example.com relay via
smtps+auth://foo...@smtp.creamylan.lan auth secrets
Shouldn't it be :
accept sender creamy for domain example.com ...
On Sat, May 10, 2014 at 06:48:18PM +0200, Denis Fondras wrote:
Le 10/05/2014 17:54, Creamy a ?crit :
table creamy db:/etc/mail/creamy.db
table secrets db:/etc/mail/secrets.db
accept sender creamy for domain example.com relay via
smtps+auth://foo...@smtp.creamylan.lan auth secrets
markup in the man page to indicate, 'name of table'.
And it's going to fix itself? Don't think so...
Index: smtpd.conf.5
===
RCS file: /cvs/src/usr.sbin/smtpd/smtpd.conf.5,v
retrieving revision 1.117
diff -u -r1.117 smtpd.conf.5
/usr.sbin/smtpd/expand.c,v
retrieving revision 1.26
diff -u -p -r1.26 expand.c
--- expand.c19 Apr 2014 12:43:19 - 1.26
+++ expand.c8 May 2014 16:28:15 -
@@ -193,12 +193,14 @@ static int
expand_line_split(char **line, char **ret)
{
static char buffer[SMTPD_MAXLINESIZE
On Thu, May 08, 2014 at 12:35:56PM -0400, Ted Unangst wrote:
This is wrong in several ways.
Never cast sizeof down, always cast the comparison variable up.
I'll specifically call out this change:
- if (snprintf(buf, sizeof(buf)) = (int)sizeof(buf))
+ if ((size_t)snprintf(buf,
On 08 May 2014, at 18:43, Alexandre Ratchov a...@caoua.org wrote:
On Thu, May 08, 2014 at 12:35:56PM -0400, Ted Unangst wrote:
This is wrong in several ways.
Never cast sizeof down, always cast the comparison variable up.
I'll specifically call out this change:
-if (snprintf(buf,
On Thu, May 08, 2014 at 18:43, Alexandre Ratchov wrote:
On Thu, May 08, 2014 at 12:35:56PM -0400, Ted Unangst wrote:
This is wrong in several ways.
Never cast sizeof down, always cast the comparison variable up.
I'll specifically call out this change:
-if (snprintf(buf, sizeof(buf))
Hi,
- - - src/usr.sbin/smtpd/smtpd.c l.1326
if (! bsnprintf(key, sizeof key,
profiling.imsg.%s.%s.%s,
proc_name(smtpd_process),
proc_name(p-proc),
imsg_to_str(imsg-hdr.type)));-- ';'
stat_set(key, stat_timespec
On Thu, Jul 04, 2013 at 08:48:16AM +0200, Maxime Villard wrote:
Hi,
- - - src/usr.sbin/smtpd/smtpd.c l.1326
if (! bsnprintf(key, sizeof key,
profiling.imsg.%s.%s.%s,
proc_name(smtpd_process),
proc_name(p-proc),
imsg_to_str
the require auth, as opposed to enable auth
Thoughts? OK?
/Alexander
Index: parse.y
===
RCS file: /data/openbsd/cvs/src/usr.sbin/smtpd/parse.y,v
retrieving revision 1.104
diff -u -p -r1.104 parse.y
--- parse.y 30 Sep 2012 17:25:09
listen on bge0 smtps certificate mycert require auth
Note the require auth, as opposed to enable auth
Thoughts? OK?
/Alexander
Index: parse.y
===
RCS file: /data/openbsd/cvs/src/usr.sbin/smtpd/parse.y,v
retrieving
On 10/09/12 15:33, Gilles Chehade wrote:
Argh, you should have talked to me first ...
Both require ssl and require auth are implemented already ... I did
not commit yet because we stabilized a release and decided to not
add new features to it unless they are critical.
This feature should be
On 10/09/12 15:38, Gilles Chehade wrote:
ok, discussed with eric, not critical but still very annoying so we'll
commit the feature tonight.
Ah, so something good came out of my diff anyway! :-)
I was actually unsure whether this would get an OK or be postponed, so
that could indeed have
On Tue, Oct 09, 2012 at 03:43:03PM +0200, Alexander Hall wrote:
On 10/09/12 15:33, Gilles Chehade wrote:
Argh, you should have talked to me first ...
Both require ssl and require auth are implemented already ... I did
not commit yet because we stabilized a release and decided to not
add new
Gilles, I'm actually wondering - should there even be a difference?
Every practical implementation of 587 I've ever seen requires auth. Is there
any sane reason to have enable auth not actually require it? I.E. what
I'm asking is is enable (without require) simply a silly knob that
we're putting
On Tue, Oct 09, 2012 at 03:48:44PM +0200, Gilles Chehade wrote:
On Tue, Oct 09, 2012 at 03:43:03PM +0200, Alexander Hall wrote:
On 10/09/12 15:33, Gilles Chehade wrote:
Argh, you should have talked to me first ...
Both require ssl and require auth are implemented already ... I did
not
On Tue, Oct 09, 2012 at 09:05:42AM -0600, Bob Beck wrote:
Gilles, I'm actually wondering - should there even be a difference?
Every practical implementation of 587 I've ever seen requires auth. Is there
any sane reason to have enable auth not actually require it? I.E. what
I'm asking is is
On Tue, Oct 9, 2012 at 9:25 AM, Gilles Chehade gil...@poolp.org wrote:
I agree with you that people will probably not want port 587 without auth
turned on so on a practical point of view, we could make it implicit.
There's a syntax issue though because, users will likely be less surprised
On Tue, Oct 09, 2012 at 09:29:25AM -0600, Bob Beck wrote:
On Tue, Oct 9, 2012 at 9:25 AM, Gilles Chehade gil...@poolp.org wrote:
I agree with you that people will probably not want port 587 without auth
turned on so on a practical point of view, we could make it implicit.
There's a
On 10/09/12 17:38, Gilles Chehade wrote:
On Tue, Oct 09, 2012 at 09:29:25AM -0600, Bob Beck wrote:
On Tue, Oct 9, 2012 at 9:25 AM, Gilles Chehade gil...@poolp.org wrote:
I agree with you that people will probably not want port 587 without auth
turned on so on a practical point of view, we
On 2012/10/09 18:49, Alexander Hall wrote:
On 10/09/12 17:38, Gilles Chehade wrote:
On Tue, Oct 09, 2012 at 09:29:25AM -0600, Bob Beck wrote:
On Tue, Oct 9, 2012 at 9:25 AM, Gilles Chehade gil...@poolp.org wrote:
I agree with you that people will probably not want port 587 without auth
On Tue, Oct 09, 2012 at 06:49:15PM +0200, Alexander Hall wrote:
I think Bob's point is that then you use 587 (with auth) for
yourselves and 25 (without auth) for mail from the rest of the
intertubes.
Yes I understand this :-)
What I want to highlight is the implication of this change so
I think Bob's point is that then you use 587 (with auth) for yourselves and
25 (without auth) for mail from the rest of the intertubes.
Yes, that's my point :)
On 10/09/12 17:07, Gilles Chehade wrote:
On Tue, Oct 09, 2012 at 03:48:44PM +0200, Gilles Chehade wrote:
On Tue, Oct 09, 2012 at 03:43:03PM +0200, Alexander Hall wrote:
On 10/09/12 15:33, Gilles Chehade wrote:
Argh, you should have talked to me first ...
Both require ssl and require auth are
401 - 500 of 546 matches
Mail list logo
