Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

Dnia 19.10.2022 o godz. 18:55:29 Kai 'wusel' Siering via mailop pisze: > > It would be less of an issue if t-online.de would take care _not_ to send > to domains they don't take the replies from; but they happily sent emails > to any MX in the world (anything else would upset _their_ users), but t

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

Dnia 19.10.2022 o godz. 13:33:04 Heiko Schlittermann via mailop pisze: > (translation by me): > Sorry, we only accept messages from proven > commercial or similiar servers. Please use the SMTP relay of your hoster > or your ISP. > > I know that T-Online's postmaster announced this kind of b

Re: [mailop] gmail: Benefit of a generic SPF-record?

Dnia 30.09.2022 o godz. 08:55:11 Andrew C Aitchison via mailop pisze: > If your are being defaulted to spam and no recipient flags a message as "not > spam" your score is > spam/not-spam 0/0 -> use default = spam. > > If you send 100 messages and one is marked "not spam", your score becomes

Re: [mailop] gmail: Benefit of a generic SPF-record?

Dnia 29.09.2022 o godz. 15:39:49 Brandon Long via mailop pisze: > > But exactly because TLS is a TLD, which means both bad and good actors can > > register under it, you should not treat a whole TLD (any TLD) as a spam > > source. > > You should conside every domain under the TLD individually. > >

Re: [mailop] gmail: Benefit of a generic SPF-record?

Dnia 29.09.2022 o godz. 10:33:38 Brandon Long via mailop pisze: > The PSL only tells you what's the TLD and what's not, that doesn't mean you > can't consider > a TLD a bad spam source. There are plenty of those. Like checking the > reputation of a network or ASN over a > single IP. But exactly

Re: [mailop] gmail: Benefit of a generic SPF-record?

Dnia 29.09.2022 o godz. 10:02:53 Brandon Long via mailop pisze: > > Another is the same old PSL issue, rDNS is rarely going to match the exact > domain, and sub-domain > matching can go awry. Obviously things like DMARC also rely on PSL, so it > seems unlikely this is the > reason. It's quite fu

Re: [mailop] How should I interpret DMARC failure reports with "abuse reports"?

Dnia 23.09.2022 o godz. 16:41:50 Jarland Donnell via mailop pisze: > In general, I just suggest to everyone a step above that as well. If you > don't know exactly why you're deploying DMARC I wouldn't do it at all. I would totally agree with this if only Google didn't require that you have DMARC s

Re: [mailop] Reject vs spam folders

Dnia 16.09.2022 o godz. 11:15:41 Grant Taylor via mailop pisze: > > I may be naive in my belief, but I do believe that you know how you operate > your email better than I do, and that if you tell me that you only send > email from X, Y, and Z, and that anything else is not from you, well, I'm > go

Re: [mailop] The oligopoly has won.

Dnia 16.09.2022 o godz. 03:57:36 Kai 'wusel' Siering via mailop pisze: > > While myself I still do "evangelize" on various forums - wherever I can - > > that "Friends don't let friends use Gmail", quite a lot of my actual friends > > *do* use Gmail and I have no way to make them not to... > > Of

Re: [mailop] Reject vs spam folders

Dnia 15.09.2022 o godz. 17:42:47 John Levine via mailop pisze: > > Speaking as a spammer, allow me to offer my deepest thanks for your help > at tuning my techniques to evade your filters. I knew that someone would bring up that argument ;) -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In

Re: [mailop] Reject vs spam folders

Dnia 15.09.2022 o godz. 22:34:50 Paul Smith via mailop pisze: > > Arguing that "a rejection is better" makes sense *when the sender is human, > technically competent and understands how email works*. Most senders don't > fall into that category. It's not me who argued that rejection is better. Re

Re: [mailop] Reject vs spam folders

Dnia 15.09.2022 o godz. 22:51:29 Cyril - ImprovMX via mailop pisze: > So basically, what would be interesting to have is both : land the email in > the spam folder but notify the sender about if, maybe via an ARF report ? > That way, the event organizer or the one applying for a job would be able >

Re: [mailop] Reject vs spam folders

