perlbug does not send email properly

[p5pRT]

Migrated from rt.perl.org#30968 (status was 'resolved')

Searchable as RT30968$

[p5pRT]

From warren.dodge@tektronix.com

Created by warrend@tek.com

I used perlbug on my PC to send a bug. It worked great up to sending the email. It then quit with the following messages.

Action (Send/Display/Edit/Subject/Save to File)​: send Are you certain you want to send this message? Please type "yes" if you are​: yes

I am terribly sorry\, but I cannot find sendmail\, or a close equivalent\, and the perl package Mail​::Send has not been installed\, so I can't send your bug report. We apologize for the inconvenience.

So you may attempt to find some way of sending your message\, it has been left in the file `C​:\DOCUME~1\WARREN~1.GLO\LOCALS~1\Temp\YhtxvYUhx7'.

It seems that this is a shortcoming of the basic perl installation.

I had loaded Mail​::Sendmail into the site library tree which is what I use for my scripts.

Hopefully something can be done to make perlbug work.

Thanks

Perl Info

``` Flags: category=utilities severity=low Site configuration information for perl v5.8.4: Configured by ActiveState at Tue Jun 1 11:52:09 2004. Summary of my perl5 (revision 5 version 8 subversion 4) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=undef use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cl', ccflags ='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX', optimize='-MD -Zi -DNDEBUG -O1', cppflags='-DWIN32' ccversion='', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -libpath:"C:\Perl584\lib\CORE" -machine:x86' libpth=C:\PROGRA~1\MICROS~3\VC98\lib libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib gnulibc_version='undef' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf -libpath:"C:\Perl584\lib\CORE" -machine:x86' Locally applied patches: ACTIVEPERL_LOCAL_PATCHES_ENTRY 22751 Update to Test.pm 1.25 21540 Fix backward-compatibility issues in if.pm @INC for perl v5.8.4: C:/Perl584/lib C:/Perl584/site/lib . Environment for perl v5.8.4: HOME=U:\ LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=C:\Perl584\bin\;j:\apps\perl561\bin;c:\oracle\ora92\bin;C:\Program Files\Oracle\jre\1.3.1\bin;C:\Program Files\Oracle\jre\1.1.8\bin;C:\WINNT\System32\Wbem;c:\emacs-21.2\bin;C:\Program Files\Microsoft SMS Installer\Installer Step-up Utility\Apps;C:\Program Files\Microsoft SMS Installer\Installer Step-up Utility\Apps\Extensions;c:\cygwin\USR\X11R6;c:\cygwin\USR\X11R6\BIN;C:\WINNT\system32;C:\WINNT;C:\EDPM\java\jdk1.3.1_03\jre\bin\hotspot;C:\EDPM\bin;J:\apps\edatools\psd\15.2a\tools\pcb\bin;J:\apps\edatools\psd\15.2a\tools\bin;J:\apps\edatools\psd\15.2a\tools\Capture;J:\apps\edatools\psd\15.2a\tools\fet\bin;J:\apps\edatools\psd\15.2a\tools\specctra\bin;J:\apps\edatools\psd\15.2a\tools\libutil\bin;J:\apps\edatools\psd\15.2a\tools\jre\bin;J:\apps\edatools\psd\15.2a\tools\pspice;J:\apps\edatools\fetools\psd152\bin;J:\apps\edatools\cadtools\psd152\bin;"C:\temp" PERL_BADLANG (unset) SHELL (unset) ```

[p5pRT]

@JohnPeacock - Status changed from 'new' to 'open'

[p5pRT]

From @JohnPeacock

Windows does not include a built in mail program (that Perl can use\, at any rate). Mail​::Send can be used by Perlbug\, but that is different from Mail​::Sendmail (the latter of which only provides a sendmail() sub\, but not a sendmail program that can be used out of the box).

If you install Mail​::Send\, you can correctly send perlbug messages directly from Windows.

HTH

John Peacock

[p5pRT]

