Plain old greylisting can yield many false positives, but recent
implementations of milter-greylist for example will not greylist
messages that validates SPF. It helps *a lot*.
The question is: does it only help "a lot", or is the result "zero false
positives"? I personally don't
On 2019-11-22 08:23, Gregory Heytings wrote:
And there are various techniques (for example connection rate limits,
response delays, greylisting) that prevent you from "accepting all
mail" and that have zero false positives.
As for greylisting, it's no more true now.
Some large and popular
And there are various techniques (for example connection rate limits,
response delays, greylisting) that prevent you from "accepting all
mail" and that have zero false positives.
As for greylisting, it's no more true now.
Some large and popular mail sending services started some time ago
> On 21 Nov 2019, at 17:06, Jaroslaw Rafa wrote:
>
> Dnia 21.11.2019 o godz. 23:50:15 Gregory Heytings pisze:
>> And there are various techniques (for example connection
>> rate limits, response delays, greylisting) that prevent you from
>> "accepting all mail" and that have zero false
Dnia 21.11.2019 o godz. 23:50:15 Gregory Heytings pisze:
> And there are various techniques (for example connection
> rate limits, response delays, greylisting) that prevent you from
> "accepting all mail" and that have zero false positives.
As for greylisting, it's no more true now.
Some large
*Everything* short of accepting all mail regardless has false positives.
Rejecting emails for non-existing users, or for domains of which your are
neither the final destination nor a relay, or coming from non-existing
domains, are filtering schemes that have zero false positives. And
On 13 Nov 2019, at 02:30, Matus UHLAR - fantomas wrote:
> On 12.11.19 17:01, Viktor Dukhovni wrote:
>> The correct way to verify that would be to resolve the EHLO name to
>> an address, NOT to resolve the address to a name. This would then
>> find no anomalies with:
>>
>> Received: from
> On Nov 13, 2019, at 4:30 AM, Matus UHLAR - fantomas wrote:
>
> On 12.11.19 17:01, Viktor Dukhovni wrote:
>> The correct way to verify that would be to resolve the EHLO name to
>> an address, NOT to resolve the address to a name. This would then
>> find no anomalies with:
>>
>> Received:
[Sorry for late, Ralph.]
Ralph Seichter writes:
> * 황병희:
>
>> i did not setup SPF. Instead i think User-Agent/X-Mailer are
>> important.
>
> The contents of these headers are easily faked, so relying on them is
> questionable to me. Also, you will encounter User-Agent headers
> generated by
For the record, it is NOT an RFC violation for the EHLO name to
differ from the name in the PTR record of the connecting IP.
On Nov 12, 2019, at 3:52 PM, Bill Cole
wrote:
Right and as was stated & I affirmed: it is explicit in RFC5321 S.4.1.4:
An SMTP server MAY verify that the domain
> On Nov 12, 2019, at 3:52 PM, Bill Cole
> wrote:
>
>> For the record, it is NOT an RFC violation for the EHLO name to
>> differ from the name in the PTR record of the connecting IP.
>
> Right and as was stated & I affirmed: it is explicit in RFC5321 S.4.1.4:
>
> An SMTP server MAY verify
Matus UHLAR - fantomas skrev den 2019-11-12 12:09:
On 11.11.19 09:29, m3047 wrote:
I (mostly) concur with what Bill Cole says (maybe I'd quibble with the
"2nd clause" part).
Here's a shopworn blade which is in my list of things to rewrite in
Python one day:
On 12 Nov 2019, at 14:26, Viktor Dukhovni wrote:
On Nov 11, 2019, at 11:09 AM, Bill Cole
wrote:
mail.namase.de is the HELO (EHLO) name. You must not reject mail
when helo
name differs from DNS name (RFC violation).
True.
For the record, it is NOT an RFC violation for the EHLO name to
> On Nov 11, 2019, at 11:09 AM, Bill Cole
> wrote:
>
>> mail.namase.de is the HELO (EHLO) name. You must not reject mail when helo
>> name differs from DNS name (RFC violation).
>
> True.
For the record, it is NOT an RFC violation for the EHLO name to
differ from the name in the PTR record
* 황병희:
> i did not setup SPF. Instead i think User-Agent/X-Mailer are
> important.
The contents of these headers are easily faked, so relying on them is
questionable to me. Also, you will encounter User-Agent headers
generated by various libraries, like Java SMTP implementations. Finally,
what
> I am a big fan of rigid adherence to rDNS & SPF rules, doing so,
> [...]
Well i don't know what rules are right things. Still i did not setup
SPF. Instead i think User-Agent/X-Mailer are important. In most case
linux softwares[1] have good manners in email world.
Sincerely,
[1] Mutt, ELM,
On 11/12/2019 6:33 AM, Dusan Obradovic wrote:
On Nov 11, 2019, at 2:27 PM, ratatouille wrote:
Hello all!
Received: from mail.namase.de (s1.bomberg.city [62.173.139.77])
I would like to reject incoming email if dns- and rdns-entries differ.
Does this make sense and how could I achieve this?
> On Nov 11, 2019, at 2:27 PM, ratatouille wrote:
>
> Hello all!
>
> Received: from mail.namase.de (s1.bomberg.city [62.173.139.77])
>
> I would like to reject incoming email if dns- and rdns-entries differ.
> Does this make sense and how could I achieve this?
>
> Kind regards
>
>
On 11.11.19 09:29, m3047 wrote:
I (mostly) concur with what Bill Cole says (maybe I'd quibble with the
"2nd clause" part).
Here's a shopworn blade which is in my list of things to rewrite in
Python one day:
http://athena.m3047.net/pub/perl/mail-processing/realmailer.pl.txt
You call it
I (mostly) concur with what Bill Cole says (maybe I'd quibble with the
"2nd clause" part).
Here's a shopworn blade which is in my list of things to rewrite in Python
one day:
http://athena.m3047.net/pub/perl/mail-processing/realmailer.pl.txt
You call it from e.g. procmail, or in other
On 11 Nov 2019, at 8:47, Matus UHLAR - fantomas wrote:
On 11.11.19 14:27, ratatouille wrote:
Received: from mail.namase.de (s1.bomberg.city [62.173.139.77])
I would like to reject incoming email if dns- and rdns-entries
differ.
Does this make sense and how could I achieve this?
they do
Hello!
I believe you can achieve that by this restriction from
"smtpd_client_restrictions" that can be included into the main.cf file:
*reject_unknown_client_hostname* /(with Postfix < 2.3://
// reject_unknown_client)//
// Reject the request when 1) the client IP
On 11.11.19 14:27, ratatouille wrote:
Received: from mail.namase.de (s1.bomberg.city [62.173.139.77])
I would like to reject incoming email if dns- and rdns-entries differ.
Does this make sense and how could I achieve this?
they do not differ above. The IP 62.173.139.77, rDNS is
Hello all!
Received: from mail.namase.de (s1.bomberg.city [62.173.139.77])
I would like to reject incoming email if dns- and rdns-entries differ.
Does this make sense and how could I achieve this?
Kind regards
Andreas
24 matches
Mail list logo
