Jump to content

You're browsing the 2004-2023 VATSIM Forums archive. All content is preserved in a read-only fashion.
For the latest forum posts, please visit https://forum.vatsim.net.

Need to find something? Use the Google search below.

Actavation Email Problems?


David Reimer 913748
 Share

Recommended Posts

David Reimer 913748
Posted
Posted

From other reports I have been hearing, There have been some email problems with ISP providers.

 

I myself have registered 4 times now, and havent recived one email, And the first registration was over 5 hours ago.

 

Has anyone else been having problems?

signiture.jpg
Link to comment
Share on other sites

Johnathon Neilsen 955672
Posted
Posted

It took mine 3 hours to get here. It says sorry fot the wait but we arew xperoincing heavy server loads.

955672.png
Link to comment
Share on other sites

Ben Zwebner 906832
Posted
Posted

took mine 30 seconds...

Link to comment
Share on other sites

Michal Rok
Posted
Posted

Some ISPs believe it is in their customer interest to block every other mail server except for most popular ones like @gmail.com. I keep on mailing them and asking to unblock my server (completely legitimate one and never used for spamming) and sometimes they unblock me.

 

If your mail did not arrive in one hour, please try a different address as a temporary solution.

 

 

Michal

vroute.net founder

Link to comment
Share on other sites

Neil Jackson 969667
Posted
Posted

Michal, if you are running your own mailserver and attempting to directly p[Mod - Happy Thoughts] outbound email to another remote mailserver (ie, a 'normal' MX-record lookup-and-send) then you will find that if your mailserver is running on an IP address which is listed as 'dial-up' or in some cases 'low end-user broadband' (ie, not an ISP or recognised company domain & IP), then this will happen. The net's been like that since about 1995, alas. Users on really low grade IP addresses (ie, genuine dial-up) or in dynamic IP address pools (such as most of those used by AOL, BT-Yahoo, etc) will find it very difficult to reliably send mail direct-to-MX from their home IP - precisely because of this deliberate blocking by some of the big-name ISPs (AOL and Yahoo both implement this check to all incoming SMTP connections to their main SMTP server, to see if they're 'home users', for example)

 

It's dumb, it's stupid, it's the know-nothings at AOL (and a few sheep that followed their line) implementing a nutsy solution to a problem that hasn't even gone away as a result - that problem being the one of hijacked users on home links sending out tons of spam.. but of course, ANYONE, ANYWHERE is just as likely to get compromised, so the 'solution' actually solved nothing - it just made it harder to operate a proper SMTP mailserver from a home account, sometimes, and 'broke' the SMTP mail 'standard'. Well done, cheapo ISPs!

 

Your best solution, Michal, would be to use your own ISP's 'smartmailer' or 'smarthost' or 'gateway mailserver' (you may see it listed as various things like that - but basically, it's your own ISP's 'official' SMTP mailserver on their clients' side). Depending on what SMTP mailserver you are running locally on your system(s), you may even ba able to attempt delivery direct-by-MX-lookup, and then, only if that fails to connect, drop back to using your ISP's smartmailer.

 

That's what this stupid incoming block-list 'solution' was meant to bring about anyway - that all us 'home users' would only ever shovel ALL our email outwards to our ISPs, and then our ISPs would forward it on for us, to the recipient's ISP, who would then store it in a POP3 mailbox for the recipient to pick it up. Stupid, cos as I said, it solves nothing, and just complicates and delays the standard SMTP mail sending process, and overloads ISP mailservers even more, on a routine basis. Marvellous, eh?

 

If you are able to configure your SMTP mailer to drop back to send your ISP when MX fails, that will probably resolve your problem, at least, and you may clear your backlog a bit faster, perhaps. IMHO, the round-trip time at the moment is a bit crazy... even with a quarter-million people all registering at once, it should be feasible to autosend replies almost as quickly back, so something is evidently wrong, if your mailserver is 'choking'. More than 3 hours is a sign your queue's stalled or dying - it should be nearer a few minutes, even with that load, honest. Perhaps it's time to redirect the whole lot straight to your ISP for onward forwarding anyway, if your mailserver is having difficulty opening its connections to other, remote ISPs?

 

