Menu
▾
▴
sqlgrey-users
|
From: Jonathan N. <jni...@pb...> - 2016-06-27 00:08:01
|
Just a couple of questions that I didn’t see covered in the archives… I see that there’s a list of pre-whitelisted servers. is this ever updated by the maintainers at any time? Is this something that we can should just do manually? if t’s recommended to just deal with it manually, what web interface is recommended these days? my setup is pretty straight forward, but there are a couple of different domains. manually adjusting the sql tables would be kind of a pain. thanks! — jonathan |
|
From: Karl O. P. <ko...@me...> - 2016-06-27 00:40:43
|
On Sun, 26 Jun 2016 19:07:54 -0500
Jonathan Nichols <jni...@pb...> wrote:
> Just a couple of questions that I didn’t see covered in the archives…
>
> I see that there’s a list of pre-whitelisted servers.
> Is this something that we can
> should just do manually?
I never do. The whole point is that it adjusts itself
once it receives incoming email.
Karl <ko...@me...>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
|
|
From: Lionel B. <lio...@bo...> - 2016-06-27 13:41:30
|
Hi, Le 27/06/2016 02:07, Jonathan Nichols a écrit : > Just a couple of questions that I didn’t see covered in the archives… > > I see that there’s a list of pre-whitelisted servers. is this ever updated by the maintainers at any time? Rarely. These pre-configured whitelists are under my direct control (the script updating them fetch files on a web server that I maintain) and my filter to allow new entries in is : - they must be cases that auto-whitelisting doesn't handle efficiently, - they must affect several users. If this doesn't pass the first test this defeats the greylisting process (greylisting is not whitelisting...). If this doesn't pass the second test this might be a fluke or a temporary situation. > Is this something that we can should just do manually? You can maintain whitelists yourself by creating files with ".local" appended to the original name. These files are under your direct control and won't ever be overwritten by SQLgrey. > > if t’s recommended to just deal with it manually, what web interface is recommended these days? > > my setup is pretty straight forward, but there are a couple of different domains. manually adjusting the sql tables would be kind of a pain. You should not have to adjust anything unless your users report delayed emails from specific domains for an extended period (several days). If there is a problem on some origin domains you can inspect the logs to find our what is going on with these domains and if they don't behave well enough for SQLgrey to auto-whitelist them add entries to /etc/sqlgrey/clients_fqdn_whitelist.local or /etc/sqlgrey/clients_ip_whitelist.local (see the original files for the format used). You are then encouraged to report them here so that I can keep track of domains which need whitelisting to perform well. Best regards, Lionel |
|
From: Philippe C. <sql...@pa...> - 2016-06-27 14:45:06
|
On 6/27/2016 9:24 AM, Lionel Bouton wrote: > [...] You are then encouraged to report them here so that I can > keep track of domains which need whitelisting to perform well. Here is a small-time host my users have discovered somehow don't retry and thus their e-mails don't come through, they may have fixed their issues since I added them in the early 2010's: # Small L.A. Law Firm assantilaw.com *.assantilaw.com Here are larger senders that probably should be considered for inclusion into global lists, outlook.com being the big one: # Mail2World is what eNom.com is using for main forwarding these days. # Retries don't necessarily come from the same machine. # [ 2014-03Mar-14 ] mail2world.com *.mail2world.com # StartSSL hates greylisting -- when verifying domain ownership # via e-mail they expect you to receive an e-mailed code essentially # immediately and will not retry without you restarting the process. startcom.org *.startcom.org startssl.com *.startssl.com # Blockchain's 2-factor auth codes expire quickly, and greylisting # makes them a pain. blockchain.info *.blockchain.info # Outlook.com users, retries do not come from the same server. # [2016-03Mar-14] outbound.protection.outlook.com *.outbound.protection.outlook.com Sorry, the comments are largely in "note-to-self/reminders" format, let me know if they're not clear. I *think* the above are in chronological order, granted not many are explicitly dated. The *. versions probably make the others redundant, but I'm paranoid. -- Philippe Chaintreuil |
|
From: Lionel B. <lio...@bo...> - 2016-06-27 14:54:16
|
Hi again, Le 27/06/2016 15:24, Lionel Bouton a écrit : > [...] > If there is a problem on some origin domains you can inspect the logs to > find our what is going on with these domains and if they don't behave > well enough for SQLgrey to auto-whitelist them add entries to > /etc/sqlgrey/clients_fqdn_whitelist.local or > /etc/sqlgrey/clients_ip_whitelist.local (see the original files for the > format used). You are then encouraged to report them here so that I can > keep track of domains which need whitelisting to perform well. One thing I forgot because it seemed obvious to me: you want to whitelist the fqdn/ip of the very first servers trying to send emails. So for best results you want to follow your logs back to the first mail transfer attempt to find out the fqdn or the ip range used then. Best regards, Lionel |
|
From: Karl O. P. <ko...@me...> - 2016-06-27 14:55:23
|
On 06/27/2016 09:29:47 AM, Philippe Chaintreuil wrote: > On 6/27/2016 9:24 AM, Lionel Bouton wrote: > > [...] You are then encouraged to report them here so that I can > > keep track of domains which need whitelisting to perform well. > # StartSSL hates greylisting -- when verifying domain ownership > # via e-mail they expect you to receive an e-mailed code essentially > # immediately and will not retry without you restarting the process. I confirm this, as of last year. > startcom.org > *.startcom.org > startssl.com > *.startssl.com > # Outlook.com users, retries do not come from the same server. > # [2016-03Mar-14] > outbound.protection.outlook.com > *.outbound.protection.outlook.com I concur. outlook.com is a pain. They ignore RFC recommendations, spat out several retries immediately, and then do not retry again for 30 minutes. (This seems to be something that the outlook software does.) Karl <ko...@me...> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein |
|
From: Lionel B. <lio...@bo...> - 2016-06-27 15:07:27
|
Hi, Le 27/06/2016 16:55, Karl O. Pinc a écrit : > On 06/27/2016 09:29:47 AM, Philippe Chaintreuil wrote: >> On 6/27/2016 9:24 AM, Lionel Bouton wrote: >>> [...] You are then encouraged to report them here so that I can >>> keep track of domains which need whitelisting to perform well. >> # StartSSL hates greylisting -- when verifying domain ownership >> # via e-mail they expect you to receive an e-mailed code essentially >> # immediately and will not retry without you restarting the process. > I confirm this, as of last year. > >> startcom.org >> *.startcom.org >> startssl.com >> *.startssl.com >> # Outlook.com users, retries do not come from the same server. >> # [2016-03Mar-14] >> outbound.protection.outlook.com >> *.outbound.protection.outlook.com > I concur. outlook.com is a pain. They ignore RFC > recommendations, spat out several retries immediately, > and then do not retry again for 30 minutes. (This > seems to be something that the outlook software does.) Thanks : *.startcom.org *.startssl.com *.outbound.protection.outlook.com Added to the public whitelists in the " Requested by MTA admins " section If I have confirmation of the non-wildcard entries usefulness I'll add them too. All users running "update_sqlgrey_config" (either by crontab or manually will get these new entries). Best regards, Lionel |
|
From: Karl O. P. <ko...@me...> - 2016-06-27 15:27:50
|
Sorry Lionel, I'm confirming that these should be whitelisted. But, while I recall the below as the correct domains, I've not examined my logs and checked. On 06/27/2016 10:07:20 AM, Lionel Bouton wrote: > Hi, > > Le 27/06/2016 16:55, Karl O. Pinc a écrit : > > On 06/27/2016 09:29:47 AM, Philippe Chaintreuil wrote: > >> On 6/27/2016 9:24 AM, Lionel Bouton wrote: > >>> [...] You are then encouraged to report them here so that I can > >>> keep track of domains which need whitelisting to perform well. > >> # StartSSL hates greylisting -- when verifying domain ownership > >> # via e-mail they expect you to receive an e-mailed code > essentially > >> # immediately and will not retry without you restarting the > process. > > I confirm this, as of last year. > > > >> startcom.org > >> *.startcom.org > >> startssl.com > >> *.startssl.com > >> # Outlook.com users, retries do not come from the same server. > >> # [2016-03Mar-14] > >> outbound.protection.outlook.com > >> *.outbound.protection.outlook.com > > I concur. outlook.com is a pain. They ignore RFC > > recommendations, spat out several retries immediately, > > and then do not retry again for 30 minutes. (This > > seems to be something that the outlook software does.) > > Thanks : > > *.startcom.org > *.startssl.com > *.outbound.protection.outlook.com > > > Added to the public whitelists in the " Requested by MTA admins " > section > > If I have confirmation of the non-wildcard entries usefulness I'll > add > them too. > > All users running "update_sqlgrey_config" (either by crontab or > manually > will get these new entries). > > Best regards, > > Lionel > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in > San > Francisco, CA to explore cutting-edge tech and listen to tech > luminaries > present their vision of the future. This family event has something > for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > Sqlgrey-users mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlgrey-users > > Karl <ko...@me...> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein |
|
From: Philippe C. <sql...@pa...> - 2016-06-27 16:05:38
|
On 6/27/2016 11:27 AM, Karl O. Pinc wrote:
> Sorry Lionel, I'm confirming that these should
> be whitelisted. But, while I recall the below as the
> correct domains, I've not examined my logs and checked.
Starting with confirmations.
BlockChain.info:
======================================================================
Jun 27 11:37:01 ip-172-30-3-20 sqlgrey[4430]: whitelist:
XXX...@ma..., 198.21.6.174(o1.mail.blockchain.info) ->
XX...@pa...
======================================================================
An Outlook.com hosted Domain:
======================================================================
Jun 27 11:40:28 ip-172-30-3-20 sqlgrey[4430]: whitelist:
XX...@XX...,
65.55.169.120(mail-bl2on0120.outbound.protection.outlook.com) ->
XX...@pa...
======================================================================
And in the "repudiating my own advice" category:
StartSSL.com
======================================================================
Jun 27 11:32:41 ip-172-30-3-20 postfix/smtpd[12272]: NOQUEUE: reject:
RCPT from mta2.startcomca.com[4.14.40.143]: 450 4.7.1
<XX...@pa...>: Recipient address rejected: Greylisted for 5
minutes; from=<no-...@st...> to=<XX...@pa...>
proto=ESMTP helo=<mta2.startcomca.com>
======================================================================
So they've apparently move to yet another domain "mta2.startcomca.com".
I don't have a way to trigger an eNom forwarding e-mail
(Mail2World.com) just now, but I might be able to get one from one of my
users. When I get one I'll pass it along.
-- Philippe Chaintreuil
|
|
From: Lionel B. <lio...@bo...> - 2016-06-27 14:50:07
|
Hi, Le 27/06/2016 16:29, Philippe Chaintreuil a écrit : > On 6/27/2016 9:24 AM, Lionel Bouton wrote: >> [...] You are then encouraged to report them here so that I can >> keep track of domains which need whitelisting to perform well. > Here is a small-time host my users have discovered somehow don't retry > and thus their e-mails don't come through, they may have fixed their > issues since I added them in the early 2010's: > > # Small L.A. Law Firm > assantilaw.com > *.assantilaw.com For this and the following entries, is the domain name really the fqdn of one of the sources ? I ask because the less entries we add, the less CPU we use. So if none of their servers resolves to "assantilaw.com" this is superfluous. If anyone could confirm these entries that would speed up their inclusion. Best regards, Lionel |
|
From: Philippe C. <sql...@pa...> - 2016-06-27 15:28:24
|
On 6/27/2016 10:49 AM, Lionel Bouton wrote: >> # Small L.A. Law Firm >> assantilaw.com >> *.assantilaw.com > > For this and the following entries, is the domain name really the fqdn > of one of the sources ? > I ask because the less entries we add, the less CPU we use. So if none > of their servers resolves to "assantilaw.com" this is superfluous. I don't remember, but their MX records are now googlemail.com, so I'm betting they've switched away from whatever homegrown, non-compliant setup they were using when this was an issues several years ago. I'd now say, 100% ignore this one. -- Philippe Chaintreuil |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X