@JohnPeacock - Status changed from 'open' to 'resolved'

[p5pRT]

From warren.dodge@tektronix.com

I guess my thought is that perlbug should work out of the box. I assume it does on Unix. I would think Mail​::Send would be included in the distribution. I would suspect any new user isn't going to know how to get the module to make this work.

Just my thoughts. I know how to deal with it.

[p5pRT]

From @JohnPeacock

Warren L Dodge wrote​:

I guess my thought is that perlbug should work out of the box. I assume it does on Unix.

It _does_ work out of the box; it's your platform that is lacking essential features. ;)

I would think Mail​::Send would be included in the distribution. I would suspect any new user isn't going to know how to get the module to make this work.

By the same token\, any new user (on Win32) is unlikely to be running perlbug in the first place. I don't know why Mail​::Send isn't in the core; probably because it isn't important enough to most users to justify the extra bloat just so one platform can run perlbug without installing it.

John

-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham\, MD 20706 301-459-3366 x.5010 fax 301-429-5747

[p5pRT]

From @ysth

On Mon\, Aug 16\, 2004 at 10​:22​:02PM -0400\, John Peacock \jpeacock@​rowman\.com wrote​:

Warren L Dodge wrote​:

I guess my thought is that perlbug should work out of the box. I assume it does on Unix.

It _does_ work out of the box; it's your platform that is lacking essential features. ;)

I would think Mail​::Send would be included in the distribution. I would suspect any new user isn't going to know how to get the module to make this work.

By the same token\, any new user (on Win32) is unlikely to be running perlbug in the first place. I don't know why Mail​::Send isn't in the core; probably because it isn't important enough to most users to justify the extra bloat just so one platform can run perlbug without installing it.

They can run perlbug even without it\, using the Save to file option and their usual email client.

[p5pRT]

From @hvds

Yitzchak Scott-Thoennes \sthoenna@​efn\.org wrote​: :On Mon\, Aug 16\, 2004 at 10​:22​:02PM -0400\, John Peacock \jpeacock@​rowman\.com wrote​: :> Warren L Dodge wrote​: :> >I guess my thought is that perlbug should work out of the box. I assume it :> >does on Unix. [...] :They can run perlbug even without it\, using the Save to file option and :their usual email client.

In that case\, is it not possible for perlbug to detect the situation and offer only the relevant options?

Hugo

[p5pRT]

From @demerphq

It _does_ work out of the box; it's your platform that is lacking essential features. ;)

I would think Mail​::Send would be included in the distribution. I would suspect any new user isn't going to know how to get the module to make this work.

By the same token\, any new user (on Win32) is unlikely to be running perlbug in the first place. I don't know why Mail​::Send isn't in the core; probably because it isn't important enough to most users to justify the extra bloat just so one platform can run perlbug without installing it.

They can run perlbug even without it\, using the Save to file option and their usual email client.

The thing that seems stupid about this to me is that there is a 99% chance that a Win32 user is going to want to talk directly to an SMTP server\, and Net​::SMTP IS a core module. It shouldn't be that serious a deal to hack perlbug to just directly use Net​::SMTP for the mail.

IE\, if its on Win32 and cant find a proper mail module (Mail​::Send\, MIME​::Lite etc\, the latter is probably more widely used on Win32 afaik) then it should check to see if libnet.cfg has been configured for SMTP\, if not ask if there is an SMTP server available\, and assuming one can be found simply use Net​::SMTP for the job.

However IMO an _even_ better thing to do would be to provide an XML gateway for submitting perlbug reports via HTTP. Then perlbug could simply connect to the gateway and upload the relevent data via XML and the gateway would handle the rest\, then you could eliminate the email dependency entirely in 99% of situations where folks need to use it.

Yves

[p5pRT]

From @rgs

Orton\, Yves wrote​:

However IMO an _even_ better thing to do would be to provide an XML gateway for submitting perlbug reports via HTTP. Then perlbug could simply connect to the gateway and upload the relevent data via XML and the gateway would handle the rest\, then you could eliminate the email dependency entirely in 99% of situations where folks need to use it.

