7 \u0441\u0435\u043d\u0442\u044f\u0431\u0440\u044f 2016�\u0433. 22:56:42 CEST, "Mauricio Teixeira mauricio.teixeira@... [milter-greylist]" <milter-greylist@yahoogroups.com> \u043f\u0438\u0448\u0435\u0442:
>I agree with you guys that the sender should be doing the right thing,
>but
>they're not, and this is only one example of a dozen I have. My only
>workaround so far has been to add them to the broken MTA white list,
>but
>that's a horrible solution. I would like something to accept those
>cases,
>specially because some of them are business related, and my customers
>are
>not happy about having their email being delayed. Thank you.
>
>Mauricio Teixeira
>(sent from mobile, sorry for my brevity)
>
>On Sep 7, 2016 17:37, "Bill Levering yidbill@...
>[milter-greylist]" <
>milter-greylist@yahoogroups.com> wrote:
>
>>
>>
>> I also agree, this is the proper result.
>>
>> Legit institutions that send mail should have their act together.
>> (properly configured dns)
>>
>> Also, if someone is running a mail server off a residential line,
>then
>> they should be ashamed and or not trusted to begin with.
>>
>> Bill
>>
>> > On Sep 7, 2016, at 12:32 PM, Marcus Schopen
>> lists-yahoogroups@... [milter-greylist] <
>> milter-greylist@yahoogroups.com> wrote:
>> >
>> > Hi,
>> >
>> > On 2016-09-06 20:41, Mauricio Teixeira mauricio.teixeira@...
>> > [milter-greylist] wrote:
>> >>>>> # Greylisting Hosts Without Reverse DNS
>> >>>>> racl greylist domain
>> >>>>> /^\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\]$/ delay 1h
>> >>>
>> >>> In my rulesets this adds a big score malus to delay longer in
>> >>> greylists, and by the time this mail might be accepted sender may
>be
>> >>> already in DNSBL.
>> >>
>> >> I find it interesting that this topic just happened while I was
>> >> scratching my head on a similar situation.
>> >>
>> >> I've seen cases where the reverse does not match the forward, and
>> >> milter-greylist is filtering them anyway. Example:
>> >>
>> >> milter-reject: RCPT from unknown[203.235.210.192]: 451 4.7.1
>> >> Greylisting in action, please come back in 00:13:18; bad reverse
>DNS;
>> >> from=<blah@...> to=<blah@...> proto=ESMTP
>> >> helo=<mymail.skcc.com [1]>
>> >>
>> >> This is my rule:
>> >> racl greylist domain
>> >> /^\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\]$/ delay 120m
>msg
>> >> "Greylisting in action, please come back in %R; bad reverse DNS"
>> >>
>> >> 203.235.210.192 resolves to mymail.skcc.com [1]
>> >>
>> >> but
>> >> mymail.skcc.com [1] resolves to 203.235.210.190
>> >>
>> >> So it seems like milter-greylist is getting confused, and thinks
>the
>> >> fact that the reverse does not match the forward means there is no
>> >> reverse.
>> >>
>> >> How can I tell milter-greylist to just accept those cases when
>there
>> >> is a reverse, even if it doesn't match the forward?
>> >
>> > Am Dienstag, den 06.09.2016, 15:41 -0300 schrieb Mauricio Teixeira
>> > mauricio.teixeira@... [milter-greylist]:
>> >>
>> >> How can I tell milter-greylist to just accept those cases when
>there
>> >> is a reverse, even if it doesn't match the forward?
>> >
>> >
>> > I'm not sure if there is an RFC, which says forward DNS and rDNS
>must
>> > match, but it's common practise for a well maintained sending host
>that
>> > a lookup should be forward confirmed in result. If not you might
>tagged
>> > as spam. Milter-greylist's result for your example IP
>203.235.210.192 is
>> > right to my mind, because 203.235.210.192 -> mymail.skcc.com ->
>> > 203.235.210.190 which doesn't match, even though there is a rDNS.
>> >
>> > Ciao!
>> >
>> >
>> >
>> > ------------------------------------
>> > Posted by: Marcus Schopen <lists-yahoogroups@...>
>> > ------------------------------------
>> >
>> >
>> > ------------------------------------
>> >
>> > Yahoo Groups Links
>> >
>> >
>> >
>>
>>
Well then, you have to somehow maintain a whitelist of counteragents you trust.
I thought of having milter-greylist (or some other milter) sit on the outgoing mail and auto-whitelist in advance mail from systems to which my users send. This would help both against lags while sending to smtp-verification systems (when they try to post back and so verify the sender exists) and when getting back expected replies.
So far this did not go anywhere (lack of time) but sounds like a neat idea ;)
The best we did until now is a cvs-based management of relay configs so static whitelist of "friend" domains is kept.
Similar things might be done dynamically with milter-greylist curl (http, ldap) interface and some other system to manage the friends (e.g. a small web-php script for your users to register who they talk to and want greylists skipped).
Jim
--
Typos courtesy of K-9 Mail on my Samsung Android