V18 not using smtp Port declarations when sending emails

[Mike Hughes]

V18.0.0 SEGA is not using the smtp port declarations when sending emails as the variable isn't used anywhere.

It's a fairly obvious bug in the sellerdeck code but took me a while to work out what they're doing and where the problem was.

Selleredeck have a declaration for the smtp port but then don't use it anywhere.

Here's the code that doesn't work. Line 482 in "SmtpLibrary.pm

my $smtp = Net::SMTP->new($smtp_host, Debug => $debug, Timeout => $nTimeout, Domain => PF_INET);

Whereas what does work is if you add in the Port declaration:

my $smtp = Net::SMTP->new($smtp_host, Debug => $debug, Timeout => $nTimeout, Domain => PF_INET, Port => $nPort);

Tested and working with Sendgrid using $nPort = 2525; It send the emails and passes the network test.

I haven't bothered with the second port declaration but it looks like the same thing is happening there.

Mike

PS. If possible it would be great if the fix could also incorporate using a variable that is set in the network settings to define the port number being used. It would save anyone needing to set the smtp port from having to modify the scripts after every upgrade.

[brucet]

Hi Mike

Changing the SMTP port has always required a script modification. We do have a wish list ticket for making it configurable via the UI. I have added your request to it.

[Goz]

Bruce - what Mike is actually saying is that you are declaring the port number (regardless of whether it should be configurable) but you are not using it in the script and, therefore, the script will not work in many circumstances.

I can confirm that the unmodified script does work on SellerDeck hosting but it did not work on 20i or Heart Internet hosting.

I can also confirm that Mike's modification enables the script to work on 20i and Heart Internet. I haven't bothered to test it on SellerDeck hosting.


While you have added the request to make the port configurable you have not acknowledged the bug nor said if it will be fixed in the next release.

[Mike Hughes]

Probably my fault for including a wish request along with the Bug Report.

Bruce if you could just confirm you're aware that this thread does contain a bug report as well as the wish request you've noted then that would avoid any confusion.

Thanks

Mike

[brucet]

The variable has always been in the code. Probably it was anticipated that it would be used, but it never has been, at least not yet. A dormant variable might seem untidy, but we would not regard it as a bug or give development time to removing it, since it doesn't actually break anything, and it might be required in the future.

Changing the SMTP port has always required a script modification. In v18 there are extensive script changes to support secure SMTP, whilst retaining backwards compatibility for sites that lack the Net::SMTP module. So the script modification required in v18 would be different from previous versions. Unfortunately that's unavoidable in this case.

The wish list ticket for changing the port number has attracted 3 requests in 13 years, so the use of a non-standard port number actually seems very unusual.

[Mike Hughes]

Sorry Bruce but you're wrong on this

The variable has always been in the code. Probably it was anticipated that it would be used, but it never has been, at least not yet. A dormant variable might seem untidy, but we would not regard it as a bug or give development time to removing it, since it doesn't actually break anything, and it might be required in the future.

The SMTP port variables were used in the past. Changing the set value had the effect of changing the port number used by the scripts. This is well documented on the forum and is something some of us have been using for some time.So it wasn't dormant in the past and is now. Someone is telling you porkies.

I can understand developers being keen to keep bug lists down as it's probably something they're being measured on, but viewed in the spirit of co-operation with it's users I find a public attempt to cover up mistakes and deny them as bugs as rather regrettable.

[Goz]

The wish list ticket for changing the port number has attracted 3 requests in 13 years, so the use of a non-standard port number actually seems very unusual.

You may have only had 3 requests for this in 13 years but there has been plenty of talk about this on this Forum.

As someone who provides hosting with 3 different providers and also deals with plenty of other clients who host elsewhere, I can tell you that a) port 587 is not a non-standard port number and b) it is not unusual.

I think it is as much a case of your user base do not know how to make requests? I certainly don't and I've been with you since 2005!

[NormanRouxel]

so the use of a non-standard port number actually seems very unusual

Bruce. It may seem so to you but in the rest of the world it is often different. 587 and 2525 come to mind immediately.

I have nagged about the need for an SMTP port variable several times. Your mention of 3 requests is perhaps small because those who know what an SMTP port is are probably capable of fixing it themselves. Especially when how to do so has been on this forum for several years.

[NormanRouxel]

your user base do not know how to make requests

Goz, request form is on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'.

[guccij]

Goz, request form is on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'.

Plus random characters to make up the minimum.

[Mike Hughes]

I think you might need a flashlight to find them....

[Goz]

The line to change is now on line 496 in the version of smtplibrary in SD18.0.2

[Goz]

And it is not fixed in SD18.0.3

So, when you upgrade remember to redo these changes - it is still on line 496 plus any changes you need to make to $nPort to make it work with your host.

[brucet]

Thanks for your persistence with this. I have raised it as a usability issue now, ref. SD-7615, and will endeavour to get a setting added to the UI in a v18 maintenance release.

[Buzby]

half a day I have spent trying to work out why Sellerdeck wasn't working. Many thanks to Goz for showing me this thread, and of course Mike for the fix.

2 things amaze me about this,

1 being that this was in the first version and is still current.
2 Do Sellerdeck not test this software, this isn't a little bug it is a massive bug that will be a problem from day 1.