Ooh\, brilliant idea (except maybe the "XML" part :). Hasn't RT a web interface\, that could be adapted ?

[p5pRT]

From @demerphq

Rafael Garcia-Suarez replied​:

Orton\, Yves wrote​:

However IMO an _even_ better thing to do would be to provide an XML gateway for submitting perlbug reports via HTTP. Then perlbug could simply connect to the gateway and upload the relevent data via XML and the gateway would handle the rest\, then you could eliminate the email dependency entirely in 99% of situations where folks need to use it.

Ooh\, brilliant idea (except maybe the "XML" part :). Hasn't RT a web interface\, that could be adapted ?

Well\, if the XML stuff bothers you I suppose it could just upload the file that would normally be emailed.

Maybe Autrijius has an idea what the easiest/best way to do this is?

Cheers\, Yves

[p5pRT]

From @rspier

The thing that seems stupid about this to me is that there is a 99% chance that a Win32 user is going to want to talk directly to an SMTP server\, and Net​::SMTP IS a core module. It shouldn't be that serious a deal to hack perlbug to just directly use Net​::SMTP for the mail.

Which SMTP server? I don't think I've _ever_ configured a default one for libnet. How do we know we're even on a box with a routable network connection that can talk to port 25 on the outside world? Or even inside world?

However IMO an _even_ better thing to do would be to provide an XML gateway for submitting perlbug reports via HTTP. Then perlbug could simply connect to the gateway and upload the relevent data via XML and the gateway would handle the rest\, then you could eliminate the email dependency entirely in 99% of situations where folks need to use it.

Thanks for volunteering! That's a great idea. We can host it with the perlbug systems once it's designed and written.

-R

[p5pRT]

From @demerphq

Robert Spier wrote on 18 August 2004 at 05​:13​:

The thing that seems stupid about this to me is that there is a 99% chance that a Win32 user is going to want to talk directly to an SMTP server\, and Net​::SMTP IS a core module. It shouldn't be that serious a deal to hack perlbug to just directly use Net​::SMTP for the mail.

Which SMTP server? I don't think I've _ever_ configured a default one for libnet. How do we know we're even on a box with a routable network connection that can talk to port 25 on the outside world? Or even inside world?

Most win32 users who do email that ive had to deal with have been using SMTP servers directly and often have configured libnet.cfg. I assumed that the Win32 users who are likely to bother with perlbug are in the camp that would either know these details and could respond to a prompt or have configured it in libnet.cfg so they don't have to enter it every time they need to use perl to send emails\, which in my experience on win32 is one of the easier ways to do so and such IME is quite common.

Either way looking for sendmail on win32 seems silly as it almost certainly _wont_ be there. And as its quite likely they do have connectivity and access to an SMTP server it seems logical to at least try to make it easier for them.

However IMO an _even_ better thing to do would be to provide an XML gateway for submitting perlbug reports via HTTP. Then perlbug could simply connect to the gateway and upload the relevent data via XML and the gateway would handle the rest\, then you could eliminate the email dependency entirely in 99% of situations where folks need to use it.

Thanks for volunteering! That's a great idea. We can host it with the perlbug systems once it's designed and written.

Tell me what to patch against and ill give it a go\, or did you mean totally independent of the current codebase? Also is there a reason that there is no way for guest users to enter a bug via the perlbug website? Maybe you could talk to me offlist and well see what we can do?

yves

[p5pRT]

From @rspier

Maybe you could talk to me offlist and well see what we can do?

Taking offlist\, as suggested.

-R

[p5pRT]

From whatever@davidnicol.com

Making perlbug open up a direct SMTP channel to mx.develooper.com would not be that difficult\, but the current need-to-configure does filter out certain naive bug reports I am certain

-- david nicol   "Someday\, everything's going to be different   when I paint my masterpiece."

[p5pRT]

From alexmv@bestpractical.com

