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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
>
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
>
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
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 -
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
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
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
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
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
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
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
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
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,
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
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
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
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,
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
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 notice t
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
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
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
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
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
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
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 checkin
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
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
Dnia 13.10.2023 o godz. 09:21:24 Fernando MM via mailop pisze:
>
> I'm debugging an issue with gmail classifying a simple confirmation email
> as spam.
>
> At my gmail account it displays "Why is this message in spam? It is similar
> to messages that were identified as spam in the past.". And at
Dnia 12.10.2023 o godz. 11:05:04 Otto J. Makela via mailop pisze:
> Microsoft had an about 16 hour period of time where their servers
> only gave a "451 4.7.500 Server busy" for their hosted domains. We saw
> these in the time range 2023-10-11T04:45/20:17+03:00, and in that time
> we had mails
Dnia 6.10.2023 o godz. 13:41:06 Marco via mailop pisze:
> > As does the standard mechanism used in browers for dealing with the
> > same type of situation.
>
> Although they try IPv6 first and don't do a "protocol balancing", at
> least I haven't experienced that yet.
One can configure Postfix
Dnia 6.10.2023 o godz. 11:00:27 Bjørn Bürger via mailop pisze:
>
> Some MTAs, like postfix for example, do load balancing across ip
> protocols. I have no idea, why they think, this might be a good idea,
> though. It's quite annoying.
Here's a quite recent explanation from Postfix author,
Dnia 6.10.2023 o godz. 11:01:10 Marco via mailop pisze:
> > https://www.postfix.org/postconf.5.html#smtp_address_preference
> > https://www.postfix.org/postconf.5.html#smtp_balance_inet_protocols
>
> Does the balancing test IPv6 first or is it just randomly?
> Does it use the first address that
Dnia 18.09.2023 o godz. 09:53:16 Scott Mutter via mailop pisze:
> Headers formatted as:
>
> From: Name
> MIME-Version: 1.0
>
> Generates this multiple addresses in From header error.
Because this header is equivalent to:
From: Name MIME-Version: 1.0
and somehow Google interprets it as
Dnia 13.09.2023 o godz. 12:35:15 Gellner, Oliver via mailop pisze:
> Other than that, I'm with you and Bill Cole: If your infrastructure is not
> being used to send spam, newsletters or other marketing messages, feedback
> loops provide no benefit. 100% of all reports are going to be false
>
Dnia 13.09.2023 o godz. 13:54:01 Atro Tossavainen via mailop pisze:
> > Might be convinced with this if it weren't for gmail being the source of
> > ~40% of the spam we receive.
>
> And that's after all of the botnets and so on have been blocked
> through the use of DNSBLs, I suppose?
I guess
Dnia 13.09.2023 o godz. 02:52:59 Jarland Donnell via mailop pisze:
>
> It's my finding that at scale, there's no silver bullet to ensure
> that 100% of emails you forward are going to be accepted by Google,
> or anyone really. That's why anyone who considers their inbox
> mission critical needs
Dnia 26.08.2023 o godz. 13:58:21 Slavko via mailop pisze:
>
> Or people simple do not want to share own email, as it is
> not related for delivery, but required by the form. Thus
> they fill semi random email like string.
In many cases either the correct email address OR a phone number is needed
Dnia 25.08.2023 o godz. 09:48:35 Chris Adams via mailop pisze:
>
> So even for transactional messages, there's usually an account making
> the purchase, or something is being delivered to an address, or the
> like. So a "this is not me" link should be able to note that (a) don't
> send more mail
Dnia 24.08.2023 o godz. 07:12:52 Chris Adams via mailop pisze:
> What do you do when legitimate mail (lately, DoorDash order info and
> Delta Airlines tickets) is sent to the wrong address? These types of
> messages rarely have an unsubscribe method. I get a ton of crap to a
> Gmail address that
Dnia 23.08.2023 o godz. 09:08:52 Michael Peddemors via mailop pisze:
>
> It continues to be a battle, but overall the traditional spammers
> are still getting IP space, seems that even the historically 'good'
> hosting companies are throwing in the towel lately, and letting any
> one on board
Dnia 19.08.2023 o godz. 11:49:34 Jarland Donnell via mailop pisze:
>
> Is "-all" not indeed a policy in SPF, directed by the domain owner?
> I would argue that it is. Especially given that there are options
> there, each one defining how the domain owner wishes SPF failure to
> be treated. I
Dnia 14.08.2023 o godz. 10:42:53 Dan Malm via mailop pisze:
>
> Since Friday I'm seeing a rather extreme amount of SMTP AUTH
> requeusts from the same IPv6 IP space that outlook.com uses when
> sending emails on behalf of customers that have added an "external"
> address to sync and send from to
Dnia 9.08.2023 o godz. 17:13:01 Mike Hillyer via mailop pisze:
>
> We have a user who has noted that the two subdomains
> *.olc.protection.outlook.com and *.mail.protection.outlook.com are
> grouping separately and asked about them being merged so they could
> maintain only one set of throttle
Dnia 9.08.2023 o godz. 11:00:12 Otto J. Makela via mailop pisze:
>
> Unless the situation has dramatically changed in the last year,
> OVH has no functioning abuse team. I block a majority of their nets
> from sending email, don't seem to getting any false positives.
Luckily you don't block the
Dnia 25.07.2023 o godz. 21:44:21 John Levine via mailop pisze:
> It appears that Mike Hillyer via mailop said:
> >So, before allowing access to submission service, Postfix consults IMAP
> >server (Dovecot in this case) to check if there is actually a
> >currently existing authenticated IMAP
Dnia 24.07.2023 o godz. 19:35:28 Sebastian Nielsen via mailop pisze:
> Also on the topic on mail server hacking, I would suggest to add
> IP-restriction on your mail accounts.
[...]
I'll add here another idea that I have implemented on my server. I don't
know how easy would be to do this with
1 - 100 of 520 matches
Mail list logo