I'd be interested to know what mailserver app you're running, and how many simultaneous connections it has been set to open to different ISPs, and how many it's been told it can dump down one link to each given ISP (ie, does it connect and send five for users at one ISP/MX record, then disconnect, or does it connect one-by-one per user? And does it attempt connect to connect to one ISP at a time, or does it open up ten TCP sockets simultaneously to different ISPs?) Optimisation of SMTP servers is a black art...

 

(I do a lot of work with mailing lists of 20,000+ users and have a good working knowledge of SMTP servers and their vagaries, if you're wondering how come I know all this geeky stuff! It's part of my day job! )

Link to comment
Share on other sites

Michal Rok
Posted
Posted

Neil,

 

Unfortunately I have a dedicated piece of hardware in a datacenter, doing almost only vroute, and my provider does not offer a common MX.

 

The IP range is used by a large data center, so I see no reason why any netblock would be cl[Mod - Happy Thoughts]ified as "end user broadband" - unless these big ISPs use low quality data to take important decisions on behalf of their customers.

 

 

Michal

vroute.net founder

Link to comment
Share on other sites

Neil Jackson 969667
Posted
Posted
Neil,

 

Unfortunately I have a dedicated piece of hardware in a datacenter, doing almost only vroute, and my provider does not offer a common MX.

 

The IP range is used by a large data center, so I see no reason why any netblock would be cl[Mod - Happy Thoughts]ified as "end user broadband" - unless these big ISPs use low quality data to take important decisions on behalf of their customers.

 

 

Michal

 

Hi Michal

 

Understood... if you have no capability to use your upstream ISP to forward for you, that's going to make life harder. But I'm really surprised your provider doesn't at least have a smarthost - that's uncommon - because it is progressively becoming the only way an ISP can lease webhosting/dedicated server space and connectivity, and have their subscribers be able to handle outgoing email successfully. Exactly for the reasons you're seeing - unfortunately far too many ISPs (both lowgrade and bluechip) are using some very 'odd' mechanisms to determine the origin of direct SMTP connections, or to decide what is spam or not. Sometimes, just setting the mailserver up the wrong way (especially in terms of the number of simultaneous connections to the same remote mailserver) is enough to get your mailserver considered temporarily 'hostile' and thus tar-pitted or denied for periods of time.

 

Your ISP doesn't really need to offer any MX facilities in the DNS though. All they need to offer is the address of the STMP server which they've told the rest of their (home grade) users to set as their 'SMTP Server' (ie the one they send mail to) in their mail-client programs.

 

Most decent SMTP servers will have the ability to enter that 'smarthost' address as a fallback for delivery if a direct-to-MX attempt fails. You absolutely sure you've got no handoff capability? The DNS tells me your upstream provider is EasySpeedy Networks - and there appears to be a host called smtp.easyspeedy.com - will they let you forward through that if direct-delivery is being blocked?

 

I've looked up mrok.com (which I presume from studying the DNS, is where the mailserver lives), and the IP address of the mailserver comes up clean on the Multi Realtime BlackHole List Lookup page:

 

http://www.robtex.com/rbls/82.103.129.175.html

 

There's no red data showing up on that, so it doesn't appear you're being explicitly blocked - but you'll notice there are some 'not whitelisted' references recorded. I really don't know if it would be worthwhile adding your server IP to them, but perhaps it's worth looking into? I haven't ever needed to do that myself (but then, I can always hand off my 'awkward' email traffic to my upstream ISP) - so my apologies if that's a dead-end.

 

You're welcome to PM me if you'd rather not discuss this on the forum, btw. If I can help, I'm more than willing to try (time permitting!)

 

Regards

Link to comment
Share on other sites

Michal Rok
Posted
Posted

Hi Neil,

 

Your [Mod - Happy Thoughts]umption about the mail server's IP is correct.

 

I have no time at the moment to go through all these "not whitelisted" cases - right now the only ISP thats keeps actively bouncing my emails is @sbcglobal.net and I have emailed them for removal according to their own process.

 

 

Michal

vroute.net founder

Link to comment
Share on other sites

 Share