Dnia 15.09.2022 o godz. 11:32:41 Jay Hennigan via mailop pisze: > > If recipients at least periodically scan the contents of the spam folder and > mark wanted mail, this avoids the need for the sender to communicate > out-of-band to deliver the original (and likely future) messages as would be > t

Re: [mailop] Reject vs spam folders

Dnia 15.09.2022 o godz. 16:06:22 Cyril - ImprovMX via mailop pisze: > If I'm missing an email, I can simply check the Spam folder, which will be > faster (and less tedious) than reaching out to the sender for him to send > another copy (hoping it wasn't an automated email, otherwise I'm good to > w

Re: [mailop] The oligopoly has won.

Dnia 15.09.2022 o godz. 09:52:30 Slavko via mailop pisze: > > I have idea (not implemented yet) to do server side personal SPAM > (bayes) filter, which will be trained automatically (based on move > to/from Junk folder) and will eg. negate delivery to Junk folder from > central filter. I did some

Re: [mailop] The oligopoly has won.

Dnia 15.09.2022 o godz. 09:07:23 Thomas Walter via mailop pisze: > > I'd love to use Ham/Spam filters, but in a very diverse environment > (university campus) with users of all languages that's a difficult task to > get right. In that case these filters clearly should be per-user. -- Regards,

Re: [mailop] The oligopoly has won.

Dnia 14.09.2022 o godz. 11:10:32 Anne Mitchell via mailop pisze: > > I think what is being lost here is that for any inbox that is being > provisioned by a webmail provider (and maybe others), it is an advantage > for the *webmail provider* to have each user have a spam folder. These > providers

Re: [mailop] The oligopoly has won.

Dnia 14.09.2022 o godz. 16:49:58 Thomas Walter via mailop pisze: > > If I send someone an email and get a reject, I know they didn't receive it. > It's my job to make sure they get the email then or contact them using other > means. > > That's a lot better than Schrödinger's mailbox where you don

Re: [mailop] The oligopoly has won.

Dnia 14.09.2022 o godz. 01:32:53 Jarland Donnell via mailop pisze: > > Do any of you feel as though you could hold Gmail accountable for anything > and actually be heard at the same time? Because if you get fired as admin, > or your users leave you, what good is theoretically holding them > accoun

Re: [mailop] The oligopoly has won.

Dnia 12.09.2022 o godz. 21:07:12 Grant Taylor via mailop pisze: > On 9/12/22 8:15 PM, Dave Crocker via mailop wrote: > > I believe 'impossible' is not the prevailing sentiment. > > > > I believe the prevailing sentiment is that it is a challenging task, > > requiring significant expertise. > > Th

Re: [mailop] The oligopoly has won.

Dnia 12.09.2022 o godz. 19:02:44 Henrik Pang via mailop pisze: > why bother to self host an email? using gmail/gsuite save a lot of time. Because Internet was designed to be a *distributed* system. Everybody can have a server and host any service. The oligopoly mentioned here pushes the Internet

Re: [mailop] SMTP noise from *.bouncer.cloud

Dnia 5.09.2022 o godz. 15:58:51 Jay Hennigan via mailop pisze: > > Of course, if you want that other person receive all information about > > the progress and results of your application, and you have no access to > > that information (unless you personally come to the office to ask about it), > >

Re: [mailop] SMTP noise from *.bouncer.cloud

Dnia 5.09.2022 o godz. 17:56:13 Bill Cole via mailop pisze: > > Yes, of course, but he said he is using "reject_unverified_recipient" which > is RECIPIENT address verification, a tool which is used to prevent > backscatter on machines that do legitimate relaying of mail. Sorry, I used the wrong

Re: [mailop] SMTP noise from *.bouncer.cloud

Dnia 5.09.2022 o godz. 14:45:40 Michael Peddemors via mailop pisze: > > This is the only argument that holds any kind of merit, but if you want to > REALLY see if the person intended to register, send them a real email, as in > confirmed double opt-in, that they have to click on. Otherwise, I can

Re: [mailop] SMTP noise from *.bouncer.cloud

Dnia 5.09.2022 o godz. 22:39:01 Atro Tossavainen via mailop pisze: > > So do all the ESPs. But their customers send mail, and the recipients > are able to act upon it, informing the ESP of problem clients and > sometimes even getting traction. > > In the case of email verifiers, there is no mess

