Re: rejecting client=unknown[ip.ad.dr.ess]
LuKreme a écrit : On 22-Jun-2009, at 18:29, mouss wrote: Is there anyway to, if not outright reject anyone whose DNS shows up as unknown to at least tempfail them with a Ooops, your DNS is not resolving, try back later or something? if you insist, you could use one of http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname but use at your own risks. In particular, reject_unknown_client_hostname (previously: reject_unknown_client) _will_ block or delay legitimate mail. Will it block or delay it? Can I set the error code to a tempfail instead of a outright rejection. Blocking legitimate mail that fails dns checks is one thing, rejecting it outright is another thing altogether. Seems at least half the spam that gets by zen shows up as client=unknown how much is half of what... I don't understand the question. sorry. I meant that, the way it is stated, at least half of spam is a meaningless measure. for example, if you use other checks, numbers will change. yes, it is hard to come up with meaningful numbers. I do a multiple levels stats: ratio of junk blocked by major checks, then among what slips, ratio blocked by other checks, and then among what slips, ratio of junk detected by SA, ... etc. I stopped doing global measures.
Re: rejecting client=unknown[ip.ad.dr.ess]
On 23-Jun-2009, at 06:31, Jan P. Kessler wrote: Another option is to use selective greylisting on unknown clients: MAIN.CF smtpd_recipient:_restrictions = permit_mynetworks, ...others..., check_client_access = pcre:/etc/postfix/client_check /etc/postfix/client_check: /^unknown$/ check_policy_service inet:127.0.0.1:10031 Oh yes, that works. In fact, I thought I already had that in my check_client_fqdn.pcre file, I guess I overlooked it. -- BILL: I can't get behind the Gods, who are more vengeful, angry, an dangerous if you don't believe in them! HENRY: Why can't all these God just get along? I mean, they're omni- potent and omnipresent, what's the problem?
Re: rejecting client=unknown[ip.ad.dr.ess]
On Wed, Jun 24, 2009 at 10:15:39PM -0600, LuKreme wrote: On 23-Jun-2009, at 06:31, Jan P. Kessler wrote: Another option is to use selective greylisting on unknown clients: MAIN.CF smtpd_recipient:_restrictions = permit_mynetworks, ...others..., check_client_access = pcre:/etc/postfix/client_check No = sign between check_client_access and the table name. /etc/postfix/client_check: /^unknown$/ check_policy_service inet:127.0.0.1:10031 Oh yes, that works. In fact, I thought I already had that in my check_client_fqdn.pcre file, I guess I overlooked it. It is somewhat fragile, because it fails to distinguish between transient and permanent lookup errors. The policy service needs to be careful to not reject outright (greylisting is perhaps safe, but one needs to understand the limitations of this approach). -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: rejecting client=unknown[ip.ad.dr.ess]
On 22-Jun-2009, at 18:29, mouss wrote: Is there anyway to, if not outright reject anyone whose DNS shows up as unknown to at least tempfail them with a Ooops, your DNS is not resolving, try back later or something? if you insist, you could use one of http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname but use at your own risks. In particular, reject_unknown_client_hostname (previously: reject_unknown_client) _will_ block or delay legitimate mail. Will it block or delay it? Can I set the error code to a tempfail instead of a outright rejection. Blocking legitimate mail that fails dns checks is one thing, rejecting it outright is another thing altogether. Seems at least half the spam that gets by zen shows up as client=unknown how much is half of what... I don't understand the question. -- The quality of our thoughts and ideas can only be as good as the quality of our language.
Re: rejecting client=unknown[ip.ad.dr.ess]
LuKreme schrieb: On 22-Jun-2009, at 18:29, mouss wrote: Is there anyway to, if not outright reject anyone whose DNS shows up as unknown to at least tempfail them with a Ooops, your DNS is not resolving, try back later or something? if you insist, you could use one of http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname but use at your own risks. In particular, reject_unknown_client_hostname (previously: reject_unknown_client) _will_ block or delay legitimate mail. Will it block or delay it? Can I set the error code to a tempfail instead of a outright rejection. Blocking legitimate mail that fails dns checks is one thing, rejecting it outright is another thing altogether. If you took a second to read the supplied link, you would have found http://www.postfix.org/postconf.5.html#unknown_client_reject_code Another option is to use selective greylisting on unknown clients: MAIN.CF smtpd_recipient:_restrictions = permit_mynetworks, ...others..., check_client_access = pcre:/etc/postfix/client_check /etc/postfix/client_check: /^unknown$/ check_policy_service inet:127.0.0.1:10031
Re: rejecting client=unknown[ip.ad.dr.ess]
LuKreme wrote, at 06/23/2009 02:58 AM: On 22-Jun-2009, at 18:29, mouss wrote: Is there anyway to, if not outright reject anyone whose DNS shows up as unknown to at least tempfail them with a Ooops, your DNS is not resolving, try back later or something? if you insist, you could use one of http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname but use at your own risks. In particular, reject_unknown_client_hostname (previously: reject_unknown_client) _will_ block or delay legitimate mail. Will it block or delay it? Can I set the error code to a tempfail instead of a outright rejection. Blocking legitimate mail that fails dns checks is one thing, rejecting it outright is another thing altogether. When using the default response code (450) the practical effect is that the sending MTA will continually try to resend the message and you will continually deny it until it gives up. Thus, it is blocked, at higher expense for both sides. The only *true* delay will occur when the sender fixes DNS or you relax your restriction, allowing the message to be delivered. You are correct that changing unknown_client_reject_code to 550 is not something that should be considered lightly.
rejecting client=unknown[ip.ad.dr.ess]
Received a message with the following received header: Received: from twitter.com (unknown [152.157.207.191]) by mail.covisp.net (Postfix) with ESMTP id 3D796118B753 for kr...@kreme.com; Mon, 22 Jun 2009 10:46:37 -0600 (MDT) It was a virus payload containing a zip file with a .exe inside it (made to look like a pdf). I got another nearly identical one claiming to be from hallmark ecards within a few minutes. postfix/smtpd[31572]: 94E84118B80D: client=unknown[152.157.207.191] postfix/cleanup[33547]: 94E84118B80D: message-id=20090622164644.94e84118b...@mail.covisp.net postfix/qmgr[1043]: 94E84118B80D: from=e-ca...@hallmark.com, size=684311, nrcpt=1 (queue active) postfix/local[33558]: 94E84118B80D: to=kr...@covisp.net, orig_to=kr...@kreme.com , relay=local, delay=70, delays=70/0/0/0.31, dsn=2.0.0, status=sent (delivered to command: /usr/local/bin/procmail -t -a $EXTENSION) postfix/qmgr[1043]: 94E84118B80D: removed postfix/smtpd[32918]: 3D796118B753: client=unknown[152.157.207.191] postfix/cleanup[33397]: 3D796118B753: message-id=20090622164638.3d796118b...@mail.covisp.net postfix/qmgr[1043]: 3D796118B753: from=invitati...@twitter.com, size=688383, nrcpt=1 (queue active) postfix/local[33558]: 3D796118B753: to=kr...@covisp.net, orig_to=kr...@kreme.com , relay=local, delay=65, delays=64/0.01/0/0.44, dsn=2.0.0, status=sent (delivered to command: /usr/local/bin/procmail -t -a $EXTENSION) postfix/qmgr[1043]: 3D796118B753: removed I know they aren't hitting the various unknown checks because they are claiming a valid looking name in the EHLO, but is there something I can do to drop these at the transaction phase? I searched my mailspool for all the IDs for client=unknown and then searched the maillog for those IDs grepping on the 'from=' line, printing them out and sorting them. I don't see anything in the maillogs for the last 31 days that is a legitimate email. Is there anyway to, if not outright reject anyone whose DNS shows up as unknown to at least tempfail them with a Ooops, your DNS is not resolving, try back later or something? Seems at least half the spam that gets by zen shows up as client=unknown -- Ah we're lonely, we're romantic / and the cider's laced with acid / and the Holy Spirit's crying, Where's the beef? / And the moon is swimming naked / and the summer night is fragrant / with a mighty expectation of relief
Re: rejecting client=unknown[ip.ad.dr.ess]
LuKreme a écrit : Received a message with the following received header: Received: from twitter.com (unknown [152.157.207.191]) by mail.covisp.net (Postfix) with ESMTP id 3D796118B753 for kr...@kreme.com; Mon, 22 Jun 2009 10:46:37 -0600 (MDT) It was a virus payload containing a zip file with a .exe inside it (made to look like a pdf). I got another nearly identical one claiming to be from hallmark ecards within a few minutes. postfix/smtpd[31572]: 94E84118B80D: client=unknown[152.157.207.191] postfix/cleanup[33547]: 94E84118B80D: message-id=20090622164644.94e84118b...@mail.covisp.net postfix/qmgr[1043]: 94E84118B80D: from=e-ca...@hallmark.com, size=684311, nrcpt=1 (queue active) postfix/local[33558]: 94E84118B80D: to=kr...@covisp.net, orig_to=kr...@kreme.com, relay=local, delay=70, delays=70/0/0/0.31, dsn=2.0.0, status=sent (delivered to command: /usr/local/bin/procmail -t -a $EXTENSION) postfix/qmgr[1043]: 94E84118B80D: removed postfix/smtpd[32918]: 3D796118B753: client=unknown[152.157.207.191] postfix/cleanup[33397]: 3D796118B753: message-id=20090622164638.3d796118b...@mail.covisp.net postfix/qmgr[1043]: 3D796118B753: from=invitati...@twitter.com, size=688383, nrcpt=1 (queue active) postfix/local[33558]: 3D796118B753: to=kr...@covisp.net, orig_to=kr...@kreme.com, relay=local, delay=65, delays=64/0.01/0/0.44, dsn=2.0.0, status=sent (delivered to command: /usr/local/bin/procmail -t -a $EXTENSION) postfix/qmgr[1043]: 3D796118B753: removed I know they aren't hitting the various unknown checks because they are claiming a valid looking name in the EHLO, but is there something I can do to drop these at the transaction phase? I searched my mailspool for all the IDs for client=unknown and then searched the maillog for those IDs grepping on the 'from=' line, printing them out and sorting them. I don't see anything in the maillogs for the last 31 days that is a legitimate email. you think so, but FPs come in when you don't wait for them... Is there anyway to, if not outright reject anyone whose DNS shows up as unknown to at least tempfail them with a Ooops, your DNS is not resolving, try back later or something? if you insist, you could use one of http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname but use at your own risks. In particular, reject_unknown_client_hostname (previously: reject_unknown_client) _will_ block or delay legitimate mail. Seems at least half the spam that gets by zen shows up as client=unknown how much is half of what...
