This issue really highlights a tension I've been feeling in swaks for a
while. The tool was written to test mail servers. From that perspective,
I often feel that I've put _too_ much input validation in it. Wanting to
see how a mail server reacts when it is passed 8bit chars in headers
without S
This wishlist item is now implemented in the formal swaks release, not
yet packaged in debian but in the short term available from
http://www.jetmore.org/john/blog/2013/02/swaks-release-20130209-0-available/.
Thanks for the feature and implementation suggestions!
--John
--
To UNSUBSCRIBE, emai
Package: id3v2
Version: 0.1.12-2
Severity: normal
Tags: patch
Trying to add a comment to an mp3 that contains a ':' results in undesired
behavior, truncating fields and producing odd results (treating embedded ':' as
option field delimiters).
Examples:
--
jetmore@g3:~$ /usr/bin/id3v2 -c 'From:
On Wed, May 30, 2012 at 1:57 PM, Andreas Metzler
wrote:
> As swaks is a debugging tool I think it would be nice if there was some
> enhanced knob to force a specific TLS version (as s_client) does.
> Other than that I have not got any suggestions. Neither s_client
> nor gnutls-cli can handle this
Package: libnet-ssleay-perl
Version: 1.48-1
Severity: normal
While troubleshooting problems using the Net::SSLeay::OP_NO_TLSv1_1 constant
in a perl app, I came to realize that Net::SSLeay, as packaged in
libnet-ssleay-perl 1.48-1, does not return the proper constant value for
OP_NO_TLSv1_1.
I don
On Tue, May 29, 2012 at 6:55 PM, John Jetmore wrote:
> On Tue, May 29, 2012 at 2:38 PM, Andreas Metzler
> wrote:
>
>> I think you need a rather new OpenSSL to show the bug. - With openssl
>> s_client (and GnuTLS) there are problems with this server if the
>> client tr
On Tue, May 29, 2012 at 2:38 PM, Andreas Metzler
wrote:
> On 2012-05-29 John Jetmore wrote:
>> FWIW I haven't been able to reproduce this anywhere yet (on a stock
>> squeeze server, with newer and older versions of swaks, and with an
>> older mac os x server). I ins
FWIW I haven't been able to reproduce this anywhere yet (on a stock
squeeze server, with newer and older versions of swaks, and with an
older mac os x server). I installed a copy of perl 5.14 and
Net::SSLeay 1.48 and couldn't reproduce it there either. I haven't
tried compiling a newer version of
Micha, if you are still interested in using swaks in an IPv6
environment, please see my initial draft of ipv6 support:
http://www.jetmore.org/john/blog/2012/02/swaks-ipv6-support-initial-draft/
I welcome and feedback you might have.
Thanks
--John
On Mon, May 25, 2009 at 8:03 AM, Micha Lenk wro
On Tue, Dec 20, 2011 at 5:08 PM, Gunnar Wolf wrote:
> tags 650024 + upstream
> thanks
>
>> Hi Gunnar,
>
> Hi Axel,
>
> I'm bringing John Jetmore, the Swaks author, for his input. John, you
> can see all of my interchange with Axel at:
>
> http://bugs.de
On Fri, Oct 21, 2011 at 9:46 AM, John Jetmore wrote:
> On Fri, Oct 21, 2011 at 3:31 AM, Peter Samuelson wrote:
>>
>> Package: swaks
>> Version: 20100211.0-4
>> Tags: patch
>>
>> The timezone field of RFC 822 date format is [+-]HHMM, whereas swaks
>> c
FWIW this is addressed in svn with a new --protect-prompt option
(which will do as much as possible to protect sensitive information
that is entered at the command line, though at the moment that's only
password entry). I won't be turning this on by default since it
doesn't fit my used of swaks as
On Fri, Oct 21, 2011 at 3:31 AM, Peter Samuelson wrote:
>
> Package: swaks
> Version: 20100211.0-4
> Tags: patch
>
> The timezone field of RFC 822 date format is [+-]HHMM, whereas swaks
> calculates it as hundredths-of-an-hour. So it is wrong any time the MM
> field is nonzero. For example:
>
>
I'm pretty sure this is a dupe of deb bug 608338. The description
isn't identical but I think it's the same back end issue and I can't
reproduce in head.
--John
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@l
Package: swaks
Version: 20100211.0-3
Severity: normal
Hello. There is a debian-specific patch in the swaks package related
to the time zone created by the get_date_string() subroutine. The
patch was created in response to bug #566013, and was originally meant
to be applied against upstream versi
This was reported independently and is fixed but not yet released.
The reporter confirmed the change below worked for him. Sorry for the
nasty formatting.
##
In the 20100211 release, replace this section of code:
if (defined($o->{header}) && ref($o->{header}) eq 'ARRAY'
First, a comment on your test cases. The test case you supplied in
your follow up:
echo -e '1\n2\n3' | swaks -s localhost -p doesnotexist -g
is different than the test case derived from your original report:
echo -e '1\n2\n3' | swaks -s localhost -p 587-g
In the first example, you are
Just fixed the exipick doc bug in the exim cvs repo, it will be in the
next Exim release.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
The functionality requested in this bug is included in the latest swaks release:
http://www.jetmore.org/john/code/swaks/swaks-20100211.0/swaks
Thanks
--John
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists
I knew it was bad, but that seems excessive. Anyway, I've had a version of
this on my list for a while:
- 20050510 reading large input from STDIN is memory wasteful
I'll add the --body, --attach stuff for review also. No promise on a
timeline, but it is on my radar.
Thx
--John
20 matches
Mail list logo
