[syslog-ng] [PATCH]: Experimental SMTP destination

[Balazs Scheidler]

Hi,

On Fri, 2011-03-04 at 15:16 +0100, Gergely Nagy wrote:
> (Quick note: I rebased my work/modules/afsmtp branch on top of the
> current master)

I'll review it, thanks.

> 
> Balazs Scheidler <bazsi at balabit.hu> writes:
> >> The usage is something like this:
> >> 
> >>         destination d_smtp {
> >>           smtp(
> >>             host("localhost")
> >>             port(25)
> >>             mail_from("syslog-ng alert service <noreply at example.com>")
> >>             rcpt_to("Admin #1 <admin at example.com>")
> >>             rcpt_to("Admin #2 <admin2 at example.com>")
> >>             subject("[ALERT] $LEVEL condition in $PROGRAM!")
> >>             header("X-Program" "$PROGRAM")
> >>             header("X-Facility" "$FACILITY")
> >>             body("Hi!\nThe syslog-ng alerting service thinks you might be interested in the following message:\n $MSG\n-- \nsyslog-ng\n")
> >>           );
> >>         };
> >
> > I'd love to get away a little bit from SMTP logic, and use option names
> > that reflect more closely what the user sees in a MUA.
> 
> Most of this has already been done on my branch, I just didn't send an
> update, I believe.
> 
> > We might give a chance to specify all the rest of the details, but they
> > should be the exception and not the rule.
> >
> > smtp(
> >             host("localhost")
> >             port(25)
> >             from("syslog-ng alert service <noreply at example.com>")
> >             to("Admin #1 <admin at example.com>", "Admin #2 <admin2 at example.com>")
> >             cc("Admin BOSS <admin.boss at example.com>")
> >             bcc("Blind CC <blindcc at example.com>")
> >             subject("[ALERT] $LEVEL condition in $PROGRAM!")
> >             body("Hi!\nThe syslog-ng alerting service thinks you might be interested in the following message:\n $MSG\n-- \nsyslog-ng\n")
> > 	    extra-header("X-Program", "$PROGRAM")
> >           );
> 
> from(), to(), cc(), bcc(), reply_to() have the following syntax in my
> current tree:
> 
>   ,----
>   | from("admin at example.com")
>   |     OR
>   | from("Admin #1" "admin at example.com")
>   `----
> 
> Same goes for the other mentioned headers. The reason behind this, is
> that libesmtp expects things this way: the address and the name in two
> separate parameters. If specified with the first form, the e-mail
> address will be used as the name too.
> 
> I could work around that, and do some parsing myself, but it's easier
> this way.
> 
> I can extend the syntax to something like the following:
> 
>   ,----
>   | to("admin at example.com" ("Admin #2" "admin2 at example.com"))
>   `----
> 
> Although, I'd rather have multiple to(), cc() and bcc() lines than this.

I think it is ok that way.

> 
> > I doubt it'd be useful to use templates within To/Cc/Bcc, but the rest should be templates, 
> > with support for embedded newline characters. (headers can also contain embedded 
> > newlines, by embedding NL and adding whitespace in the front of the upcoming line, 
> > although I'm not sure how much MUAs like it).
> 
> As of this writing, subject(), body() and header() (soon to be renamed
> to extra_header()) support templates, the rest don't.
> 
> I haven't verified that embedded newlines work properly yet. I have a
> suspicion that they don't, and in that case I think I have a reasonably
> easy workaround (more on that below). I'll post an update once I know
> for sure.
> 
> > The same syntax could perhaps be used by a possible "sendmail()" destination, which 
> > could spawn the local sendmail binary, instead of directly using SMTP.
> 
> I think I replied to this before - I'd rather extend program() to have
> an option that would make it always spawn a new instance of the
> program. Something like flags(always-spawn) or similar.

That's ok, then sendmail() or better yet email() destination could
become an SCL block, that uses a template() to format an email. The
important stuff is to take care about proper escaping, so that users
wouldn't have to care about that.

> 
> >> These are: Date, From, To, Cc, Bcc, Reply-To - trying to set either of
> >> these will result in unspecified behaviour (ranging from mangled headers
> >> to crashes, in case of Date). I will fix these at a later point. They
> >> will probably be need to set via their own statements (header_date,
> >> header_from, etc, or something along those lines).
> 
> This has partially been solved since: one can't set the mentioned
> headers with the headers() statement, and has to use from(), to(), etc.
> 
> I do not have a solution for the date header yet (it can't be set in any
> way at the moment).

Is there a point in setting that? I mean I would never want to specify
the date header, or do you have a specific usecase?

> 
> Another problem is, that libesmtp parses the whole body, and tries to
> extract headers even if they appear after the body. Thus, having a body
> like the following will crash the module:
> 
>   ,----
>   | body("Yadayada\nDate: CRASH, BOOM, BANG!")
>   `----
>   
> The workaround for this will be to replace "\n"s in the body with "\n ",
> to stop libesmtp from messing with the headers.

hmm... that doesn't sound too good? are you sure libesmtp is the correct
library to use, then?

two NLs terminate the message, that's such an ancient rule, that should
really be working with an SMTP library, shouldn't it?

> 
> Something similar will be done for the headers too, to prevent embedded
> newlines from injecting extra headers.
> 
> >> Further plans include authentication & starttls support. libesmtp
> >> supports both, I just didn't have time to write the neccessary glue code
> >> yet.
> >
> > Great. Just let me know when I can pull it :)
> 
> I have both auth & starttls support locally, but... the solution is
> rather dumb, especially the tls one. They "Work For Me", but aren't
> merge ready yet, I believe.
> 
> If it's possible, I'd like to request a two-stage merge: first the basic
> driver, without auth & tls, because that'll be ready within a reasonable
> time-frame, and the rest can be merged later, whenever I or anyone else
> gets around to do it properly.
> 

That's ok for me. I'll try to review the SMTP bits until then.

-- 
Bazsi