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 m
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
> Am I right?
Yes Wesley you are right. So i don't like DMARC (with SPF).
Sincerely,
--
^고맙습니다 _地平天成_ 감사합니다_^))//
> 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 positiv
Richard Damon wrote:
The
side effect of it is that addresses on such a domain really shouldn't be
used on mailing lists,
Thanks for pointing out this. I never knew it.
Now I changed my mail to fastmail account, which I owned it for many
years. I just don't like its mobile app, it's just a
Richard Damon wrote:
That is a question to ask them. Basically the strict DMARC policy is
designed for transactional email, where spoofing is a real danger. The
side effect of it is that addresses on such a domain really shouldn't be
used on mailing lists, or any other 3rd party senders not speci
On 11/21/19 11:21 PM, Wesley Peng wrote:
> Richard Damon wrote:
>> The typical options for the mailing list are
>>
>> 1) Just not allow people from such domains to post to the list (the
>> reject option you mention)
>>
>> 2) Rewrite the from address from people from such a domain to be from
>> the
Richard Damon wrote:
The typical options for the mailing list are
1) Just not allow people from such domains to post to the list (the
reject option you mention)
2) Rewrite the from address from people from such a domain to be from
the domain of the list (often the list address). This is arguabl
On 11/21/19 9:45 PM, Wesley Peng wrote:
> Greetings,
>
> When mail is relayed through mailing list, why the DMARC policy is
> possible to reject?
>
> For example, I sent mail from x...@mail.ru to y...@googlegroups.com
>
> Since mail.ru has the strictest DMARC policy, the recepients may
> choose to
Greetings,
When mail is relayed through mailing list, why the DMARC policy is
possible to reject?
For example, I sent mail from x...@mail.ru to y...@googlegroups.com
Since mail.ru has the strictest DMARC policy, the recepients may choose
to reject this mail which is relayed by googlegroups,
One more thing...
On Thu, 21 Nov 2019, Fred Morris wrote:
Since I run my own mail servers I'm probably not a good person to ask. I
don't find it particularly hard work. I set account limits, provide some
tools and also disincentives to make safety and privacy the easier course and
at the end o
On Fri, 22 Nov 2019, Merrick wrote:
On Fri, Nov 22, 2019, at 2:25 AM, Fred Morris wrote:
I'll hazard that the reputation of particular domains whether they're
TLDs or PseudoTLDs, registrars, or particular constellations of network
infrastructure, is outside the scope of this list. There are li
On Fri, Nov 22, 2019, at 2:25 AM, Fred Morris wrote:
>
>
>
> I'll hazard that the reputation of particular domains whether they're
> TLDs or PseudoTLDs, registrars, or particular constellations of network
> infrastructure, is outside the scope of this list. There are lists for the
> discuss
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 a
*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 the
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 ehl
Hi Wesley, see my post on risk vs reward for background.
I left this out because it was getting too long, but it appears the big
ESPs (Microsoft and Google for example) are curating. In other words, they
are probably are working very very hard to avoid the perception of being
cesspools of spam
It's about risk versus reward.
Never mind email. Let's say I'm an employer. They might all be perfectly
fine people in Walmart land, but why do people on the network I control
need to visit their web site? Is there any reason? Do we do business with
them? I might not go to any great lengths to
> On Nov 21, 2019, at 11:18 AM, Fazzina, Angelo
> wrote:
>
> Thank you for clearing that up.
> Since this client I have is having trouble and I am trying to determine if
> the clients IP is the one generating these log entries do you think these to
> settings will give me more info in the l
Thank you, I need to learn to Google better, my bad.
https://groups.google.com/forum/#!topic/mailing.postfix.users/mpeVD0d56zM
Wietse, seems to have answered this question in the past.
I am going to just do more simultaneous testing with client like you said and
sniff the wire.
Thanks everyone
> On Nov 21, 2019, at 6:50 AM, Matus UHLAR - fantomas wrote:
>
> Seems I found it:
>
> http://postfix.1071664.n5.nabble.com/Mydestination-and-transport-maps-td85665.html
>
> so for every subdomain of .example.com, override must be done in
> transport_maps:
>
> proxy.example.com local:
Yes
On 11/21/2019 10:18 AM, Fazzina, Angelo wrote:
Thank you for clearing that up.
Since this client I have is having trouble and I am trying to determine if the
clients IP is the one generating these log entries do you think these to
settings will give me more info in the logs for smtpd related da
Thank you for clearing that up.
Since this client I have is having trouble and I am trying to determine if the
clients IP is the one generating these log entries do you think these to
settings will give me more info in the logs for smtpd related data ?
debug_peer_level (x)
and
debug_peer_lis
> On Nov 21, 2019, at 10:54 AM, Fazzina, Angelo
> wrote:
>
> ov 21 09:00:15 mail5 postfix/smtpd[31265]: lost connection after CONNECT from
> unknown[unknown]
> Nov 21 09:00:15 mail5 postfix/smtpd[31265]: disconnect from unknown[unknown]
The connection was lost right after it was established, b
Dnia 21.11.2019 o godz. 15:54:04 Fazzina, Angelo pisze:
>
> Nov 21 09:00:15 mail5 postfix/smtpd[31265]: lost connection after CONNECT
> from unknown[unknown]
> Nov 21 09:00:15 mail5 postfix/smtpd[31265]: disconnect from unknown[unknown]
CONNECT indicates that something tried to connect to your S
Hi, i read this
http://www.postfix.org/OVERVIEW.html
which got me to this
http://www.postfix.org/smtpd.8.html
Then i got lost...
I am trying to diagnose the details of what smtpd does when a client
tries to connect to my postfix server, based on these 2 lines
Nov 21 09:00:15 mail5 postfix/smtpd[
On Thu, 21 Nov 2019 at 14:53, Chris Green wrote:
> On Thu, Nov 21, 2019 at 01:00:24PM +, Dominic Raferd wrote:
> >I use a VM in a different country with the same priority MX so that we
> >should have effectively zero overall downtime. (The exceptions are
> when
> >I propagate a br
On Thu, Nov 21, 2019 at 01:04:45PM +, Gregory Heytings wrote:
>
> >
> > Sending systems will automatically back off and retry at intervals (I
> > have seen this happen when I have upgraded my home server in the past)
> > so will a secondary/backup MX actually help at all?
> >
>
> It's up to
On Thu, Nov 21, 2019 at 01:00:24PM +, Dominic Raferd wrote:
>I use a VM in a different country with the same priority MX so that we
>should have effectively zero overall downtime. (The exceptions are when
>I propagate a broken configuration from one MTA to the other - oops.)
>Th
On 11/21/19 2:57 AM, Jaroslaw Rafa wrote:
Same as blocking an entire netblock or ISP because there are spammers within
this netblock or using this ISP (but there are "good" senders there as
well). Which is something a lot of email providers do, nevertheless.
Given that ab...@example.com yields
Sending systems will automatically back off and retry at intervals (I
have seen this happen when I have upgraded my home server in the past)
so will a secondary/backup MX actually help at all?
It's up to you to decide what your priorities are. It's true that sending
systems automatical
On Thu, 21 Nov 2019 at 12:05, Chris Green wrote:
> I run postfix on an 'always on' machine at home and have the MX record
> for my domain pointing at this machine.
>
> Obviously there are occasional downtimes, for example this morning we
> had a 3 hour power failure and I also need to upgrade the
I run postfix on an 'always on' machine at home and have the MX record
for my domain pointing at this machine.
Obviously there are occasional downtimes, for example this morning we
had a 3 hour power failure and I also need to upgrade the machine
occasionally.
Now I could of course overcome some
On 21.11.19 12:16, Matus UHLAR - fantomas wrote:
I run "proxy.example.com" server with ".example.com" in transport_maps, to
direct all example.com subdomains to internal server
my $mydestination contains proxy.example.com and some other names, however
all domain to proxy.example.com is directed
Hello,
I run "proxy.example.com" server with ".example.com" in transport_maps, to
direct all example.com subdomains to internal server
my $mydestination contains proxy.example.com and some other names, however
all domain to proxy.example.com is directed to internal servers.
What should I to to
Dnia 21.11.2019 o godz. 16:01:04 Wesley Peng pisze:
>
> 1. gmail totally can't be registered from PC, only mobile client
> (gmail, outlook etc) can sign up a new username. they require mobile
> verification in the process.
What? Just a few weeks ago I made four new Gmail accounts from my home PC
Dnia 21.11.2019 o godz. 07:51:20 Reto pisze:
>
> Blocking based on geolocation / domain endings is something I seriously
> despise.
> Email is decentralized for a reason, blocking huge portions of it due to
> spammers abusing a few *is* evil in my opinion.
Same as blocking an entire netblock or
Am 21.11.2019 um 09:01 schrieb Wesley Peng:
Hello
I saw a trend that, every ESP has taken hard work on antispam policy.
For example, from my test cases:
1. gmail totally can't be registered from PC, only mobile client (gmail,
outlook etc) can sign up a new username. they require mobile
verifi
Wesley Peng writes:
> Hello
>
> I saw a trend that, every ESP has taken hard work on antispam policy.
> For example, from my test cases:
>
> 1. gmail totally can't be registered from PC, only mobile client (gmail,
> outlook etc) can sign up a new username. they require mobile
> verification in
Hello
I saw a trend that, every ESP has taken hard work on antispam policy.
For example, from my test cases:
1. gmail totally can't be registered from PC, only mobile client (gmail,
outlook etc) can sign up a new username. they require mobile
verification in the process.
2. yahoo totally can
40 matches
Mail list logo