Re: [mailop] facebook, help?

Dnia 27.08.2022 o godz. 20:50:51 Dave Lugo via mailop pisze: > > She's in tears. She has ~15 years of kid pics, memorories, all lost... I know it's too late, but why someone stores such important things only on FB and does not have a local copy on a disk? -- Regards, Jaroslaw Rafa r...@ra

Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on IMAP and SMTP.

Dnia 19.08.2022 o godz. 10:31:32 Brandon Long via mailop pisze: > I won't say that OAUTH is the perfect solution to all of these issues, but > it is definitely an improvement for them. > Could TLS client certs have been issued in place of the tokens in these > schemes? Maybe? Not sure what it > w

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

Dnia 4.08.2022 o godz. 12:51:21 Gellner, Oliver via mailop pisze: > > A TLS encrypted SMTP connection protects against eavesdropping or altering > of messages through MITM attacks, which can be either passive or active: No. As long as certificates are not checked (and on MTA-to-MTA connections t

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

Dnia 3.08.2022 o godz. 19:51:24 Jarland Donnell via mailop pisze: > Either allowing an end user to negotiate a secure connection, to which their > software absolutely acknowledges it as a secure connection, is either sane > or it isn't. Ignore the protocol. Ignore the software. Either it's sane to

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

Dnia 3.08.2022 o godz. 14:46:06 Jarland Donnell via mailop pisze: > > But you must take into account the difference between web and e-mail. > > With > > HTTPS, the connection is directly between your browser and the server, > > so if > > it's secure, it's secure (as long as you trust the server).

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

Dnia 3.08.2022 o godz. 14:28:43 Jarland Donnell via mailop pisze: > > There's nothing that requires you to log a TLS 1.0/1.1 connection as > > being secure. You could choose to log it as if it were plaintext. It's > > likely to be logged with the protocol and cipher information. > > What you log

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

Dnia 3.08.2022 o godz. 13:14:07 Jarland Donnell via mailop pisze: > > It's about proper documentation, expectation, and communication. The most > secure line is the actual secure line, the least secure line is the one that > says "I am secure" and isn't. This might sound confusing because most pe

Re: [mailop] HR 8160 and SB 4409: The "You're not allowed to run political campaign email through your spam filter" act

Dnia 1.08.2022 o godz. 08:26:56 Dan Malm via mailop pisze: > > But the only way you can get gmail to "use a filtering algorithm to apply a > label" would be for yourself to "take action to apply such a label" by > creating a filter yourself... Gmail doesn't apply labels to spam, it places > the s

Re: [mailop] Trouble sending to sympatico.ca

Dnia 31.07.2022 o godz. 09:28:31 John Gateley via mailop pisze: > > Usually providers provide info on the block, with details on how to get > removed if you are legit etc. This error is very unfriendly... For example in case of Postfix, if you manually add sender's IP or email address to the bloc

Re: [mailop] HR 8160 and SB 4409: The "You're not allowed to run political campaign email through your spam filter" act

I'm not an American, so it's basically "not my fairy-tale" (as we say in our country), but I can't stop wondering at the use of the word "label" in the proposed regulation. I already asked (in a bit sarcastic tone) in one of the previous emails, what is a "label" in context of email in general. Be

[mailop] Gmail going crazy again

Just now I tried to send a message to a group of 6 people (of which 3 are on Gmail) whom I *regularly* correspond with and never had problems sending mail to them. But Gmail rejects my message to those 3 people with the infamous "421-4.7.28 Our system has detected an unusual rate of unsolicited mai

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

Dnia 25.07.2022 o godz. 04:09:14 Ángel via mailop pisze: > > Now, if we instead have the hash bbbaa1af939a01d0e22286c63827d936 > If you can hash multiple emails until finding who that refers to, then > it's equivalent to the email. IANAL as well, but if you want to hash multiple emails to find th

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

Dnia 23.07.2022 o godz. 15:25:43 Atro Tossavainen via mailop pisze: > > Ideally, a SMTP return code should differentiate the reason for rejection. > > There should be a different code for non-existing user, technical problems > > (like mailbox full) or policy-based reject. > > You know, they actua

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

Dnia 23.07.2022 o godz. 09:17:30 Laura Atkins via mailop pisze: > > Consider the case where Microsoft spits out a incorrect and false 550 user > unknown (which happens every couple years). What you’re suggesting is > that when this happens the next time, Gmail block every gmail user from > ever s

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

Dnia 22.07.2022 o godz. 20:10:35 Atro Tossavainen via mailop pisze: > > Indeed if, say, an address doesn't exist, it doesn't exist whether the > sender is X or Y. > > Also, if the mail platform rejects mail from the sender's IPs or domains, > it will probably do that for X and Y alike. Ideally,

Re: [mailop] Google's Request to the FEC about Allowing Political Email to Bypass Spam Filtering

Dnia 12.07.2022 o godz. 13:06:46 Bob Proulx via mailop pisze: > > This is in the context of Google's Gmail webmail web email reader > interface. Gmail tags messages into various tabs in the web email > reader interface. This currently includes Promotions as a tab and in > the above possibility m

Re: [mailop] Google's Request to the FEC about Allowing Political Email to Bypass Spam Filtering

Dnia 10.07.2022 o godz. 11:03:32 Anne Mitchell via mailop pisze: > > Or a 'Political' tab, just like the 'Promotions' tab. What is a "tab" in context of the SMTP protocol? What is a "tab" in context of the IMAP protocol, if user uses it to access his/her mail? -- Regards, Jaroslaw Rafa r..

Re: [mailop] Google's Request to the FEC about Allowing Political Email to Bypass Spam Filtering

Dnia 9.07.2022 o godz. 13:53:46 Anne Mitchell via mailop pisze: > To those of you who aren't already aware of it, Google has asked the > Federal Election Commission for an opinion about Google's 'pilot project' > to allow political candidates and campaigns to bypass Google's spam > filters. Don't

Re: [mailop] Interesting question from a team member, MX chaining, list-manage.com

Dnia 1.07.2022 o godz. 10:00:00 Paul Smith via mailop pisze: > If you don't want to accept mail for a domain, usually, you'd accomplish > that by simply not having an MX record. Not having a MX record AND not having an A record as well. Otherwise, if there is no MX record but there is A record,

Re: [mailop] No MX? use A/AAAA

Dnia 20.06.2022 o godz. 16:32:10 Jarland Donnell via mailop pisze: > > Be that as it may in opinion, it was my observation that having this > limitation has resulted in extremely minimal pushback with extremely > significant gain. Everything we do is a trade off. If I could have a rule > that had

Re: [mailop] No MX? use A/AAAA

Dnia 20.06.2022 o godz. 15:39:22 Jarland Donnell via mailop pisze: > I've seen it work but frankly, I don't bother with it anymore. No MX for > sender or recipient, I don't send it. This rspamd module right here: > https://rspamd.com/doc/modules/mx_check.html > > While it works, I can't recall the

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

Dnia 20.06.2022 o godz. 15:27:10 Bill Cole via mailop pisze: > > From your message, as received here: > > From: Jaroslaw Rafa via mailop > Reply-To: Jaroslaw Rafa > > Common Mailman behavior. Yes, common (that's exactly what I'm writing about), but &quo

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

Dnia 20.06.2022 o godz. 20:05:37 Jaroslaw Rafa via mailop pisze: > > Mailing lists can operate minimal changes, like this list does, for example. > > I received your message with "From: Jaroslaw Rafa " after > > my filter verified that your DKIM signature still vali

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

fied that your DKIM signature still validates upon undoing > their changes. If my domain had DMARC record with p=reject instead of p=none, you would receive a message with: "From: Jaroslaw Rafa via mailop ". You can find a lot of such examples in the messages from other people on this

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

Dnia 19.06.2022 o godz. 08:40:18 Noel Butler via mailop pisze: > > I was a very early (even in testing) user of SPF, It's rather commical > reading these FUD sayers about SPF and mailing lists, it has never been a > problem with mailing lists, not using mailman nor its more common > predecessor m

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

Dnia 17.06.2022 o godz. 21:35:08 Brandon Long via mailop pisze: > There is a limit to the utility of that thing, however, ie SPF passing doesn't > mean a message isn't spam, And the reverse is true as well - SPF failing doesn't mean the message is spam. Neither does it mean it is fake - just becau

Re: [mailop] Question for Google -- how am I able to be added to google groups without opting in?

People, please stop CC'ing me when you reply to this thread. Reply to list only, I don't need a second copy of your messages. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her dadd

Re: [mailop] Question for Google -- how am I able to be added to google groups without opting in?

Dnia 16.06.2022 o godz. 11:38:00 Dan Mahoney via mailop pisze: > > Can someone please explain to me how/why a google group manager is able to > just add any email address and send to it? Considering all the > authentication they're requiring, this seems like a gaping hole in any > kind of securit

Re: [mailop] How "more secure" is actually less secure (regarding Gmail)

Dnia 30.05.2022 o godz. 11:57:57 Ken O'Driscoll via mailop pisze: > > The point of the measure is to reduce the chance of attacks related to > password reuse. > > If a reused password and the associated Gmail email address are exposed > because of a security breach with Service X, then that data

[mailop] How "more secure" is actually less secure (regarding Gmail)

Hello, today is the day when Google withdraws "access for less secure apps", which - translated to understandable terms ;) - means that IMAP client (or any other non-web app) cannot login to Google using password only. One has to switch either to use OAuth2 as the method of authentication (if the a

Re: [mailop] Any reason to NOT block the entire .cam domain?

Dnia 27.05.2022 o godz. 14:15:12 Grant Taylor via mailop pisze: > > I can understand the desire to block some -- what I refer to as -- > vanity domains. But .us is a country code TLD. I would refrain > from blocking CC TLDs. Definitely. I have seen a LOT of completely legitimate mail coming fro

Re: [mailop] forwarding to gmail - problem

Dnia 8.05.2022 o godz. 16:59:29 Hans-Martin Mosner via mailop pisze: > Am 08.05.22 um 15:27 schrieb Scott Mutter via mailop: > >If you forward your mail to Google then Google is going to get your email. > > > >If you give Google your POP password to retrieve mail, then Google is > >going to get yo

Re: [mailop] forwarding to gmail - problem

Dnia 6.05.2022 o godz. 14:41:49 John Levine via mailop pisze: > > Until then, I tell people who ask me to forward mail to Gmail that if > they actually want to get the mail, I'll put it in a local mailbox and > they can tell Gmail to poll it with POP. That works quite well. As I already noted,

Re: [mailop] forwarding to gmail - problem

Dnia 29.04.2022 o godz. 12:08:13 Andrew C Aitchison via mailop pisze: > >You wouldn't want to give anybody - be it Google or anybody else - login > >credentials to your email account, would you? > > In many organisations it is worse than that. > With single-sign-on it gives Google etc. access to t

Re: [mailop] forwarding to gmail - problem

Dnia 28.04.2022 o godz. 14:14:02 Dan Mahoney via mailop pisze: > I've told any of my users to not forward to gmail instead, but rather to > just use their pop-fetcher. You wouldn't want to give anybody - be it Google or anybody else - login credentials to your email account, would you? -- Regards

Re: [mailop] forwarding to gmail - problem

Dnia 28.04.2022 o godz. 14:58:09 Scott Mutter via mailop pisze: > Automatic email forwarders are generally a bad idea, at least in my > humble opinion. > > They're always going to fail SPF unless you rewrite the > sender-envelope, which I also don't think is a good idea. I would say the opposite.

Re: [mailop] [E] $GOOG

Dnia 23.04.2022 o godz. 14:48:05 Dan Mahoney via mailop pisze: > > I would LOVE there to be legal structure to say “Gee, Equifax, you failed > to demonstrate the basic opsec of paying some junior admin to type `yum > upgrade apache-struts`, so you don’t get to keep my PII anymore.” I would > love

Re: [mailop] [External] Re: FYI - Google/Gmail hard enforcing SPF presence

Dnia 19.04.2022 o godz. 15:34:07 Kevin A. McGrail via mailop pisze: > > My argument is since you can't join Google's postmaster tools until > you have SPF or DKIM, well that sort of answers it for you from > Google's perspective: Google Postmaster Tools is of no use anyway if you are a small send

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

Dnia 19.04.2022 o godz. 11:17:54 Scott Mutter via mailop pisze: > > I'm a little surprised people are this upset. Google's using SPF for what > it's actually meant for - and yet people are upset because they are doing > that? No. "Using SPF for what it's actually meant for" would be honoring wha

Re: [mailop] [E] $GOOG

Dnia 15.04.2022 o godz. 20:18:54 John Levine via mailop pisze: > > > >You quoted that. Eu.org is a *domain registrar*. Only. They don't offer any > >email service and never did. So how can they "police users for email"? > > They can turn off people when they get credible spam reports. Maybe they

Re: [mailop] [E] $GOOG

Dnia 15.04.2022 o godz. 19:20:28 Laura Atkins via mailop pisze: > > Would you really hold it against that company, given the data they have, > if they blocked all mail with that tld in it? Given that it’s 90+% > guaranteed that tld is spam? What if 90+% of the mail in the .eu.org >

Re: [mailop] [E] $GOOG

Dnia 15.04.2022 o godz. 13:29:45 Luis E. Muñoz via mailop pisze: > > There are many who claim that there's a correlation between easily, > cheap (or free) domain names and spam. Their rationale is that > spammers can secure disposable domain names for very low price. Domains at eu.org are free, b

Re: [mailop] [E] $GOOG

Dnia 15.04.2022 o godz. 11:47:37 Bill Cole via mailop pisze: > > OK, so you know why Google rejects your mail and how you could fix it, if > you wanted to have your mail accepted instead of having a solid point to > argue here. As I said initially, using a different domain is only a poor workarou

Re: [mailop] [E] $GOOG

Dnia 15.04.2022 o godz. 16:55:36 Graeme Fowler via mailop pisze: > > $ host 217.182.79.147 > 147.79.182.217.in-addr.arpa domain name pointer rafa.eu.org. > > $ whois -h whois.cymru.com 217.182.79.147 > AS | IP | AS Name > 16276 | 217.182.79.147 | OVH, FR > > Obviously we’v

Re: [mailop] [E] $GOOG

Dnia 15.04.2022 o godz. 16:53:11 Laura Atkins via mailop pisze: > > "EU.org, free domain names since 1996” You quoted that. Eu.org is a *domain registrar*. Only. They don't offer any email service and never did. So how can they "police users for email"? Do you know any paid domain registrar - f

Re: [mailop] [E] $GOOG

Dnia 15.04.2022 o godz. 09:36:16 Grant Taylor via mailop pisze: > On 4/15/22 8:32 AM, Jaroslaw Rafa via mailop wrote: > >Never used IPv6 to send mail at all. > > I strongly disagree with that statement. Both in the current > veracity and the long term implications thereof. Wh

Re: [mailop] [E] $GOOG

Dnia 15.04.2022 o godz. 15:43:13 Laura Atkins via mailop pisze: > > He’s also been told, repeatedly, to stop using a free service that doesn’t > police its users for email. Google doesn’t like services that let folks > abuse them and don’t do anything about it. They’re also blocking mail > with bi

Re: [mailop] [E] $GOOG

Dnia 15.04.2022 o godz. 09:24:41 Al Iverson via mailop pisze: > PPS- Don't send to Gmail over IPv6. Never used IPv6 to send mail at all. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived w

Re: [mailop] [E] $GOOG

Dnia 14.04.2022 o godz. 12:40:52 Al Iverson via mailop pisze: > > Yes, it is unfixable. Once Google's AI decides (for no apparent reason) that > > it will reject e-mails from you, or put them to recipients' spam folder, > > there's pretty much nothing you can do about it. > > That is false. I can

Re: [mailop] $GOOG

Dnia 13.04.2022 o godz. 20:28:18 Rob McEwen via mailop pisze: > (2) These are OFTEN the types of mistakes that are most often > unknown to the sender - since the sender then never gets back a > non-delivery notification. (and unfortunately not everyone is savvy > and consistent with requesting and

Re: [mailop] [E] $GOOG

Dnia 13.04.2022 o godz. 19:44:52 Al Iverson via mailop pisze: > > Seconded. Google does not do things the way I would, and I find them > frustrating, yes, but no, it is not true about there being some > conspiracy to keep you out, and no, it's not unfixable, unless you > stick your head in the san

Re: [mailop] Best mailbox provider for personal domain?

Dnia 14.04.2022 o godz. 09:36:43 Al Iverson via mailop pisze: > IMAP download is indeed a lot slower than Google Takeout -- I learned > that the hard way. I tried to download it all via IMAP then gave up > and switched to Google Takeout. FYI, Apple Mail will read the Google > Takeout MBOX file, so

Re: [mailop] What the f**k, Google?

Dnia 2.03.2022 o godz. 11:44:57 Graeme Fowler via mailop pisze: > > Whilst I may occasionally - like 5 or 6 times a year - have something that > lands in the Junk folder, I almost _never_ receive “obvious” spam in the > Inbox, and neither do they. Personally I care more about the spam filtering

Re: [mailop] What the f**k, Google?

Dnia 2.03.2022 o godz. 10:08:48 Edgaras | SENDER via mailop pisze: > > sorry, I can't describe the stupidity and incompetence of Gmail systems > lately without resorting to expletives. Seriously everyone, see for > yourselves. Google has quite a time ago gone completely crazy with regard to spam

Re: [mailop] Best email server for home use...

Dnia 24.02.2022 o godz. 09:30:27 Grant Taylor via mailop pisze: > > What I don't know is if this qualifies as "hosting entirely > yourself". Does the reliance on a VPS to be an L3 endpoint break > "entirely"? Does substituting the VPS with a box that you Co-Lo > change anything? I guess theres n

Re: [mailop] Best email server for home use...

Dnia 24.02.2022 o godz. 01:58:36 Paul Gregg via mailop pisze: > > So I concur with John... it is perfectly possible to host yourself if > you can get past things like 'dialup rbls' and other poor reputation > blocks. It's often easier just to let established providers do that > bit. So you are n

Re: [mailop] Best email server for home use...

Dnia 23.02.2022 o godz. 13:10:56 Sinclair, John via mailop pisze: > hosting my own email server for the family. What's the best of breed > these days for small/micro servers hosting five-ish email accounts, > probably no more than 1TB total - looking for > as-close-to-gmail-as-possible webmail, IM

Re: [mailop] Musings on Mail Service Operators

Dnia 3.02.2022 o godz. 11:59:42 Andrew C Aitchison via mailop pisze: > > Having said that, my understanding is that deliverability is also an > issue in Facebook. If some of my posts are not shown to some of my friends, > without them telling Facebook that they did not want to see those messages,

Re: [mailop] Musings on Mail Service Operators

Dnia 2.02.2022 o godz. 21:31:04 Scott Mutter via mailop pisze: > Instant > messaging and SMS can't as easily be spoofed, they may be fake but senders > have to register on the platform in some way Here in Poland we are now right in the middle of a real-life "experiment" that will probably show ho

Re: [mailop] Musings on Mail Service Operators

Dnia 2.02.2022 o godz. 18:26:38 yuv via mailop pisze: > > Either it will go the other way, or folks will move away from email all > together. I am moving away. I miss the ability to store away in > Maildir format my correspondence and to look back in the archives to > Eudora times and earlier,

Re: [mailop] Musings on Mail Service Operators

Dnia 2.02.2022 o godz. 10:47:33 Carsten Schiefner via mailop pisze: > Having now also read Michael's call for O365 assistance, I start to > earnestly wonder when folks are tired enough of having put their > email fate into the hands of a few mega-large Mail Service Operators > with kafkaesque and

Re: [mailop] 2 questions about BCC and mailing lists

Dnia 31.01.2022 o godz. 19:46:25 Grant Taylor via mailop pisze: > Remember, SMTP servers operate on the SMTP envelope. > > As such, the first SMTP server would send one copy directly to the > recipient's SMTP server and another copy to the MLM's SMTP server. I was assuming that first SMTP server

Re: [mailop] 2 questions about BCC and mailing lists

Dnia 31.01.2022 o godz. 20:16:11 Sebastian Nielsen via mailop pisze: > >>I would say a). > > Why? Then you end up with 3 copies of the email. > > Remember this: > You have sender's server, which we can call ServerA. > > If recipient is yourn...@example.org and list is mailingl...@examplelist.or

Re: [mailop] 2 questions about BCC and mailing lists

Dnia 31.01.2022 o godz. 10:43:52 Geoff Mulligan via mailop pisze: > 1. If a recipient on an email message is both in the To: or Cc: and > on the mailing list, should the listserver send the message to the > recipient: > a) By default > b) Not by default (but configurable) > c) Never

