You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(10) |
Nov
(37) |
Dec
(66) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(52) |
Feb
(136) |
Mar
(65) |
Apr
(38) |
May
(46) |
Jun
(143) |
Jul
(60) |
Aug
(33) |
Sep
(79) |
Oct
(29) |
Nov
(13) |
Dec
(14) |
2006 |
Jan
(25) |
Feb
(26) |
Mar
(4) |
Apr
(9) |
May
(29) |
Jun
|
Jul
(9) |
Aug
(11) |
Sep
(10) |
Oct
(9) |
Nov
(45) |
Dec
(8) |
2007 |
Jan
(82) |
Feb
(61) |
Mar
(39) |
Apr
(7) |
May
(9) |
Jun
(16) |
Jul
(2) |
Aug
(22) |
Sep
(2) |
Oct
|
Nov
(4) |
Dec
(5) |
2008 |
Jan
|
Feb
|
Mar
(5) |
Apr
(2) |
May
(8) |
Jun
|
Jul
(10) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
(32) |
May
|
Jun
(7) |
Jul
|
Aug
(38) |
Sep
(3) |
Oct
|
Nov
(4) |
Dec
|
2010 |
Jan
(36) |
Feb
(32) |
Mar
(2) |
Apr
(19) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
(8) |
Dec
|
2011 |
Jan
(3) |
Feb
|
Mar
(5) |
Apr
|
May
(2) |
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(6) |
2012 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(6) |
Dec
(10) |
2014 |
Jan
(8) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(34) |
Aug
(6) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(18) |
Jul
(13) |
Aug
(30) |
Sep
(4) |
Oct
(1) |
Nov
|
Dec
(4) |
2016 |
Jan
(2) |
Feb
(10) |
Mar
(3) |
Apr
|
May
|
Jun
(11) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Lionel B. <lio...@bo...> - 2015-07-03 22:26:31
|
On 07/04/15 00:21, Bruce Bodger wrote: > [...] > > P.S. Even though I've been running sqlgrey for 6 years I've never been > sure what the whitelist requires. Is troubled.com equivalent to > *.troubled.com? My intention is to add all servers and users in the > troubled.com domain. I've been adding both. The whitelisting is about the ips or fqdns of the mail servers contacting yours and not the addresses of the sender (so they might not share the same domain). If you are not sure about what they are you should be able to find them in your postfix logs. Lionel |
From: Bruce B. <bb...@bo...> - 2015-07-03 22:21:20
|
Thanks for your feedback Karl, Dan, and Lionel.. On 7/3/15 12:33 PM, Karl O. Pinc wrote: > On Fri, 3 Jul 2015 11:13:03 -0500 > Bruce Bodger <bb...@bo...> wrote: > >> I'm wondering how many of you have implemented the sqlgrey mod >> described here... http://www.hyllander.org/sqlgrey_whitelisting > Some thoughts, take them for what you will: > > If it were me I'd avoid modifying sqlgrey and write a little > postfix filter that frobs the database whitelist directly. > I'm no advocate of re-inventing the wheel, and honestly > didn't read the article in detail, but simpler seems better > than more complicated. > I understand your perspectives. I've been running sqlgrey since 2009. I was just wondering if you saw this issue as a big deal and, obviously, you don't. As soon as I hear from a recipient having any problem sending us email I check the mail log and then add their domain to clients_fqdn_whitelist.local if I see that they've truly connected. Again, thanks for the replies. BTW, I've kept the reject_code = 451 default since original installation. P.S. Even though I've been running sqlgrey for 6 years I've never been sure what the whitelist requires. Is troubled.com equivalent to *.troubled.com? My intention is to add all servers and users in the troubled.com domain. I've been adding both. Thanks again, Bruce |
From: Karl O. P. <ko...@me...> - 2015-07-03 17:33:55
|
On Fri, 3 Jul 2015 11:13:03 -0500 Bruce Bodger <bb...@bo...> wrote: > I'm wondering how many of you have implemented the sqlgrey mod > described here... http://www.hyllander.org/sqlgrey_whitelisting Some thoughts, take them for what you will: If it were me I'd avoid modifying sqlgrey and write a little postfix filter that frobs the database whitelist directly. I'm no advocate of re-inventing the wheel, and honestly didn't read the article in detail, but simpler seems better than more complicated. On a related note, to actually solve the problem you must know exactly what the problem is. It's not clear from your description just why there was an issue in the first place. Karl <ko...@me...> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein |
From: <da...@ha...> - 2015-07-03 17:26:27
|
Just a side note. On 2015-07-03 18:13, Bruce Bodger wrote: > often that I receive a call from a customer informing me that the email > that he attempted to send to us resulted in an error message (from his > If you by "error message" mean that the sender receives a mail that looks like a bounce (but isn't), I eliminated most of those at my old job, by using reject_code = 451 which is actually why i added the reject_code option in the first place :).. - Dan |
From: Lionel B. <lio...@bo...> - 2015-07-03 17:05:39
|
Hi Bruce, On 07/03/15 18:13, Bruce Bodger wrote: > Good day, > > I'm wondering how many of you have implemented the sqlgrey mod described > here... http://www.hyllander.org/sqlgrey_whitelisting It's not very > often that I receive a call from a customer informing me that the email > that he attempted to send to us resulted in an error message (from his > perspective). And the last time was when he was replying to a message > that I sent to him! Of course, the "auto-whitelisting of recipient > addresses" wouldn't help a bit until someone in my domain writes to a > customer but it might add an additional layer of automation. I realize > that the problem relates to broken mail servers but it's our customers > who are inconvenienced and our business that might suffer. It's unlikely your business will suffer: if your customer reports this kind of errors, he probably have them with multiple other destinations (unless his/her admin was temporarily playing with parameters of the mail server) as greylisting and temporary errors are commonplace. If you aren't prepared to explain that everything is fine there is support for whitelisting your customer mail servers (instead of his domain or addresses as implemented in the patch above which would make easy to circumvent greylisting by simply using fake addresses derived from your known customers). Just add entries to /etc/sqlgrey/clients_fqdn_whitelist.local or /etc/sqlgrey/clients_ip_whitelist.local depending on how you want to whitelist (by fqdn or ip). You don't have to restart SQLgrey, these files are automatically reloaded when modified. Best regards, Lionel |
From: Bruce B. <bb...@bo...> - 2015-07-03 16:38:07
|
Good day, I'm wondering how many of you have implemented the sqlgrey mod described here... http://www.hyllander.org/sqlgrey_whitelisting It's not very often that I receive a call from a customer informing me that the email that he attempted to send to us resulted in an error message (from his perspective). And the last time was when he was replying to a message that I sent to him! Of course, the "auto-whitelisting of recipient addresses" wouldn't help a bit until someone in my domain writes to a customer but it might add an additional layer of automation. I realize that the problem relates to broken mail servers but it's our customers who are inconvenienced and our business that might suffer. Does anyone have experience with this auto-whitelisting of recipients mod? Thanks, ~Bruce |
From: <da...@ha...> - 2015-07-03 09:46:22
|
Hi Alex.. On 2015-07-03 03:45, Alex wrote: > They may or may not also resend from a different box, > doing a round-robin on outbound mail gateways. > Mail (probably) eventually gets delivered when all the boxes (IPs) > are whitelisted. But it means that legitimate mail > can get overly delayed. (Dunno who's doing this any more.) > I'm using db_cluster to avoid this. round-robin issue. This was one of > the main reasons I chose sqlgrey over the others like postgrey. Is > this not what you're talking about? No db_cluster (or a central db for that matter) solves the problem of 1 foreign IP hitting multiple servers at YOUR end. Not multiple foreign servers, with different IP's, hitting your mail server(s). sqlgrey stores the ip of the sender, either full or as partial, in the db. But if that ip changes, sqlgrey sees it as an entirely new "connection" and has to add that one as well. So now sqlgrey has 2 new connections from the same mail-cluster and both new ip's must resubmit to be whitelisted and be able to send mail through sqlgrey. Hence; they are treated as 2 different mail setups. One always has to remember the purpose of SQLGrey & Greylisting. The purpose is not filtering spam. The purpose is filtering out mail-senders that aren't real mailservers. if it IS a real mailserver but it still sends spam, that is NOT something sqlgrey can do anything about. Thats a job for other spam-filtering mechanisms. So, if we KNOW that eg. google.com are actually real mailservers and that they will alway behave as such, then there is no danger of whitelisting, as you are only whitelisting the fact that they ARE real mailservers; not that they arent sending spam. And as Karl points out, you save time for the clients by whitelisting, as they dont have to do the whole resubmit-dance to determine that they are in fact a real mailserver, when we already know it is. > Thanks, > Alex > Regards - Dan |
From: Alex <mys...@gm...> - 2015-07-03 01:45:29
|
Hi, On Thu, Jul 2, 2015 at 1:08 AM, Karl O. Pinc <ko...@me...> wrote: > On Wed, 01 Jul 2015 20:39:57 -0400 > Alex Regan <mys...@gm...> wrote: > >> It appears the default installation includes an auto-whitelist entry >> for google.com and yahoo.com. >> >> Is there a particular reason for this that would prevent me from >> removing it? I'm seeing quite a bit of spam that I believe could >> otherwise be blocked if the whole domain wasn't whitelisted. > > The google and yahoo servers are going to obey the rules > and retry after an appropriate interval and deliver > the spam anyway. You may as well reduce the load and > accept it immediately. Ah, right, makes sense. > They may or may not also resend from a different box, > doing a round-robin on outbound mail gateways. > Mail (probably) eventually gets delivered when all the boxes (IPs) > are whitelisted. But it means that legitimate mail > can get overly delayed. (Dunno who's doing this any more.) I'm using db_cluster to avoid this. round-robin issue. This was one of the main reasons I chose sqlgrey over the others like postgrey. Is this not what you're talking about? Thanks, Alex |
From: Karl O. P. <ko...@me...> - 2015-07-02 05:08:43
|
On Wed, 01 Jul 2015 20:39:57 -0400 Alex Regan <mys...@gm...> wrote: > It appears the default installation includes an auto-whitelist entry > for google.com and yahoo.com. > > Is there a particular reason for this that would prevent me from > removing it? I'm seeing quite a bit of spam that I believe could > otherwise be blocked if the whole domain wasn't whitelisted. The google and yahoo servers are going to obey the rules and retry after an appropriate interval and deliver the spam anyway. You may as well reduce the load and accept it immediately. They may or may not also resend from a different box, doing a round-robin on outbound mail gateways. Mail (probably) eventually gets delivered when all the boxes (IPs) are whitelisted. But it means that legitimate mail can get overly delayed. (Dunno who's doing this any more.) Regards, Karl <ko...@me...> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein |
From: Alex R. <mys...@gm...> - 2015-07-02 00:40:05
|
Hi, It appears the default installation includes an auto-whitelist entry for google.com and yahoo.com. Is there a particular reason for this that would prevent me from removing it? I'm seeing quite a bit of spam that I believe could otherwise be blocked if the whole domain wasn't whitelisted. Ideas greatly appreciated. Thanks, Alex |
From: Hajo S. <ha...@ha...> - 2015-06-13 14:51:23
|
Could one of the mods please remove the below guy from the list? -- Composed on my tablet. Apologies for typos. PGP key: http://tinyurl.com/neswujo > On 13 Jun, 2015, at 17:32, nc...@xn... wrote: > > Dear Sender > > The mail address nc...@xn... is not used anymore. If you want to contact me. Please use my new address. > > fir...@tr... > > Firstname: Niccolo > Lastname: Camponovo > > > Best Regards > Niccolo Camponovo > > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Sqlgrey-users mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlgrey-users |
From: <nc...@xn...> - 2015-06-13 12:02:17
|
Dear Sender The mail address nc...@xn... is not used anymore. If you want to contact me. Please use my new address. fir...@tr... Firstname: Niccolo Lastname: Camponovo Best Regards Niccolo Camponovo |
From: <nc...@xn...> - 2015-06-12 12:01:07
|
Dear Sender The mail address nc...@xn... is not used anymore. If you want to contact me. Please use my new address. fir...@tr... Firstname: Niccolo Lastname: Camponovo Best Regards Niccolo Camponovo |
From: <nc...@xn...> - 2015-06-11 12:03:36
|
Dear Sender The mail address nc...@xn... is not used anymore. If you want to contact me. Please use my new address. fir...@tr... Firstname: Niccolo Lastname: Camponovo Best Regards Niccolo Camponovo |
From: Karl O. P. <ko...@me...> - 2015-06-10 18:24:23
|
On Wed, 10 Jun 2015 13:18:49 -0400 Alex Regan <mys...@gm...> wrote: > Hi Karl, > > Looks like as of postfix 2.1 there is an "instance" > > variable passed to the policy daemon that could be used > > to keep from adding multiple header lines. It's not > > clear how this would work and it's not implemented > > in sqlgrey. > > > > Something for somebody's todo list. > > Do you think sqlgrey is still the best option for doing greylisting > with postfix, or are is there something else we should be looking it? > > I originally thought policyd was an alternative, but it looks to be > more of a front-end or management system that just uses apps like > sqlgrey. > I don't have an informed option, not really knowing what else is out there. My guess is that if you have something working it's not really worth the time spent to switch. I like sqlgrey because it works with Postgres. Not only do I think Postgres technically superior to MySQL but MySQL, in my opinion, is not truly Open Source. The MySQL documentation (and as far as I can tell the MariaDB documentation) is _not_ open source. A database is no good without documentation, which makes forking a db product with no documentation a huge problem. It took MariaDB _years_ to get decent documentation. (And near as I can tell they still don't have a document for each release, making it hard to tell just how the version you happen to be running actually works.) If it can't be forked it's not open source. Karl <ko...@me...> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein |
From: Alex R. <mys...@gm...> - 2015-06-10 17:18:57
|
Hi Karl, >> I'm not doubting what you're saying, but here's a thread that seems >> to indicate it's the expected behavior: > > Looks like what I'm saying is wrong. The policy > daemon is called for each destination address. > See the postfix SMTPD_POLICY_README. > >> Here's another one from Lionel discussing: >> >> http://sourceforge.net/p/sqlgrey/mailman/sqlgrey-users/thread/42F...@bo.../ >> >> Could that be the solution here as well? > > "That" being rcpt_awl? Dunno. > > Looks like as of postfix 2.1 there is an "instance" > variable passed to the policy daemon that could be used > to keep from adding multiple header lines. It's not > clear how this would work and it's not implemented > in sqlgrey. > > Something for somebody's todo list. Do you think sqlgrey is still the best option for doing greylisting with postfix, or are is there something else we should be looking it? I originally thought policyd was an alternative, but it looks to be more of a front-end or management system that just uses apps like sqlgrey. >> I'm going to have to use postfix to strip them because I believe it's >> causing some mail to be rejected because the headers are too large. > > That sounds like a sensible approach. > > Since the policy check is smtpd you ought to be able > to use header_checks = pcre:/etc/postfix/header_checks > with file content of: > > /^X-Greylist: whitelisted by SQLgrey/ IGNORE > > I'd bet there's an even more clever way to > "collapse" all the identical entries but > haven't investigated. Yes, that's exactly how I'm currently doing it. Thanks again, Alex |
From: <nc...@xn...> - 2015-06-10 12:02:38
|
Dear Sender The mail address nc...@xn... is not used anymore. If you want to contact me. Please use my new address. fir...@tr... Firstname: Niccolo Lastname: Camponovo Best Regards Niccolo Camponovo |
From: Karl O. P. <ko...@me...> - 2015-06-10 02:35:41
|
On Tue, 09 Jun 2015 18:18:29 -0400 Alex Regan < > >> This is on postfix-2.10. > >> > >>> Whitelisting via sqlgrey is the wong approach. > >> > >> It looks like this was auto-whitelisted, because it has seen this > >> IP/email combination previously, no? > > > > Then it must be that the email is exiting postfix and > > passing through amavis and being re-injected back > > into postfix. You'll need to make sure that amavis > > is either on a trusted network (127.0.0.1) or > > uses lmtp not smtp or has some other way of getting the mail back > > into postfix that does not get greylisted. > > All of the networks involved are on the amavis "TRUSTED" or in > @mynetworks. > > I'm not doubting what you're saying, but here's a thread that seems > to indicate it's the expected behavior: Looks like what I'm saying is wrong. The policy daemon is called for each destination address. See the postfix SMTPD_POLICY_README. > Here's another one from Lionel discussing: > > http://sourceforge.net/p/sqlgrey/mailman/sqlgrey-users/thread/42F...@bo.../ > > Could that be the solution here as well? "That" being rcpt_awl? Dunno. Looks like as of postfix 2.1 there is an "instance" variable passed to the policy daemon that could be used to keep from adding multiple header lines. It's not clear how this would work and it's not implemented in sqlgrey. Something for somebody's todo list. > > I'm going to have to use postfix to strip them because I believe it's > causing some mail to be rejected because the headers are too large. That sounds like a sensible approach. Since the policy check is smtpd you ought to be able to use header_checks = pcre:/etc/postfix/header_checks with file content of: /^X-Greylist: whitelisted by SQLgrey/ IGNORE I'd bet there's an even more clever way to "collapse" all the identical entries but haven't investigated. Regards, Karl <ko...@me...> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein |
From: Karl O. P. <ko...@me...> - 2015-06-09 22:54:25
|
On Tue, 09 Jun 2015 18:18:29 -0400 Alex Regan <mys...@gm...> wrote > >> The smtpd_relay_restrictions is as follows: > >> > >> smtpd_relay_restrictions = permit_mynetworks, > >> permit_sasl_authenticated, defer_unauth_destination > > > > I greylist here too. Keeps more spam out. > > Okay, interesting. I'll try that too. On reflection, no, this is not a good idea in the general case. You need to be careful with this and if you're not using it now I'd be leery about adding it. Karl <ko...@me...> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein |
From: Alex R. <mys...@gm...> - 2015-06-09 22:18:39
|
Hi, >> The smtpd_relay_restrictions is as follows: >> >> smtpd_relay_restrictions = permit_mynetworks, >> permit_sasl_authenticated, defer_unauth_destination > > I greylist here too. Keeps more spam out. Okay, interesting. I'll try that too. >> This is on postfix-2.10. >> >>> Whitelisting via sqlgrey is the wong approach. >> >> It looks like this was auto-whitelisted, because it has seen this >> IP/email combination previously, no? > > Then it must be that the email is exiting postfix and > passing through amavis and being re-injected back > into postfix. You'll need to make sure that amavis > is either on a trusted network (127.0.0.1) or > uses lmtp not smtp or has some other way of getting the mail back > into postfix that does not get greylisted. All of the networks involved are on the amavis "TRUSTED" or in @mynetworks. I'm not doubting what you're saying, but here's a thread that seems to indicate it's the expected behavior: http://lists.policyd.org/pipermail/users_lists.policyd.org/2007-April/001426.html Here's another one from Lionel discussing: http://sourceforge.net/p/sqlgrey/mailman/sqlgrey-users/thread/42F...@bo.../ Could that be the solution here as well? I'm going to have to use postfix to strip them because I believe it's causing some mail to be rejected because the headers are too large. Thanks again, Alex |
From: Karl O. P. <ko...@me...> - 2015-06-09 19:47:22
|
On Tue, 09 Jun 2015 10:49:32 -0400 Alex Regan <mys...@gm...> wrote: > Hi, > > >>>> X-Greylist: whitelisted by SQLgrey-1.8.0 > >>> > >>> Is this inbound, outbound, or relayed mail? > >> > >> This is from the headers on the destination system. It is received > >> by our mail relay, where the header is added, then sent to the > >> destination system where the user reads the mail. > > > > You shouldn't be relaying except from trusted systems, > > so your smtpd_relay_restrictions should include > > something like "permit_mynetworks", in addition > > to your check_policy_service that runs sqlgrey. > > Then relayed mail won't go through sqlgrey. > > (Use smtpd_recipient_restrictions on older > > versions of postfix.) > > The check_policy_service is in smtpd_recipient_restrictions. Is that > not correct? Yes, that's right. > > The smtpd_relay_restrictions is as follows: > > smtpd_relay_restrictions = permit_mynetworks, > permit_sasl_authenticated, defer_unauth_destination I greylist here too. Keeps more spam out. > > This is on postfix-2.10. > > > Whitelisting via sqlgrey is the wong approach. > > It looks like this was auto-whitelisted, because it has seen this > IP/email combination previously, no? Then it must be that the email is exiting postfix and passing through amavis and being re-injected back into postfix. You'll need to make sure that amavis is either on a trusted network (127.0.0.1) or uses lmtp not smtp or has some other way of getting the mail back into postfix that does not get greylisted. I'm not really focusing here so I could be off on the wrong track. But this is what it looks like offhand. (And I don't remember anything about amavis any more.) Karl <ko...@me...> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein |
From: Alex R. <mys...@gm...> - 2015-06-09 14:49:40
|
Hi, >>>> X-Greylist: whitelisted by SQLgrey-1.8.0 >>> >>> Is this inbound, outbound, or relayed mail? >> >> This is from the headers on the destination system. It is received by >> our mail relay, where the header is added, then sent to the >> destination system where the user reads the mail. > > You shouldn't be relaying except from trusted systems, > so your smtpd_relay_restrictions should include > something like "permit_mynetworks", in addition > to your check_policy_service that runs sqlgrey. > Then relayed mail won't go through sqlgrey. > (Use smtpd_recipient_restrictions on older > versions of postfix.) The check_policy_service is in smtpd_recipient_restrictions. Is that not correct? The smtpd_relay_restrictions is as follows: smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination This is on postfix-2.10. > Whitelisting via sqlgrey is the wong approach. It looks like this was auto-whitelisted, because it has seen this IP/email combination previously, no? > But it looks to me like you've got something > else wrong since I wouldn't think, without > having really investigated, that any piece of > mail should go through sqlgrey more than once. > So you should only get one header no matter what. Yes, I agree. It would be great to figure out how to configure it so trusted networks weren't greylisted. Sure appreciate any ideas you might have. Thanks, Alex |
From: Karl O. P. <ko...@me...> - 2015-06-09 14:23:48
|
On Tue, 09 Jun 2015 09:51:53 -0400 Alex Regan <mys...@gm...> wrote: > Hi Karl, > > >> It seems when a message is sent to multiple recipients, multiple > >> X-Greylist headers are added. When there are dozens of these, it > >> appears some systems are rejecting it due to the header being too > >> large. > >> > >> How can I configure it to only include one copy of the X-Greylist > >> header? > >> > >> I'm using postfix. Is it possible to strip off all but one copy of > >> the header? > >> > >> X-Greylist: whitelisted by SQLgrey-1.8.0 > > > > Is this inbound, outbound, or relayed mail? > > This is from the headers on the destination system. It is received by > our mail relay, where the header is added, then sent to the > destination system where the user reads the mail. You shouldn't be relaying except from trusted systems, so your smtpd_relay_restrictions should include something like "permit_mynetworks", in addition to your check_policy_service that runs sqlgrey. Then relayed mail won't go through sqlgrey. (Use smtpd_recipient_restrictions on older versions of postfix.) Whitelisting via sqlgrey is the wong approach. But it looks to me like you've got something else wrong since I wouldn't think, without having really investigated, that any piece of mail should go through sqlgrey more than once. So you should only get one header no matter what. Karl <ko...@me...> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein |
From: Alex R. <mys...@gm...> - 2015-06-09 13:52:01
|
Hi Karl, >> It seems when a message is sent to multiple recipients, multiple >> X-Greylist headers are added. When there are dozens of these, it >> appears some systems are rejecting it due to the header being too >> large. >> >> How can I configure it to only include one copy of the X-Greylist >> header? >> >> I'm using postfix. Is it possible to strip off all but one copy of >> the header? >> >> X-Greylist: whitelisted by SQLgrey-1.8.0 > > Is this inbound, outbound, or relayed mail? This is from the headers on the destination system. It is received by our mail relay, where the header is added, then sent to the destination system where the user reads the mail. The mail is apparently sent to dozens of recipients via a mail expander at the corporate office to recipients on this destination system because there is no indication in the email that it was sent to dozens of recipients. Apparently the relay is adding an X-Greylist header for each of the recipients in the email. I've included a copy of the email here: http://pastebin.com/1reiWEM3 Any ideas would be greatly appreciated. Thanks, Alex |
From: Karl O. P. <ko...@me...> - 2015-06-09 13:29:50
|
On Mon, 8 Jun 2015 17:12:22 -0400 Alex <mys...@gm...> wrote: > Hi, > > It seems when a message is sent to multiple recipients, multiple > X-Greylist headers are added. When there are dozens of these, it > appears some systems are rejecting it due to the header being too > large. > > How can I configure it to only include one copy of the X-Greylist > header? > > I'm using postfix. Is it possible to strip off all but one copy of > the header? > > X-Greylist: whitelisted by SQLgrey-1.8.0 Is this inbound, outbound, or relayed mail? Karl <ko...@me...> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein |