@ lbutlr:
> On 12/4/16 8:17 AM, Wietse Venema wrote:
> > @ lbutlr:
> >> On 12/3/16 2:57 PM, Wietse Venema wrote:
> >>> Proof of concept:
> >>>
> >>> MAIL FROM<" >>> type='text/javascript'>alert('xss');"@example.com>
> >>
> >> That result in "501 5.5.4 Syntax: MAIL FROM:"
> >
> > OK, so insert a
On 12/4/16 8:17 AM, Wietse Venema wrote:
@ lbutlr:
On 12/3/16 2:57 PM, Wietse Venema wrote:
Proof of concept:
MAIL FROM<"alert('xss');"@example.com>
That result in "501 5.5.4 Syntax: MAIL FROM:"
OK, so insert a the missing ':'
MAIL FROM:"alert('xss');"@example.com>
250 2.1.0 Ok
Fair
@ lbutlr:
> On 12/3/16 2:57 PM, Wietse Venema wrote:
> > Proof of concept:
> >
> > MAIL FROM<" > type='text/javascript'>alert('xss');"@example.com>
>
> That result in "501 5.5.4 Syntax: MAIL FROM:"
OK, so insert a the missing ':'
MAIL FROM:"alert('xss');"@example.com>
250 2.1.0 Ok
Instead of
On 2016-12-02 15:10, Michael Munger wrote:
This is a great idea. This is a spam filter that is integrated into a
CRM system, so I needed to parse and dump the information so it could
be
sucked up later.
Here's what I ultimately created. It still needs some work (mainly
because it re-reads the
> On Dec 4, 2016, at 12:58 AM, @lbutlr wrote:
>
>> MAIL FROM<"> type='text/javascript'>alert('xss');"@example.com>
>
> That result in "501 5.5.4 Syntax: MAIL FROM:"
There's a missing ":" after FROM. In any case, even if a particular
exploit mechanism fails, or even all
On 12/3/16 2:57 PM, Wietse Venema wrote:
Proof of concept:
MAIL FROM<"alert('xss');"@example.com>
That result in "501 5.5.4 Syntax: MAIL FROM:"
Wietse Venema:
> @ lbutlr:
> > > Careful with that. To easy to create a script injection vector. Bash is
> > > not
> > > a good language in which to construct safely quoted remote content for
> > > injection
> > > into a suitable HTML skeleton.
> >
> > Injection from where? the script is only
@ lbutlr:
> > Careful with that. To easy to create a script injection vector. Bash is
> > not
> > a good language in which to construct safely quoted remote content for
> > injection
> > into a suitable HTML skeleton.
>
> Injection from where? the script is only accessible to the root user on
On 12/3/16 9:53 AM, Bastian Blank wrote:
On Sat, Dec 03, 2016 at 09:44:03AM -0700, @lbutlr wrote:
Injection from where? the script is only accessible to the root user
on the mail server and only checks /var/log/maillog (or the log
specified at the top of the script). There's no remote content
On Sat, Dec 03, 2016 at 09:44:03AM -0700, @lbutlr wrote:
> Injection from where? the script is only accessible to the root user
> on the mail server and only checks /var/log/maillog (or the log
> specified at the top of the script). There's no remote content
> involved.
The contents of the log
On 12/3/16 1:48 AM, Viktor Dukhovni wrote:
On Dec 2, 2016, at 1:30 AM, @lbutlr wrote:
I have a bash script that does it, and when a user wants this, I simply set up
a crontab for them. Usually after a week or so they want it turned off. The
script sends them a lightly
Viktor Dukhovni:
>
> > On Dec 2, 2016, at 1:30 AM, @lbutlr wrote:
> >
> > I have a bash script that does it, and when a user wants this, I simply set
> > up a crontab for them. Usually after a week or so they want it turned off.
> > The script sends them a lightly styled
> On Dec 2, 2016, at 1:30 AM, @lbutlr wrote:
>
> I have a bash script that does it, and when a user wants this, I simply set
> up a crontab for them. Usually after a week or so they want it turned off.
> The script sends them a lightly styled HTML table in the email.
>
>
This is a great idea. This is a spam filter that is integrated into a
CRM system, so I needed to parse and dump the information so it could be
sucked up later.
Here's what I ultimately created. It still needs some work (mainly
because it re-reads the whole file every time, and I should use
On 11/30/16 2:35 PM, Michael Munger wrote:
I am writing a log parser so that when users complain "so and so sent me
an email and I didn't get it" I can query the logs and find this with
ease. Ultimately, I want ot make this self service through a web page.
I went a different way. Users can
On 12/01/2016 09:37 AM, Wietse Venema wrote:
And I have made a note to log the sender when rejecting the (MAIL
FROM) SIZE parameter.
Wow. Wasn't expecting that! Thank you, sir.
Michael Munger:
> Bill:
>
> Thank you for both items. I shall pour over them.
And I have made a note to log the sender when rejecting the (MAIL
FROM) SIZE parameter.
Wietse
Bill:
Thank you for both items. I shall pour over them.
On 11/30/2016 11:49 PM, Bill Cole wrote:
On 30 Nov 2016, at 20:20, Michael Munger wrote:
First, there can be no TO address before the client sends MAIL FROM.
Second, the size check is done before checking the sender address,
presumably
On 30 Nov 2016, at 20:20, Michael Munger wrote:
First, there can be no TO address before the client sends MAIL FROM.
Second, the size check is done before checking the sender address,
presumably because it is more efficient that way. But I guess some
code could be swapped around.
My mistake.
> First, there can be no TO address before the client sends MAIL FROM.
> Second, the size check is done before checking the sender address,
> presumably because it is more efficient that way. But I guess some
> code could be swapped around.
My mistake. I thought:
552 5.3.4 Message size exceeds
Michael Munger:
> I am writing a log parser so that when users complain "so and so sent me
> an email and I didn't get it" I can query the logs and find this with
> ease. Ultimately, I want ot make this self service through a web page.
>
> In a transaction like this:
>
> 119970-Nov 29 13:56:12
21 matches
Mail list logo