Dnia 23.09.2024 o godz. 09:21:52 Mark Delany via mailop pisze:
> > (Do you mean that the postal service is not globally addressable
> > or that it does not allow mortal participaton ?
>
> I think you know the answer to this. Can you create a postal address which is
> automatically recognized by e
Dnia 28.08.2024 o godz. 09:11:28 Colin Johnston via mailop pisze:
> Google does 2fa to phone or tablet so long as the device has WiFi regardless
> of sim
And how does it do this, if there's no Google account logged in?
--
Regards,
Jaroslaw Rafa
r...@rafa.eu.org
--
"In a million years, when
Dnia 27.08.2024 o godz. 22:35:41 Atro Tossavainen via mailop pisze:
>
> Is this the generic advice that all Android device users should take
> in order to ensure they will be able to continue to use the Google
> account which is essentially mandatory to have in order to use said
> device? If so, h
Dnia 27.08.2024 o godz. 17:54:05 Colin Johnston via mailop pisze:
> Have you tried an normal android phone without a sim as Google should send
> the 2fa to that as well as sms ?
How do you expect anybody/anything to send a SMS to a phone without a SIM
card, which means no phone number and no cell
Dnia 27.08.2024 o godz. 15:26:44 Viktor Dukhovni via mailop pisze:
>
> Welcome to two-factor denial of service. I try to resist signing up for
> such baked-in disasters as much as I can, but the powers that be (hello
> GitHub) have made it impossible in many cases.
>
> It is a sad state of affai
Dnia 19.08.2024 o godz. 12:23:54 John A via mailop pisze:
> My motto that I tell my senders is "Send mail people want to people who
> want it." This should cover your personal > personal bucket ;-)
No, it won't. If you read again my messages, you would understand.
I want to emphasize it again: EV
Dnia 19.08.2024 o godz. 01:15:04 Richard Clayton via mailop pisze:
> perhaps Google and Yahoo don't work in exactly the same way ?
>
> also you should note that although anecdotes are interesting, what MBPs
> do does change over time
My message was not about how Google and Yahoo work, and what MB
Dnia 18.08.2024 o godz. 20:21:08 Kasper Peeters via mailop pisze:
> > Someone well respected round here advises "send email people have asked
> > for" ... those people find that in the spam folder
>
> There is one class of emails to which this logic does not apply: real
> humans sending email to o
Dnia 18.08.2024 o godz. 17:59:49 Richard Clayton via mailop pisze:
> Note that this behaviour is also the correct way to handle actual spam
> from spammers ... they have never sent anything that people wanted, yet
> their mail is not so awful to be rejected out of hand so it goes into
> the spam fo
Dnia 18.08.2024 o godz. 11:28:50 Kasper Peeters via mailop pisze:
> That test message eventually made its way out of the queue (the
> "temporary" aspect of the 421 error I guess) and then went straight to
> spam in my Yahoo account... So Yahoo decides by itself that it is spam
> and then uses that
Dnia 14.08.2024 o godz. 16:30:23 Dave Crocker via mailop pisze:
>
> That is why I was careful not to argue against timeouts, per se, but
> merely not to consider expected distance as a factor.
>
> There are a number of reasons for needing timeouts. And the choice
> of how long or short one shoul
Dnia 8.08.2024 o godz. 09:59:02 Tobias Fiebig via mailop pisze:
> The issue occurs if an employee/user of a PP client forwards such
> a mail, or, even worse, copies content--often not even being aware
> of the urldefense URL being included, e.g., when dealing with an
> HTML email.
>
> In that cas
Dnia 2.08.2024 o godz. 21:53:05 Tobias Fiebig via mailop pisze:
> > I realize this is unlikely to happen, but they should make up their
> > mind. If Google is hosting their mail, Proofpoint doesn't provide a
> > lot more than what Google already does. Or if they really want to use
> > Proofpoint,
Dnia 17.07.2024 o godz. 11:24:39 Stuart Henderson via mailop pisze:
> (Note that the mailop list sets "reply-to" to the sender's own address,
> so when replying on-list, so it's normal to use group-reply here,
> otherwise you need to adjust the To address by hand).
That's why it's good to develop
Dnia 10.07.2024 o godz. 21:24:23 Ralph Seichter via mailop pisze:
>
> If sombody tries to send mail from something.xxx or otherthing.auto, for
> example, they should expect having to work hard for their mail getting
> accepted. I reject this type of domain until by means of directing
I don't know
Dnia 9.07.2024 o godz. 11:53:47 Anne P. Mitchell, Esq. via mailop pisze:
>
> Receivers don't block email from new IPs by default;
Some certainly do.
Perhaps the most known example is T-Online, as mentioned here in another
email. It's their official policy. Every new (unknown) sending IP is bloc
Dnia 5.07.2024 o godz. 19:45:10 Jeff Pang via mailop pisze:
>
> When an user requests to join mailing list, which address should we
> take? The envelope address, or the header From address?
I think you should follow the best practice, ie. how it is implemented in
the predominant mailing list sof
Dnia 26.06.2024 o godz. 20:17:32 Al Iverson via mailop pisze:
> I'm not aware of any way to do this.
>
> Microsoft used to have a method to add sender logos for hosted email
> service domains. This was called Brand Cards. It's been dead for a few
> years, though.
The only case I saw Outlook displ
Dnia 18.06.2024 o godz. 20:27:49 Scott Mutter via mailop pisze:
> I work in the shared web hosting industry, which may be foreign to a lot of
> people on this list.
>
> With shared hosting, 1 physical server and 1 IP address hosts 100s of other
> websites and email accounts. And some of those acc
Dnia 30.04.2024 o godz. 14:44:32 Matus UHLAR - fantomas via mailop pisze:
> OTOH, UCEPROTECT-L3 is a strong sign there's something bad with the
> ISP and/or its customers (same as UCEPROTECT-L2).
>
> Of course you should only use it at SMTP level if feel your mission
> is to educate ISPs (or, not
Dnia 30.04.2024 o godz. 14:05:00 Stefan Bauer via mailop pisze:
> Wow. Indeed. Thank you. The ip is 217.160.0.245 and yes, the complete ASN
> is blocked.
That's why nobody should treat UCEPROTECT seriously (also due to highly
suspicious behavior of the people who run this blacklist - their de-list
Dnia 25.04.2024 o godz. 19:12:34 John Levine via mailop pisze:
> No, really it's not, and I should know. In any event, I can see how
> people might reject mail from a domain that has a TXT record but no
> A or MX, but it seems pretty marginal.
I'm not sure if you understand you well. Marginal? It
Dnia 25.04.2024 o godz. 14:59:35 Andrew C Aitchison via mailop pisze:
> Should someone here not know, RFC 7505
> A "Null MX" No Service Resource Record for Domains That Accept No Mail
> is the accepted standard way to signal a domain that does not receive email.
>
> By using the MX records sugge
Dnia 19.04.2024 o godz. 14:25:49 Grant Taylor via mailop pisze:
>
> I wonder if TCP connections were being fully established. Is there
> a chance that someone was spoofing your IP?
I was also thinking this.
> Could he produce packet captures for you to analyze?
Sadly no.
> Is there a possibil
Dnia 19.04.2024 o godz. 10:47:56 Sebastian Arcus via mailop pisze:
> In a sense I haven't managed to make further progress with this.
> Spamhaus have been very vague about the problem - which to some
> extent I understand as they don't want the bad guys to exploit their
> systems. But at the same t
Dnia 16.04.2024 o godz. 06:47:44 Bruno Flückiger via mailop pisze:
> Similar products are Microsoft Hyper-V, Oracle Linux Virtualization
> Manager (OLVM), Proxmox and Nutanix. Each one of these products has
> some shortcommings compared to VMware. If you don't need a GUI to
> manage your virtual en
Dnia 25.03.2024 o godz. 16:10:47 Rob Kendrick via mailop pisze:
> > The problem I am trying to fix is that these are legal emails and I
> > need a way to signal that to the providers. With many states and USA
> > government stating that email is a legal form of communication, how
> > can we guarant
Dnia 17.03.2024 o godz. 16:17:10 Hans-Martin Mosner via mailop pisze:
> >My current ISP (BTW, one of the biggest cable providers in Europe, you can
> >probably guess which one it is) currently provides by default an IPv6 *only*
> >connection to the home users, even if you have IPv4-only devices in
Dnia 17.03.2024 o godz. 08:30:39 Hans-Martin Mosner via mailop pisze:
> does IPv6 (not exclusively though), and I've been trying to usher in
> the future by setting up at least dual stack on my home DSL
> connection (that at least works now after years of IPv6 routing
> issues with my previous home
Dnia 16.03.2024 o godz. 16:57:54 Andy Smith via mailop pisze:
> On this list one might argue¹ that we all have MUAs capable of
> filtering etc. without subject tag and that we all know where the
> mail came from without an explanatory footer because we know to look
> at List-* headers. So maybe the
Dnia 16.03.2024 o godz. 13:08:52 Benny Pedersen via mailop pisze:
>
> bingo its why its tempfailed, gmail should redesign how to handle
> maillists where message-id can come to inbound on gmail, should not
> count on message-id abuse counts
Well... from Google's point of view, it seems like a pre
Dnia 8.03.2024 o godz. 12:45:18 Paul Gregg via mailop pisze:
> I can confirm your observations. I can't see their NS from my OVH box,
> nor can I connect to port 25 of the 3 IPs behind their MX.
> From home (UK broadband), I can see and query DNS servers, but I can't
> talk to port 25.
> From non
Dnia 7.03.2024 o godz. 13:12:27 Julian Bradfield via mailop pisze:
>
> If you have a mail client that is so badly written that it crashes
> when it encounters a missing character in a font, you need to replace
> or fix the mail client, or file a bug report against the library
> causing the proble
Dnia 26.02.2024 o godz. 10:50:44 Grant Taylor via mailop pisze:
> However my opinion is that this is the wrong thing to do. Like so
> many things, email is governed by checks and balances (of sorts).
> If enough people complain about not being able to receive something,
> then hopefully the provid
Dnia 26.02.2024 o godz. 10:19:54 Kris Deugau via mailop pisze:
> Also try getting your recipients to complain to their mail hosting
> provider - complaints from the people who want to *receive* the
> message are far more effective than complaints from the sender.
The typical reaction of an average
Dnia 24.02.2024 o godz. 13:16:45 Anne P. Mitchell, Esq. via mailop pisze:
>
> pointing out that Federal law mandates a one-step method; completely
Not everybody is located in the USA, and "federal" law has no meaning to
those who don't.
> two-step method, even though a one-step is implicit in th
Dnia 15.02.2024 o godz. 10:54:56 Philip Paeps via mailop pisze:
>
> Having said that: I have seen S/MIME and even PGP signed spear fishing.
I'd dare to say, that aginst *spear* phishing there is no viable technical
protection. The only protection against this is common sense and awareness
of the
Dnia 12.02.2024 o godz. 14:47:41 Sebastian Nielsen via mailop pisze:
> When you pass traffic on layer 7, you are the de facto recipient of the
> traffic, and when you then “resend” that received traffic somewhere else
> than its actually destined, you become responsible. That’s why a reverse
> pro
Dnia 12.02.2024 o godz. 14:44:43 Sebastian Nielsen via mailop pisze:
>
> Nope, you just open the encapsulated email (open the .EML attachment), and
> respond to that.
Very cumbersome. Speaking from my own experience.
--
Regards,
Jaroslaw Rafa
r...@rafa.eu.org
--
"In a million years, when k
Dnia 10.02.2024 o godz. 11:18:17 Al Iverson via mailop pisze:
> That error message, though, makes it sounds
> like IP reputation which is a rare error.
Actually, it has been mentioned here on this list several times. It usually
happens "out of the blue", for servers that were able to send OK previ
Dnia 12.02.2024 o godz. 12:15:08 Sebastian Nielsen via mailop pisze:
>
> However, if an end user SENDS something via the proxy, let's say a forum
> post, the proxy usually bears the responsibility for the content, which we
> have seen in numerous court cases where a proxy have been used to hide th
Dnia 11.02.2024 o godz. 00:10:54 Thomas Walter via mailop pisze:
> Remember when we had an SMTP status code 551?
>
> 551 User not local; please try
Would be an ideal solution if sending SMTP servers would actually react to
it like web browsers react to HTTP 301 or 302 status code, ie. automatic
Dnia 10.02.2024 o godz. 07:52:43 Sebastian Nielsen via mailop pisze:
> Try it yourself in your email software.
> Click Forward.
> Sending this email will basically rewrite the headers and add Fwd: into
> subject.
>
> You can also click "Forward as an attachment", which will forward the
> original
Dnia 10.02.2024 o godz. 12:42:36 L. Mark Stone via mailop pisze:
> 1. We have trained our Zimbra users who want their email to be copied
> someplace else to configure the someplace else to log in and collect their
> email from Zimbra, after having educated them that Forwarding is
> problematic and
Dnia 12.02.2024 o godz. 01:36:09 Benny Pedersen via mailop pisze:
> if spf should be pr email addresses, thay could add ipv6 pr sender
> email :=)
>
> and have ipv4 with nullMX or simply remove ipv4 in mx, will it ever
> happen ?
Yeah, use only IPv6 for sending mail and cut off deliverability to
Dnia 10.02.2024 o godz. 05:02:12 Sebastian Nielsen via mailop pisze:
> Disadvantages --> Every email will look like an empty email containing a
> attachment that you have to click to open.
Many antispam filters will right away classify such an email as spam.
> Also, that’s how forwarding ALWAYS h
Dnia 9.02.2024 o godz. 18:06:41 Slavko via mailop pisze:
> Hmm, and are you sure that regular users know what S/MIME is and
> are able to reliable distinguish email with and without it? I don't think
> so...
While they are probably not capable of signing S/MIME mail (which requires
getting your p
Dnia 9.02.2024 o godz. 07:13:31 Marco Moock via mailop pisze:
> S/MIME exists and I really don't understand why banks and online shops
> don't consequently use it.
I must say that my bank is and always was using it. Same for my phone
provider.
--
Regards,
Jaroslaw Rafa
r...@rafa.eu.org
--
Dnia 9.02.2024 o godz. 13:03:28 Philip Paeps via mailop pisze:
>
> Most people don't actually use email anymore. Email is for
> marketing and receipts.
Yeah, that's probably the main reason why they can live with such
problematic service like Gmail.
I have heard numerous times from Gmail users
Dnia 9.02.2024 o godz. 06:58:40 Marco Moock via mailop pisze:
> Not possible if some receivers require SPF, like Google for bulk
> senders.
> One possibility is to add ?all instead of -all. That makes it possible
> that sites that check SPF and reject on -, but accept no SPF, will
> accept the mes
Dnia 8.02.2024 o godz. 11:49:39 Kai Bojens via mailop pisze:
>
> Google wants you to use ARC for forwarded mails:
>
> https://support.google.com/a/answer/13198639?sjid=7229117128739116669-EU
I don't see anywhere on this page a statement that you must (or even should)
use ARC. It only describes
Dnia 7.02.2024 o godz. 20:51:15 Jarland Donnell via mailop pisze:
> Nearly 100% of
> users who forward email do so because they want it in Gmail.
I am always wondering - as Gmail gives so many problems that have been
discussed multiple times - why anybody who has another mail account would
want t
Dnia 7.02.2024 o godz. 14:41:02 Andreas S. Kerber via mailop pisze:
>
> This only applies if your sending more than 5000 messages per day.
That is a "MUST" in RFC sense ;), because otherwise they reject mails from
you.
But if you read their sender guidelines, they say since long ago (long
befor
Dnia 6.02.2024 o godz. 15:13:47 Michael Peddemors via mailop pisze:
> Some days.. it's like F* DMARC.. hehehe..
>
> Anything that created a multi-million dollar industry of consultants
> on how to set up DMARC, well.. email should NOT be that difficult..
>
> I still remember when email administr
Dnia 6.02.2024 o godz. 15:26:33 Aric Archebelle-Smith via mailop pisze:
> Beginning in late January, we received user reports that mail was not
> being delivered to Shaw.ca addresses. Users did not receive a
> non-delivery notification, but our logs show the following rejection:
> `status=sent (2
Dnia 3.02.2024 o godz. 13:34:43 Philip Paeps via mailop pisze:
> (There is something to be said for hard-enforcing specifically
> "v=spf1 -all", but policies with anything between the v=spf1 and the
> -all are overwhelmingly configuration errors, and should only count
> for scoring.)
I am glad th
Dnia 28.01.2024 o godz. 22:04:26 Jay Hennigan via mailop pisze:
> Conversely, when the receiver purges everything else in the spam
> folder without opening it, this gives feedback that the decision to
> route it to spam was correct.
And this is often the problem, because - as I mentioned - users t
Dnia 28.01.2024 o godz. 23:44:29 Scott Mutter via mailop pisze:
> What if the receiving mail server tagged the message in some way in their
> final acknowledgement of the message. For Google. instead of:
>
> 250 2.0.0 OK 1706409809
> h4-20020ac8584400b10427e71c979dsi9837397zyh.449 - gsmtp
>
Dnia 27.01.2024 o godz. 13:21:46 Thomas Walter via mailop pisze:
>
> To me it just doesn't make a lot of sense to basically have two
> inboxes to check - the regular one and the spamfolder.
>
> Also having to tell people to check their spamfolders every time
> they are missing an email is annoyin
Dnia 26.01.2024 o godz. 22:06:44 Gellner, Oliver via mailop pisze:
> Independent of this I wouldn’t use r...@hostname.example.org as a sender
> address to external recipients. This doesn’t look professional, makes
> replying to those emails impossible and in case hostname.example.org
> doesn’t have
Dnia 25.01.2024 o godz. 22:00:08 John Levine via mailop pisze:
>
> As I may have said once or twice before, when you pick the cheapest,
> crummiest option, often you get what you pay for.
s/the cheapest, crummiest option/the option you CAN actually afford/
Certainly you, John, are not the person
Dnia 25.01.2024 o godz. 07:10:13 Hans-Martin Mosner via mailop pisze:
> It's probably pointless to call for a general OVH boycott, as much as I
> would like to do that :-)
I would be the first to object to that, because my server is hosted at OVH :)
--
Regards,
Jaroslaw Rafa
r...@rafa.eu.or
Dnia 24.01.2024 o godz. 21:48:39 Grant Taylor via mailop pisze:
>
> Am I missing something obvious or has Google started implementing
> this new requirement ahead of their published schedule?
>
> The only surprise to me is that this happened ~8 days before the
> published February 1st date.
Appa
Dnia 24.01.2024 o godz. 11:57:13 Randolf Richardson, Postmaster via mailop
pisze:
> > But, in reality not really worth the trouble.. domains are easy to
> > forge, and innocent companies maybe trying to verify the address,
> > because a bad guy used it in a contact form..
>
> Not when SPF
Dnia 19.01.2024 o godz. 12:42:49 Randolf Richardson, Postmaster via mailop
pisze:
> UCE Protect also has level 3 listings for the worst offenders,
> although I don't recall the list being downloadable for firewall use:
>
> UCEPROTECT Blacklist Policy LEVEL 3
> h
Dnia 15.01.2024 o godz. 07:54:47 Sebastian Nielsen via mailop pisze:
> Problem is, that when MUA or first MTA has a incorrect date set, the email
> comes like last in inbox... have seen emails set with 1970-01-01 00:00:00
> Or, even worse, it has a date that is like, several months off, so you
> h
Dnia 15.01.2024 o godz. 08:07:28 Sebastian Nielsen via mailop pisze:
> A better solution would otherwise to make a BIMI extension to SMIME in
> that case, that will override the server BIMI in SMIME signed emails.
> Where the BIMI logo becomes part of the SMIME certificate by an
> non-critical ext
Dnia 13.01.2024 o godz. 16:58:27 John Levine via mailop pisze:
>
> That's why it's not silly that BIMI tries only to show legit logos, even
> though
> it makes it impractical for anyone other than largish organizations.
Which brings us back to my original point - which you now have confirmed -
t
Dnia 12.01.2024 o godz. 13:23:07 Todd Herr via mailop pisze:
> There is no such thing as "BIMI-authenticated". BIMI isn't authentication,
> and doesn't claim to be. I quote from the Abstract of
> https://datatracker.ietf.org/doc/html/draft-brand-indicators-for-message-identification
>
> BIMI permi
Dnia 12.01.2024 o godz. 11:18:32 Tim Starr via mailop pisze:
> By publishing the BIMI spec. No one's required to follow the spec, but if
> they don't, then they're not doing BIMI, and that's not the fault of the
> spec.
Does the BIMI spec *require* that *only* BIMI-authenticated messages can
have
Dnia 11.01.2024 o godz. 17:02:01 Tim Starr via mailop pisze:
> The image has to be specified in the DNS, and it has to be certified w/ a
> VMC. The VMC certification process includes checking if it's trademarked.
> So, in order for a trusted brand's BIMI logo to get spoofed, the email
> would have
Dnia 11.01.2024 o godz. 14:34:16 Laurent S. via mailop pisze:
> The trademark verification is only for those that pay for it. Nothing
> forbids a MUA from displaying an unverified BIMI. Most are luckily not
> doing it (yet), I just want to warn that if this becomes common, it will
> be abused fo
Dnia 10.01.2024 o godz. 14:05:26 Marcel Becker via mailop pisze:
>
> https://bimigroup.org/mailbox-providers/
Marketing blah-blah only. No actual explanation.
--
Regards,
Jaroslaw Rafa
r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hus
Dnia 10.01.2024 o godz. 22:57:21 Louis Laureys via mailop pisze:
> Just wanted to add that I actually like it for visual clarity. Though I would
> have liked a more general avatar implementation not geared towards businesses.
If someone, *as a recipient*, likes having avatars next to email, I have
Dnia 10.01.2024 o godz. 11:32:36 Seth Blank via mailop pisze:
> The hope is that as BIMI gets more widely adopted, the cost (and
> automation) of the logo validation drops. Time will tell.
>
> Of course, for broader adoption, we also need to progress beyond
> trademarks, which have their own cost
Dnia 1.01.2024 o godz. 23:10:22 Jaroslaw Rafa via mailop pisze:
>
> This is basically equal to the new configuration setting
> "smtpd_forbid_unauth_pipelining = no" which is a default for Postfix
> versions >= 3.9.
Sorry, of course I made a mistake here. I meant
"
Dnia 1.01.2024 o godz. 21:53:59 Gellner, Oliver via mailop pisze:
>
> Yes, but as with Postfix the update alone does not fix the vulnerability.
> You have to additionally change the config as instructed. The vendors and
> distributions don’t do this automatically as this changes the behavior of
Dnia 30.12.2023 o godz. 22:58:25 Simon Wilson via mailop pisze:
>
> The error message from Google is specifically:
>
> 421-4.7.28 Gmail has detected an unusual rate of unsolicited mail
> originating from your SPF domain [howiesue.net 35]. To protect our
> users from spam, mail sent from you
Dnia 30.12.2023 o godz. 15:57:45 Richard Rognlie via mailop pisze:
> I'm not seeing deferrals but some of my users are reporting that they're
> not seeing emails coming from my play by email service. I've double
> checked the logs and gmail is accepting the messages. So anything
> happening to us
Dnia 22.12.2023 o godz. 10:54:54 Randolf Richardson, Postmaster via mailop
pisze:
> > Tracking/spying elements in email messsages are usually intended to spy on
> > the *recipient* - did the recipient read the email at all, did he clicked
> > on a link in the email etc.
>
> ...mail server l
Dnia 22.12.2023 o godz. 16:22:45 Slavko via mailop pisze:
> But my point was (mostly) not about courties cases, i mean usual users
> tracking/spying (contacts, shoppings, opinions, etc), where signature is
> checked once (at receive time), but used/stored forever. And that cannot
> be solved by rot
Dnia 18.12.2023 o godz. 14:49:50 Paul Smith* via mailop pisze:
> Spam filters handle reputation of things. One thing they can do is
> track reputation of sender domains. When forgery is possible, then
> that means that spammers can piggy-back on the good reputation of
> big companies like Google, A
Dnia 17.12.2023 o godz. 10:45:04 Benny Pedersen via mailop pisze:
> >If they use forwarders, SPF will fail in the case the envelope sender
> >isn't rewritten. Check your logs for that.
>
> false, every forwarder changes envelope sender
Definitely not.
Simple forwarding, as done by default by .fo
Dnia 22.11.2023 o godz. 16:25:36 Otto J. Makela via mailop pisze:
> Can someone shed light on a Microsoft/Outlook block list? Our hobby server
> (on upcloud.com) seem to have been blocked for quite some time now.
>
> At this time, SPF and DKIM should be correct for our outgoing messages.
> Is ther
Dnia 21.11.2023 o godz. 12:44:20 Ralf Hildebrandt via mailop pisze:
>
> We're running the postfix-users ML on list.sys4.de, and all over a
> sudden we're being tempfailed by GMAIL:
Seems to be a quite common issue recently, many people here are reporting
it. Something's wrong at Google again (was
Dnia 17.11.2023 o godz. 22:37:58 Philip Paeps via mailop pisze:
> For the past couple of days, mx2.FreeBSD.org is queuing more mail to
> Google than usual.
>
> This is the 421:
>
> 421-4.7.28 Gmail has detected an unusual rate of unsolicited mail.
> To protect 421-4.7.28 our users from spam, mail
Dnia 17.11.2023 o godz. 14:34:19 Lukas Tribus via mailop pisze:
>
> Google probably wants you to enable STARTTLS, so reducing sending
> limits for non STARTTLS senders can make sense from Google's POV.
That thread makes me wonder, how come anybody is sending mail without
STARTTLS now? When all ma
Dnia 13.11.2023 o godz. 19:13:50 Jaroslaw Rafa via mailop pisze:
> > What if users travel abroad?
> >
> > IMHO, it is better to monitor login IPs using services like
> > AbuseIPDB which provide an abuse score.
>
> Or just fail2ban :)
Nevermind, I didn't not
Dnia 13.11.2023 o godz. 14:04:29 Alessandro Vesely via mailop pisze:
> >My boss wants to block access from abroad but that will block several
> >people, I'm afraid.
>
> What if users travel abroad?
>
> IMHO, it is better to monitor login IPs using services like
> AbuseIPDB which provide an abuse
Dnia 10.11.2023 o godz. 21:09:31 Louis Laureys via mailop pisze:
> You can probably tell from my wording how I feel about this. I get the battery
> efficiency part. Not the part where ActiveSync has an exception to it, and
> their
> own battery efficient IDLE alternative is not accessible to most.
Dnia 9.11.2023 o godz. 12:41:57 Jarland Donnell via mailop pisze:
> A score of 5.8 on SpamAssassin rules is fairly low. It would be more
> advisable for you to consider adjusting your settings. SpamAssassin
> is designed in such a way that it will always trigger a variety of
> rules for every emai
Dnia 31.10.2023 o godz. 11:09:52 Stuart Henderson via mailop pisze:
>
> SPF syntax allows expressing policy which can't be converted to a
> simple list of addresses (the policy can include further DNS
> lookups based on sender localpart/domain, IP address, etc).
>
> So it's not possible to produc
Dnia 27.10.2023 o godz. 17:03:29 Cyril - ImprovMX via mailop pisze:
>
> This should weight in the decision; If the hostname doesn't match the PTR,
> that the SPF fails, and so on, maybe it would be time to block the incoming
> email.
>
> Really interesting! Thank you everyone!
Hm... aren't you b
Dnia 27.10.2023 o godz. 15:19:33 Cyril - ImprovMX via mailop pisze:
>
> It's been quite common to refuse a server connecting that doesn't have a
> proper PTR, but I was wondering if there was any recommendation (either
> official via RFC or standard practice) about a server connecting with a PTR
>
Dnia 27.10.2023 o godz. 14:23:14 Marco M. via mailop pisze:
> > You mean DMARC failure?
> >
> > SPF by itself checks only the envelope-From.
>
> If Sender: is missing, the application will most likely use From: for
> envelope sender (MAIL FROM:) (normal MUAs do that). That will make SPF
> fail an
Dnia 27.10.2023 o godz. 12:44:09 Marco M. via mailop pisze:
> This will result in SPF failure if your MTA sends the message with
> From: and MAIL FROM:https://list.mailop.org/listinfo/mailop
Dnia 24.10.2023 o godz. 11:04:05 Alessandro Vesely via mailop pisze:
>
> Is that the way it went? Let's Encrypt certificates get renewed
> automatically, so it's hard to "forget" to do it.
They don't have to. You can just run a simple ACME client (like 'bacme') one
time, get a certificate and in
Dnia 23.10.2023 o godz. 11:27:09 Slavko via mailop pisze:
> Dňa 23. októbra 2023 10:26:57 UTC používateľ Jaroslaw Rafa via mailop
> napísal:
>
> >However, all this discussion is hardly related to email, as - as many have
> >noted - there's hardly any certificate ch
Dnia 22.10.2023 o godz. 12:59:18 Matt Corallo via mailop pisze:
> SSL certificates do not, and have never, "protected against MiTM".
> The certificate authority trust model can best be summarized as
> "someone else's DNS resolver and connection", it is not a statement
> of who actually owns the dom
Dnia 13.10.2023 o godz. 15:43:50 Al Iverson via mailop pisze:
> Submit a sample message from the affected IP here:
> https://support.google.com/mail/contact/gmail_bulk_sender_escalation
> They rarely respond, but they do sometimes address issues based on
> submissions.
Probably very rarely.
In my
1 - 100 of 546 matches
Mail list logo