On Wed\, 2004-08-18 at 18​:23\, david nicol wrote​:

[snip] You could also skip the mail gateway entirely\, and send a POST request to http​://rt.perl.org/rt3/REST/1.0/NoAuth/mail-gateway with parameters​:   queue => "perl5"\,   action => "correspond"\,   message => # Full email message\, including headers

- Alex

-- Networking -- one letter away from not working

[p5pRT]

From @rspier

You could also skip the mail gateway entirely\, and send a POST request to http​://rt.perl.org/rt3/REST/1.0/NoAuth/mail-gateway with parameters​: queue => "perl5"\, action => "correspond"\, message => # Full email message\, including headers

Please don't even *think* of doing this. It totally bypasses all of our spam/virus/idiot checks.

Thanks for pointing out a hole. I've now blocked it.

-R

[p5pRT]

From @rspier

Making perlbug open up a direct SMTP channel to mx.develooper.com would not be that difficult\, but the current need-to-configure does filter out certain naive bug reports I am certain

That would just cause an influx of mail from poorly configured systems that would likely be blocked by our MTA for your protection.

And at some indeterminate point in the future\, it is possible that the relay will need to change. Then we're stuck with having to change all the C\ programs out there.

-R

[p5pRT]

From whatever@davidnicol.com

we would have to commit to an MX alias for the purpose -- I only said mx.develooper because that is the current correct value -- getting perlbug to send its own mail would require\, IMO\, some support on the receiving end for at least one DNS record that will remain valid for this purpose\, and working DNS on the sending end.

The suggestion is to lower the bar for ability to submit a bug report from where it currently is\, to something slightly lower. "Having working DNS" instead of "Having working outbound command line MUA that perlbug knows about" || "reporter ability to write perlbug to file and invoke command line MUA"

A DNS name would be selected and a committment made to keep it valid\, perhaps perlbug-mx-inbound.rt.perl.org.

But if we've got programmatic control of both ends\, there's no technical reason to prefer SMTP\, and various political reasons against it\, in particular firewalls (i doubt very much this is news to anyone reading this list.)

Following the negotiating principles from _Getting To Yes_ we should agree on\, "do we or do we not wish to lower the bar on entering bugs?" before deciding "how far" and only then\, start discussing approaches.

As if we were really that organized.

David Nicol\, in final year of a MBA program

On Sun\, 2004-08-29 at 00​:18\, Robert Spier wrote​:

And at some indeterminate point in the future\, it is possible that the relay will need to change. Then we're stuck with having to change all the C\ programs out there.

-R -- david nicol   "Someday\, everything's going to be different   when I paint my masterpiece."

[p5pRT]

From @nwc10

On Tue\, Aug 31\, 2004 at 05​:03​:04PM -0500\, david nicol wrote​:

The suggestion is to lower the bar for ability to submit a bug report from where it currently is\, to something slightly lower. "Having working DNS" instead of "Having working outbound command line MUA that perlbug knows about" || "reporter ability to write perlbug to file and invoke command line MUA"

Colour me cynical\, but anyone who is sufficiently non-savvy to manage to write a perlbug report to a file and then run a mail program is unlikely to be able to submit an actionable bug report. And I'm quite happy not to receive crap bug reports.

If people have the time\, I think that the effort would be better spent in dealing with the good but unresolved bug reports that we already have\, and already get lots of.

Following the negotiating principles from _Getting To Yes_ we should agree on\, "do we or do we not wish to lower the bar on entering bugs?" before deciding "how far" and only then\, start discussing approaches.

Bang on. I do not wish to lower the bar. If you can't get over the bar at the moment\, you should be seeking help from someone else first\, who in turn can send the bug on *if it really is a bug in perl*

As if we were really that organized.

David Nicol\, in final year of a MBA program

Organising our volunteer labour significantly better is somewhat jumping the gun. I fear you've missed the prerequisite problem - that we don't have enough skilled and willing and committed volunteer labour.

Nicholas Clark