Re: [mailop] [SUBJECT CHANGE] Feedback loops

Dnia 17.01.2022 o godz. 16:41:26 Michael Peddemors via mailop pisze: > > So, while there are many companies with terrible or no abuse > handlers, the problem maybe is now that the other way, where noone > reports it. Speaking for myself, I don't get a lot of spam, but when I do, I don't bother re

Re: [mailop] Best hosting platform was Re: [EXTERNAL] Microsoft IP Filtering - sort of full details

Dnia 16.01.2022 o godz. 19:27:28 Aaron C. de Bruyn via mailop pisze: > Noel isn't the only one who blocks linode. It has been mentioned multiple times on this list that there are mail recipients who block entire particular providers' IP space from sending mail to them (for example Linode, AWS or O

Re: [mailop] [E] Re: What am I supposed to do with abuse complaints on legit mail?

Dnia 11.01.2022 o godz. 19:12:14 Andrew C Aitchison via mailop pisze: > > But yes, if the user downloads the message with something like fetchmail, > then uses thunderbird to read the *local* inbox. In recent Thunderbird versions the support for "movemail" type accounts, ie. local system mailboxe

Re: [mailop] [E] Re: What am I supposed to do with abuse complaints on legit mail?

Dnia 11.01.2022 o godz. 16:57:21 Matthias Leisi via mailop pisze: > >> How would it know the difference if it was Thunderbird, or the user? > > > > You can guess by timing. > > > > If the message is moved to spam folder immediately after being fetched by > > client, then it is an automated filter

Re: [mailop] [E] Re: What am I supposed to do with abuse complaints on legit mail?

Dnia 10.01.2022 o godz. 19:30:02 Dave Warren via mailop pisze: > > How would it know the difference if it was Thunderbird, or the user? You can guess by timing. If the message is moved to spam folder immediately after being fetched by client, then it is an automated filter action. If there is at

Re: [mailop] Roundcube client IPs → dovecot, postfix

Dnia 29.12.2021 o godz. 20:48:25 Noel Butler via mailop pisze: > >I for one look forward to Roundcube building in the option to have > >the web IP included in headers, > > Mark, you do realise, that information *is already there* in the > header, well, for network operators it is, as its encrypted

Re: [mailop] Roundcube client IPs → dovecot, postfix

Dnia 28.12.2021 o godz. 07:17:43 Michael Peddemors via mailop pisze: > > For us, the security value of passing the originating IP to the > Dovecot or SMTP layers for auth restrictions is paramount, as well > as other details on the originating sender. (Country AUTH > restrictions, OS Detection, an

Re: [mailop] What a drag it is sending DMARC reports

Dnia 26.12.2021 o godz. 21:39:36 John Levine via mailop pisze: > > Last time I checked Gmail sends you an SMS with a code you need to provide to > register a new account. It seems to depend on the IP address you are using. I have quite recently registered a few new Gmail accounts from my home Int

Re: [mailop] Ethics Complaint to Princeton (was: Privacy research spam apparently from a grad student at Princeton)

Dnia 19.12.2021 o godz. 14:52:58 yuv via mailop pisze: > > To me, this was a dead-end. The research was in my view morally wrong, > but legally right and I had no leverage other than appealing to the > researchers' morality because the law is flawed. Again: this may be the right moment to get me

Re: [mailop] Ethics Complaint to Princeton (was: Privacy research spam apparently from a grad student at Princeton)

Dnia 18.12.2021 o godz. 10:01:18 yuv via mailop pisze: > Based on the conversation with the researchers so far, I suspect that > they disingenously represented to the IRB their data collection > practice so as not to alert the IRB that humans would be affected. I [...] > Their FAQ is up at

Re: [mailop] What a drag it is sending DMARC reports

Dnia 18.12.2021 o godz. 07:50:19 yuv via mailop pisze: > > Meanwhile, I hear that iMessage, Whatsapp, Messenger, etc. do not suffer > these problem and are a good replacement for internet email. What makes > the difference between them and internet email? You surely know what the difference is.

<    1   2   3   4   5   6   >