Re: [mailop] Mailserver software
On 2024/07/17 00:09, postfix--- via mailop wrote: > P.S.: reply to list only is enough. I don't need > double-copy. only write directly to me if you prefer to > reply privately. Standard etiquette on many technical mailing lists is specifically to CC the sender, as a courtesy to the person being CC'd. (Copies are likely to arrive more quickly, and the way some people filter mail into folders, that way they'll see replies to their own mail - which they're usually more interested in than other list mail - in their inbox rather than just in the list folder). If you want to indicate your preference to not get CC'd, you can set the Mail-Followup-To header to just the list address, many mail clients have a way to do this automaticallly for messages to mailing lists (e.g. "mail.identity.default.subscribed_mailing_lists" in Thunderbird, "subscribe" and "followup_to" in Mutt). The group-reply in most clients uses this. Or just write a note in a signature for list messages. You can't expect everyone to keep track of who doesn't want CCs. (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). ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailserver software
On 2024/07/17 06:34, Andrew C Aitchison via mailop wrote: > On Wed, 17 Jul 2024, postfix--- via mailop wrote: > > > On 2024-07-16 14:36, Bjoern Franke via mailop wrote: > > > Which iPhone / Android clients do you mean? > > > > last time I tested Apple Mail, my IMAP server logged > > requests from Apple's network. > > > > On Android, I do not use Gmail. I use a client that > > pulls regularly the IMAP. The trade-off is battery > > duration: the client wakes up the phone every time it > > checks for email, even if there are no new emails to > > pull. > > IMAP IDLE exists to save the client from polling, by pushing > a notification when a new message becomes available. > > Does that play nicely on phones ? Not entirely, because the mail client needs to stay running to keep the TCP connection active (and send keepalives etc). For those clients where the IMAP connections come from Apple/Google/... they'll use a platform-native messaging system (Apple Push Notification Service, Google Firebase Cloud Messaging) which is used as a channel for notifications for various apps, so there's only one app that needs to wake up for the routine ability to handle push notifications, then other apps only need to wake up when there's work to do. For Android it's still possible to disable battery saving for an app so that it can handle things itself if wanted; AFAIK Apple doesn't allow this any more. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why an SPF hard bounce on ~all ?
On 2024/06/27 17:46, Marco Moock via mailop wrote: > Am Thu, 27 Jun 2024 11:27:53 -0400 > schrieb "Mark E. Jeftovic via mailop" : > > > Why the hard bounce? > > Some postmasters decide not to accept them. IIRC Google had that > behavior in some cases in the past. > I assume this is the case here. Still happens (and not just for forwarded mail). Not sure if it's all cases, but at least we've run into that with @openbsd.org senders including quite recently. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] reverse proxy for smtp client
On 2024/06/24 12:16, Marco Moock via mailop wrote: > Am 24.06.2024 um 12:03:49 Uhr schrieb Alessandro Vesely via mailop: > > > IME, large sending times are often caused by IMAP. Most clients > > operate by first sending the message and then saving it in the Sent > > IMAP folder. Just changing that method to Bcc: halves the time > > required. > > Why should using Bcc: change that the client saves the message in > Draft/Sent via IMAP? You only need to send the message to save once not twice (though that can also be avoided by RFC 4468 "BURL" if supported), and SMTP sending is often queued and done in the background in mail clients, whereas IMAP operations are often done immediately. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] how to stop this spam
On 2024/06/20 10:13, Jeff Pang via mailop wrote: > Hello > > Recently i got a lot of spams like this one: > https://cloud.hostcache.com/spam.eml > > They have two features: > 1. arabic language > 2. from google groups (though i never joined those groups) I've reported a bunch of these over the years, never any response. google don't seem to care. > how can i stop them effectively? (block arabic and google groups?) Yes that's probably the way. Or just block all of google groups if you don't need it. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Cannot send messages to Google Mail users
On 2024/04/24 12:04, Matus UHLAR - fantomas via mailop wrote: > Make sure nobody did spam/mailbomb from your domain while having matching > SPF/DKIM. I guess that could include forwarding of spam messages or > creating mail loop etc. AFAIK forwarding mail into gmail is generally not good for your reputation scores. People that want that are probably better off having gmail pull over pop3 instead. > I also guess you signed into google postmaster > tools and configured your domain. > > https://postmaster.google.com/ That seems rather hit and miss whether it will show you anything. Works fine on my personal domain with fairly low send rates, but after a few months it's still "No data to display at present. Please come back later" for a few work ones with slightly higher (but still not really high) rates. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Aruba Email Servers getting Authenticated SMTP sessions from Google?
On 2024/04/09 09:21, Michael Peddemors via mailop wrote: > Is this something new that Google will attempt to relay out another > companies email servers with authentication? New in 2014 or so. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google unsolicited mail rejected with 421
On 2024/03/14 10:28, Julian Bradfield via mailop wrote: > Their latest daftness (latest in my noticing it, anyway) is > rate-limiting on the basis of too many recipients for a single > message-id, where "too many" varies from 6 to 30. You'd think they'd > never heard of organization mailing lists. Same problem for the openbsd.org mailing lists: "Gmail has detected this message exceeded its quota for sending messages with the same Message-ID. To best protect our users, the message has been temporarily rejected" ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] ECDSA DKIM validation?
On 2023/12/21 11:44, John R Levine via mailop wrote: > > On Thu 21/Dec/2023 10:37:52 +0100 John Levine via mailop wrote: > > > Yes, your code should handle them. No, that doesn't mean you should > > > sign with them. > > > > Yup. The question was why Gmail doesn't /verify/ ed25519 signatures. > > Answering that they do so because it's not necessary to use them doesn't > > sound real. That way, they are damaging the halo of steady innovators > > that their pushing on authentication might evoke... > > Sorry, but I don't understand what you are saying. > > I'm sure that Google has code somewhere that can validate ED25519 > signatures. But that does not mean that it would be a good idea for them to > use that code in production today and try to update their reputation systems > to deal with the dual signing that implies. > > As I've said several times, unless there is a cryptographic problem with > RSA, there is no reason to *use* any other kind of signature. If you've had to talk someone not very technical through adding a DKIM RSA key to a poorly implemented web interface from some cheap DNS provider that doesn't handle long TXT records, you might feel differently. There is often a workaround in that case - using 1024 bit keys - but then there *is* a cryptographic problem. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] script to collect SPF addresses by domain?
On 2023/10/30 20:28, Peter Nicolai Mathias Hansteen via mailop wrote: > > On 30 Oct 2023, at 20:01, Michael W. Lucas via mailop > wrote: > > Hi, > > Trying to not reinvent the wheel here. > > I want to create an allow list of the big providers that retry from > multiple IP addresses. (Spam from them won't be caught by > protocol-level checks like postscreen, it needs rspamd or somesuch). > > It seems that someone surely would have created a "grab the SPF > records and create a list" script, recursing the included > records. Search engines are not useful to find it, though. > > Any pointers? > > > I wrote a piece some years back about just that. > > Assuming you are running on OpenBSD or other system that has a recent-ish > OpenSMTPD, you could > use OpenSMTPD's "smtpctl spf walk" 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 produce a complete list like this. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] New Gmail sender guidelines
On 2023/10/11 15:05, Giovanni Bechis via mailop wrote: > Hi, > starting from 02/2024 Gmail will require authenticated email for senders who > send 5,000 or more messages a day to Gmail accounts. > However, authenticated email requirements seems to have started today, in the > past days those email messages where temporary rejected, starting from today > I have the following error message: > 550-5.7.26 This mail has been blocked because the sender is > unauthenticated.5.7.26 Gmail requires all senders to authenticate with either > SPF or DKIM.5.7.26 5.7.26 Authentication results:5.7.26 DKIM = did not > pass5.7.26 SPF [domain.tld] with ip: [1.2.3.4] = did not pass5.7.26 5.7.26 > To mitigate this issue, please visit Gmail's authentication guide5.7.26 for > instructions on setting up authentication:5.7.26 > https://support.google.com/mail/answer/81126#authentication > z20-20020a05600c0a1400b004068c7a951csi7296094wmp.167 - gsmtp I've had this start recently (a couple of weeks maybe?) to @gmail.com addresses (though not other google-hosted domains, e.g. @googlemail.com, yet) - sending far less than 5k/day their way. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] IPv6 capable servers send with IPv4 to me
On 2023/10/06 13:08, Marco via mailop wrote: > Am 06.10.2023 schrieb Bjørn Bürger via mailop : > > > 15 yrs ago I would have agreed to Wietse Venemas view, but nowadays > > this kind of "solution" is just adding confusion and makes debugging > > harder for everyone, unfortunately. > > And sadly it creates a comfortable solution for admins of non-functional > networks instead of fixing stuff. As does the standard mechanism used in browers for dealing with the same type of situation. RFC 8305 9.3 has a suggested approach to dealing with this. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] IPv6 capable servers send with IPv4 to me
On 2023/10/06 11:13, Marco via mailop wrote: > Am 06.10.2023 schrieb Stuart Henderson : > > > Networks single-homed behind cogent can't connect to networks > > single-homed behind he.net and vice-versa. > > Is that related to PMTU-blackhole? > Who is guilty for that? > Why isn't that going to be fixed? No, that's due to commercial policies of the companies. Nothing to do with PMTU-blackhole in that case. It's been like it for years. (And btw, MTU issues with PMTU blackhole mean that the connection can succeed but delivery fails - so using a short connection timeout does not help). In any event, even without any of these problems, it is easily possible to have an outage which affects only one of v4+v6. It's nice to still have semi-working email when that happens (especially if email is needed to get such an outage fixed!) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] IPv6 capable servers send with IPv4 to me
On 2023/10/06 11:01, Marco wrote: > Am 06.10.2023 schrieb Stuart Henderson : > > > On 2023/10/06 10:09, Marco via mailop wrote: > > > Hello! > > > > > > I have an IPv6 and IPv4 accessible server, both protocols work and I > > > receive mails with IPv6 too. > > > Although, I see that certain IPv6 capable servers send with IPv4 in > > > some cases. > > > I am not aware of any outages and the strange things is it is rather > > > random which protocol they use. > > > > > > relay=mx.mailop.org [91.132.147.157] #never sent me mail via IPv6, > > > but I can send to them via IPv6 > > > relay=bendel.debian.org [82.195.75.100] > > > relay=bendel.debian.org [IPv6:2001:41b8:202:deb:216:36ff:fe40:4002] > > > > > > What can be the reason for that? > > > > Postfix balances address families by default to avoid blockages if one > > isn't working: > > Isn't a timeout of some seconds enough for that? > > Most people have a working connection and most servers too. Define "working"... There are still more MTU blackhole issues with v6 than v4. Networks single-homed behind cogent can't connect to networks single-homed behind he.net and vice-versa. There can be different treatment by spam filtering etc (even if purely by virtue of one address family having working reverse dns and the other not). And it works both ways: v6 may be working but v4 not. > > 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 works? > > Then that explains the behaviour. Default is to select randomly (see the postconf(5) sections that I linked). > > Perhaps some other MTAs have similar too. > > All of the MTAs that create that effect use Postfix, so it seems to be > related to it. Perhaps it is the only one with the balancing feature then.. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] IPv6 capable servers send with IPv4 to me
On 2023/10/06 10:09, Marco via mailop wrote: > Hello! > > I have an IPv6 and IPv4 accessible server, both protocols work and I > receive mails with IPv6 too. > Although, I see that certain IPv6 capable servers send with IPv4 in > some cases. > I am not aware of any outages and the strange things is it is rather > random which protocol they use. > > relay=mx.mailop.org [91.132.147.157] #never sent me mail via IPv6, but > I can send to them via IPv6 > relay=bendel.debian.org [82.195.75.100] > relay=bendel.debian.org [IPv6:2001:41b8:202:deb:216:36ff:fe40:4002] > > What can be the reason for that? Postfix balances address families by default to avoid blockages if one isn't working: https://www.postfix.org/postconf.5.html#smtp_address_preference https://www.postfix.org/postconf.5.html#smtp_balance_inet_protocols Perhaps some other MTAs have similar too. Some admins disable delivery over v6 completely because some receiving sites are suspected to apply more stringent checks to mail coming in over v6. Some just do this for specific sites (e.g. as shown in https://www.postfix.org/postconf.5.html#smtp_dns_reply_filter), some for everything. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google groups spam
On 2023/02/16 07:17, MRob via mailop wrote: > Forgive if its already been discused but is googel already aware of ongoing > Google Groups spam? Will they stop this? Lots of recurring mails with arabic > subject and body from nonsense group names like "hghgjhghjgb": > > hghgjhghjgb+@googlegroups.com They should be, it has been reported to them enough times over the years. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] IBM: [to unsubscribe] please enter your first, last name, email and country
On 2022/12/06 16:43, Michael Peddemors via mailop wrote: > > People who 'gather' or require information on the opt-out pages, even if it > is just the email address (you already sent to our email address) And this is made worse because there are plenty of cases where the recipient won't know the exact address that the email was sent to. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
On 2022/11/21 13:55, Taejoong (tijay) Chung via mailop wrote: > Please note that we do NOT collect any personal information, thus > the Institutional Review Board (IRB) at Virginia Tech determined the > survey as Non-Human Subjects Research. eh, that doesn't make any kind of sense. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] tls certificates
On 2022/11/21 10:07, Julian Bradfield via mailop wrote: > So my question is, if it is certificates (rather than ciphers - my > cipher suites are all gnutls default, so should be current), what do I The type of alert should indicate ahether it's ciphers or certs. > need to do to get everybody to accept TLS ? Just make the certificate > match the machine name, or do I need to get letsencrypt certificates In the absence if MTA-STS most senders will use an unvalidated cert on the basis that encryption is usually better than no encryption, though obviously this doesn't do anything to guard against MITM. Any checks beyond this are going to depend on how the relevant sending host is configured, so it's not really possible to give general advice. > for it? Do TLS clients follow CNAMEs to find the server hostname? That > is, do I need a certificate with SANs for every name that might be > used to contact the machine, or just for the name it presents at SMTP > session start? They don't follow CNAMEs. So if you have a bunch of domains with say "example.com MX 0 mail.example.com" and an A record for mail.example.com, if you can do so it's probably more straightforward to change them to "MX 0 mail.someprovider.example" and cut down on the number of SANs (each of which will need to be verified by the cert issuer..) (If you do get CA-signed certs, don't forget to configure your servers to present the intermediate aka chain cert to clients as well, that's probably the most common thing which causes validation problems). ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Odd DNS-cache avoidance queries (Spam Assassin / Unbound / AWS)
On 2022/09/13 09:20, Cyril - ImprovMX via mailop wrote: > Nice! Good catch about the dns-0x20 implementation! I must have copy/pasted > some properties > without looking much into it. That is unlikely to be causing an actual problem here though. > > 2. The other issue is even weirder. SA is trying to validate the > domains by > > trimming the left part up to the gTLDs : > > > > > > - some.domain.com._custom_id.df.uribl.com > > - domain.com._custom_id.df.uribl.com > > - com._custom_id.df.uribl.com <-- wtf? > > > > Somehow, something is trying to check up to the top TLD, where it's > > useless. Again, I can't understand why SA would do that. > > This is probably unbound doing what it does, recursive resolving (from > TLD all the way down). > > Is there a way to avoid unbound to fetch the root tld ? (just "com") ? That's qname-minimisation, which these days is enabled by default in at least unbound and BIND. It improves privacy by avoiding sending the full query name to parent DNS servers. In your example, without qname-minimisation you'll occasionally see queries including "_custom_id" sent to one of the .com nameservers i.e. *.gtld-servers.net. With qname-minimisation those queries which include "_custom_id" will only get sent to uribl.com's nameservers. See more in https://www.isc.org/blogs/qname-minimization-and-privacy/, RFC 7816, and others. One would have thought that operators of a DNS-based service would have known about these already though... ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on IMAP and SMTP.
On 2022/08/19 10:31, Brandon Long via mailop wrote: > > Who thinks managing and refreshing client TLS certificates is easier than > OAUTH2? It's certainly easier than getting client IDs registered with whichever providers might be used. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on IMAP and SMTP.
On 2022/08/20 06:55, Alexander Huynh via mailop wrote: > Shameless plug: this discussion has gotten me to open-source my Office 365 > OAuth script, which should be plug-and-play compatible with mail systems > that can run python3 scripts and receive XOAUTH2 JWTs via stdin. > > If you'd like to give it a try, visit > https://github.com/ahrex/oauth-helper-office-365 > > There's an example mutt integration, which I'm currently using to compose > this very email. "# borrow Mozilla Thunderbird's client information" Ha, well that's one way to work around one of the major problems with using OAuth2 with simple tools! ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on IMAP and SMTP.
On 2022/08/19 09:08, Gellner, Oliver via mailop wrote: > Hello, > IMAP, SMTP etc are still being supported with Office365. What gets > disabled is Basic Auth for some services. Microsoft announced the > decomission of Basic Authentication three years ago and all tenant > administrators have been notified several times in the meantime about > this change. Originally the change was planned for 2020, but due to > interoperability issues it got postponed until 2022. So while I'm no > Microsoft fellow I don't think anyone should be caught unprepared. The interoperability issues have not been fixed though. > If you need POP3 or IMAP4 access with Basic Auth, then you can either > put a proxy or other email server in between which speaks Basic Auth > on one side and OAuth on the other. That proxy will have the same issue as seen by other tools accessing the OAuth2-only services. Hideously complicated configuration, having to keep tokens refreshed, etc. It would seem sensible for operators who want to require something stronger than basic authentication to have a way to use TLS with client certificates as an alternative to OAuth2, it would be a lot more straightforward to handle on the client side. Unless they have other motives. It's not really surprising to see this exact thing mentioned on https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] I understand less and less why I accept any mail at all from Sendgrid
On 2022/08/16 02:03, Ángel via mailop wrote: > On 2022-08-13 at 18:46 -0400, John Levine wrote: > > Subject: IP address blacklisted(Child Pornography Act 1996 violated) > > > > Hello, > > > > We have found instances of child pornography accessed from your IP > > address. This is a punishable offence under The Child Pornography > > Prevention Act of 1996 . For now we are blacklisting your IP address > > and if there is any further action from Microsoft you will be > > informed via email. > > > > If this was not you and you suspect potential hack or id theft > > contact Microsoft Support Team at +1-808-460-7701 > > > > Microsoft Support > > +1-808-460-7701 > > > > support > > This is probably "just" a tech support scam. I have seen others on a > similar theme, but claiming to be sent from the national police and > asking you to provide your allegations to an email address. Presumably > in order to get replies of those gullible enough to believe it and pay > a "fine" and, one would guess, hunting in case someone admitted > something worth being extorted about. yes yes, but the point is that Twilio SendGrid are allowing their services to be used by whoever is sending this. With a website saying things like "We take trust and security seriously" and "With the industry’s largest team of delivery experts monitoring your sender reputation" they don't pick up on this? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication
On 2022/08/03 14:01, Jarland Donnell via mailop wrote: > > The MTA-MTA encryption is weak at best: because the client doesn't > > (can't, actually) verify that the certificate is appropriate for that > > MTA, any MITM attack is easily accomplished. End users get virtually no > > indication that the message was or wasn't encrypted in transit, and > > there is no accepted mechanism to force encryption in the first place. > > Why can't an MTA verify a certificate? Postfix seems to do certificate > verification, for example: > https://www.postfix.org/TLS_README.html#server_vrfy_client That's talking about client certificates which is a different matter than the client verifying the server's certificate. I think when acting as SMTP-over-TLS clients, most MTAs out there are not checking the server's certificate in any really meaningful way; they can usually be configured to do so but, last time I looked, there were plenty of expired certs, mismatching host names, and self-signed certs, and based on what I've seen with web servers I'd expect to see more than a few with valid CA-signed certs, but with no chain cert presented. Turning this on for general use (rather than for specific destinations) would seem likely to result in a lot of failures. Without cert verification, there seems little point in requiring stronger TLS versions. Rather than trying to break a weaker encryption protocol (usually still relatively hard) an attacker could MITM with their own cert. FWIW https://www.postfix.org/TLS_README.html#client_tls_verify shows how to enable this for Postfix, but very much recommends against it on the internet for now. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Question for Google -- how am I able to be added to google groups without opting in?
On 2022/07/02 20:00, Suresh Ramasubramanian via mailop wrote: > Spammers in the middle east and Pakistan seem to love doing this. I finally > set my google > settings to “don’t add me to any google group without my requesting to join > it” and that solved > the issue, at least from the POV of my not receiving it. They’re running > riot all over > googlegroups and have been for years now. That doesn't help unless you have a google account for every address which you might receive mail at. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] No MX? use A/AAAA
On 2022/06/20 15:39, Jarland Donnell via mailop wrote: > 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 That is not what mx_check does at all. It looks for MX _or A_ records and (if not already cached) tries connecting to them to see if something answers on port 25. https://github.com/rspamd/rspamd/blob/master/src/plugins/lua/mx_check.lua#L193 ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Question for Google -- how am I able to be added to google groups without opting in?
On 2022/06/16 19:42, Jaroslaw Rafa via mailop wrote: > However, I am not sure if Google Groups sends an email to the user who is > being added informing him/her about that if you do not enter any "welcome > message" in the appropriate field when adding users. In my opinion, for > users who are added without being asked for confirmation it definitely > should send such an informational message, and it should be impossible to > turn it off. But I don't know how does it look like in reality. I had a spate of these a few years ago, exactly the same type of groups as mentioned here, and with addresses probably harvested from an OpenBSD-related source in my case. It was difficult to search for the right place to report the group from a logged-in google account (the addresses that were added didn't have a google account themselves), it would have helped a lot if there was either a welcome message or a footer added to group messages, with a link to report abuse. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why TLS is better without STARTTLS
On 2021/08/10 10:28, Andrew C Aitchison via mailop wrote: > On Mon, 9 Aug 2021, Thomas Walter via mailop wrote: > > > https://nostarttls.secvuln.info/ > > > > Their conclusion is that all vulnerabilities rely on the transition of > > an insecure connection to a secure connection. > > If possible, we recommend that users check and configure their email > clients to use SMTP, POP3 and IMAP with implicit TLS on dedicated ports, > i.e., SMTP/Submission on port 465, POP3 on port 995, and IMAP on port 993. > This is in line with already existing recommendations in RFC 8314 and was > already recommended by security professionals before. > > It is a pity that 587 is the offical smtp submission port > whilst TLS-on-connect port 465 is merely "traditional". 465 was made official before the above-mentioned RFC was published. https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=submissions ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] free.fr / tdsnet.com / zeelandnet.nl bounces
On 2021/08/06 11:31, Stephen Frost via mailop wrote: > Greetings, > > We have quite a few folks with @free.fr addresses, and a few with the > other domains listed in $subject, on the @postgresql.org mailing lists > and recently we've started getting bounces back for some of the emails > we send out, claiming they're spam (which they certainly aren't). > > If this continues, we're going to have to unsubscribe them all, but > figured I'd reach out here first to see if there's any free.fr admins > (or those for the other domains, though we have just a few of those) > paying attention who could help us figure out why these emails are being > classified as spam and help us work to a resolution. > > These emails from coming from 217.196.149.56 / > 2a02:16a8:dc51:0:0:0:0:56, SPF matches, DKIM signed, passes DMARC, etc. > Our best guess is that the ones being marked as spam have too many URLs > or some other silly measure that's tripping up a poorly designed spam > filter. Whether a message passes DMARC or not depends on the From: address in the email headers. Unless you rewrite that (which looking at the archives it doesn't appear you do) you'll see rejections from some sites if that domain publishes a p=reject policy. Could it be due to that? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Outlook strange behavior from Outlook.com (not a surprise... but...)
On 2021/06/16 09:04, Xavier Beaudouin via mailop wrote: > Hello there, > > I have a setup with 2 MX : > > domain.tld mx 10 mx1.domain.tld > domain.tld mx 30 mx3.domain.tld > > For some operational reason mx3 replys all mail with a 454 which is TEMPORALY > error... : > Jun 14 23:22:55 mx3 postfix/smtpd[83891]: NOQUEUE: reject: RCPT from > mail-eopbgr50127.outbound.protection.outlook.com[40.107.5.127]: 454 4.7.1 > : Relay access denied; from= > to= proto=ESMTP > helo= > > It trys about 31 times But they didn't had the idea to check the mx1... > which is ready for relay. You can't tell for certain that they didn't check the mx1. Perhaps there was a network error. Sometimes route announcements don't make it to the whole world, sometimes packets to some hosts but not others end up on a broken member of a load-balanced port group. Related, note that some SMTP software doesn't fall to a lower priority MX if the higher priority one connects but rejects with temporary failure. Things work best if all listed MX that accept connections are prepared to accept mail. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DANE for SMTP Survey
On 2021/06/10 15:48, Moritz Müller via mailop wrote: > Together with researchers from Seoul National University, Virginia Tech and > the University of Twente, we would like to understand which challenges > operators face when deploying DANE for SMTP. > Also, we would like to understand how operators deploy DANE successfully. > Finally, we want to develop solutions to simplify DANE deployment for SMTP. > > Filling out the survey should take between 10 and 20 minutes. > We would highly appreciate your participation. > > https://forms.gle/PPfULBH4Smwm6mSc8 > > Don’t hesitate to drop me a mail if you have questions or remarks. > We’ll share the results with the list after evaluation. If my certificate validity is 90 days and 1 second, should I choose "1 <= N < 3" or "3 <= N < 6"? ;-) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Greylisting never passing on retry
On 2021/04/21 10:23, Neil Youngman via mailop wrote: > On 21/04/2021 11:00, Chris wrote: > > Aside from the possibility that the message is simply wrong, or the > > implementation broken, is your mail server acting like most other > > servers when presented with a failure (soft or hard)? > > > > Your posting seems to be that you give up after the second try. > > > > Most servers will try at least 5 times for such, only giving up after > > hours (sendmail defaults at 4 days). > > It doesn't behave exactly like a normal mail server, but it does retry > more than five times. Not all retries are from the same IP, but I have > observed that retries from the same IP don't get delivered. > > Neil Youngman Retries from different IPs (even within the same /24 or so) will certainly cause problems for some greylisting software. Also make sure the addresses used in SMTP are identical for each try (say, not changing the sender address etc.) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Greylisting never passing on retry
On 2021/04/21 12:55, Tim Bray via mailop wrote: > Like fire up an exim? This exim? https://www.openwall.com/lists/oss-security/2021/04/21/1 "The current Exim versions (and likely older versions too) suffer from several exploitable vulnerabilities. These vulnerabilities were reported by Qualys via secur...@...m.org back in October 2020. Due to several internal reasons it took more time than usual for the Exim development team to work on these reported issues in a timely manner." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] GMail DKIM support for ed25519-sha256
On 2021/04/15 10:58, Odhiambo Washington via mailop wrote: > > On Tue, Apr 13, 2021 at 6:44 PM Stuart Henderson via mailop < > mailop@mailop.org> wrote: > > I don't know specifically about gmail, but generally support for > ed25519 > in DKIM is still a bit lacking, I think the advice for this is > still to > dual-sign. > > > How does dual-signing work? Sorry to sound so ignorant, but I am only > hearing about dual-signing for the first time. Just like it sounds, add two DKIM headers, one signed using RSA, one using ed25519. Different selector (s=), same domain/identity (d=/i=). It's easy using rspamd for signing, example in the documentation. For opendkim it seems like you need to use lua scripting to achieve this (there's https://github.com/trusteddomainproject/OpenDKIM/issues/6 with a request for a built-in way to do this, issue is open since 2018). ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] GMail DKIM support for ed25519-sha256
On 2021/04/13 11:11, Wolfgang Rosenauer via mailop wrote: > Hi, > > I'm seeing issues with GMail not recognizing a valid DKIM signature. > > Message is correctly signed like: > DKIM-Signature: v=1; a=ed25519-sha256; > > GMail reports > dkim=neutral (no key) > > while most DKIM validators (incl. dmarcian) are totally fine with the > provided key. > The only reason I could imagine is the key/hash format but I haven't seen > any official documentation from GMail if ed25519-sha256 is supported or not. > > Any ideas or recommendations? I don't know specifically about gmail, but generally support for ed25519 in DKIM is still a bit lacking, I think the advice for this is still to dual-sign. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Autoresponder for EAI mail
On 2021/02/04 16:20, John Levine via mailop wrote: > Is anyone aware of autoresponder code that works with UTF8SMTP mail? It's > not hard > to write one, but why reinvent a wheel if I can steal the code. Not sure about this, but.. > Also, has anyone ever written down in one place the best practices for > doing a non-annoying autoresponder? Things like only respond if you're > on the To: or Cc: line, don't respond to anything with a List-* or > Precedence header, and rate limit responses. there's RFC 3834 ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Current OSS anti-spam software best practice?
On 2020/12/16 09:03, Dr. Christopher Kunz via mailop wrote: > We are still using Spam Assassin on our main setup, but I feel that it's not > aggressive enough to cope with current spam patterns, especially with > regards to its rather conservative bayesian learning parameters. > > Is it generally being superseded by other OSS solutions, or should I be > looking into fine-tuning it? It's a shared cluster, so per-mailbox bayesian > learning is an important feature for us. Another +1 for rspamd. It is pretty good even with close-to-default configuration. > Is it generally best practice to also scan all outgoing e-mail on a shared > e-mail cluster for spamminess? It is definitely helpful to pass outgoing mail through the same system in order that it can watch message-ids and reduce score for replies to locally originated mail. It's also a good place in the pipeline to sign dkim if needed. Whether to have it score outgoing mail for spaminess really depends on local policies. Even if it's not blocking anything it maybe useful to have it as an alerting mechanism to pick up on potentially dubious accounts. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] open RBL and RHSBL lists these days?
On 2020/12/15 00:28, Mary via mailop wrote: > > Indeed, I am not blocking it for two reasons: > > 1) I was never sure why 50% of all gmail spam seem to originate from > trix.bounces.google. > > 2) The other 50% has regular gmail received headers. > > > For example, trix.bounces.google spam contains: > > Return-Path: > <3sczsxwkjcfci8xprvytq5bz7a.1db27b7ig7hb7163a7cz97h...@trix.bounces.google.com> > (envelope-from > <3sczsxwkjcfci8xprvytq5bz7a.1db27b7ig7hb7163a7cz97h...@trix.bounces.google.com>) > smtp.mailfrom=3sczsxwkjcfci8xprvytq5bz7a.1db27b7ig7hb7163a7cz97h...@trix.bounces.google.com AFAIK it's connected to google forms and *sometimes* has legit mail. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] scam prevention
On 2020/12/08 13:09, Tim Bray via mailop wrote: > On 08/12/2020 12:32, Mary via mailop wrote: > > A solid idea, but you would have to avoid modifications to DKIM signed > > emails that sign the From header field via the h= tag as specified by > > RFC6376 secton 5.4 and 5.4.1. > > They aren't going to go any further once they will come in. So I don't > think any further DKIM checks will be done. > > I'll DKIM check and then make the change before it drops into the mailbox. > > -- > Tim Bray > Huddersfield, GB > t...@kooky.org > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop Not a bad idea at all. I have seen quite a few places that add [EXTERNAL] or similar to subject lines for this too (you'll see some examples in posts to this list). ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] New server email being treated as spam by Google
On 2020/11/21 13:59, Thomas Walter via mailop wrote: > Hello, > > On 21.11.20 12:54, Jaroslaw Rafa via mailop wrote: > > You can configure your MTA to disable IPv6 only for delivery to Google - at > > least with Postfix it should be possible. > > how would one do that? https://marc.info/?l=postfix-users=149964217524463=2 (and for Exim there's dns_ipv4_lookup). ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] New server email being treated as spam by Google
On 2020/11/19 13:47, Paul Waring via mailop wrote: > On Thu, Nov 19, 2020 at 01:29:48PM +, Chris Woods wrote: > > I dropped the TTL on the MX, SPF, DKIM and DMARC records to 300 about 36 > > hours before starting the migration, and published the new DKIM key as > > well. I left the records at 300 for about 72 hours after the migration > > and then moved them up to 3600. > > > > > > Correct the PTR, it's currently "romana.vs.mythic-beasts.com". > > I'm not sure what's wrong about the PTR? > > 1. The hostname of the machine is romana.vs.mythic-beasts.com > > 2. The hostname used in HELO is romana.vs.mythic-beasts.com > > 3. The MX record for xk7.net is romana.vs.mythic-beasts.com > > 4. romana.vs.mythic-beasts.com has an A record and record > > 5. The IP addresses in the A & records have PTR records to > romana.vs.mythic-beasts.com > > Isn't that the correct way to have things? That all looks right. No idea how things work in gmail with keys, but it may be better to use the original DKIM key? That would provide some kind of continuity original from th server/IP to the new one, whereas now you have new IP *and* new key at the same time. If you're sending into them over v6 I would disable that too, most of the common open source MTAs have a feature to prevent sending over v6 exactly because of gmail. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is DNS-over-HTTPS bad? Sure.
On 2020/07/07 10:27, Noel Butler via mailop wrote: > On 07/07/2020 01:01, Johann Klasek via mailop wrote: > > > I have been told that DoH is set into place to solve the privacy > problem. On a small DNS workgroup meeting I saw a presentation on how > they statistically identify users by their DNS traffic, and could create > a profile with interests and affectations these users have. I think DNS > is not that anonymous one would expect. > > > > Don't you think there is more chance of a perfect picture of you being built > from, ohh i dunno, > long standing things like, netflow :) > > It will tell me a whole lot more about you than any DNS query could. Straying a bit off-topic but, with traditional DNS requests are often aggregated first with other devices in your house/company by a local forwarder or NAT, then again at your ISP with their other customers, before being passed on to other servers with whom you don't have a customer relationship. Looking at netflow data, it's at least aggregated with other devices behind the same NAT IP, and a lot of it is just "tcp 443 to cloudflare" or whatever which tells a lot less than DNS query data. With DoH the query stream immediately goes to somewhere that often you don't have a customer relationship, and is separated nicely per-application (not even per-device), so yes a DNS provider very often does get a better picture of you than an ISP would have from netflow data. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)
On 2020/06/04 12:05, Andrew C Aitchison via mailop wrote: > On Thu, 4 Jun 2020, Benoît Panizzon via mailop wrote: > > [ Not replying to the list as this may be off topic, > but you are welcome to bring it back on list if you wish. ] Unfortunately this is one of those mailing lists using modern software that messes with From headers so that doesn't always go so well :) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Force double opt in for marketing list companies per email address
On 2020/06/02 14:35, Tim Bray via mailop wrote: > My question to mailchimp et al: > > Is there way I could force my email address to be double opt in? Like > register with you, confirm my address, and then any of your customers who > try to add me, I get a `please confirm` email. This, but without the "have to register" bit ... ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Google: 'Low reputation of the sending domain'
On 2020/06/02 10:37, Benoit Panizzon via mailop wrote: > <<< 550-5.7.1 [2001:4060:dead:beef::1 19] Our system has detected that > this > <<< 550-5.7.1 message is likely suspicious due to the very low reputation of > the > <<< 550-5.7.1 sending domain. "due to the very low reputation of the sending domain", I'm surprised that made it through legal... > DKIM is not a solution. I faced too many problems with mailinglists > and similar which did alter the header and broke DKIM signatures. DKIM isn't (or at least shouldn't be) used as an absolute check unless it's combined with a restrictive DMARC setting - usually it just feeds in to an overall score. Failing DKIM doesn't mean that people won't see a mail at all and when combined with other positive scores usually assigned to genuine mailing list servers, it will often still get through. You are likely to need all the tricks in the book to get mail delivered over IPv6 into gmail (many people just gave up - most of the common open- source MTAs have methods to avoid delivering over v6 to certain servers precisely because of this) - DKIM definitely seems to be something worth doing. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] MX fallback and TLS problems
It seems that if gmail has a problem making a TLS connection to the highest priority MX, it does not fallback to lower priority ones. Is this common with other senders too? ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] mailbox auth for system integration
On 2020/02/07 14:36, Philip Paeps via mailop wrote: > On 2020-02-07 14:32:50 (-0800), Stuart Henderson wrote: > > On 2020/02/07 13:41, Philip Paeps via mailop wrote: > > > I think the only viable solution will be to set up forwarders > > > > Or pass it through a proxy which knows how to authenticate. I'm not > > aware of any that have been written yet but it shouldn't be too complex. > > It sounds like we have about one year for that to happen before people lose > access to their email. I don't think that will be a problem. > > > Unless fetchmail starts supporting Oauth, I will lose access to > > > certain customer mailboxes when Google decides to stop accepting > > > "app passwords". > > > > Do you need to use fetchmail? getmail has supported that for some time. > > (fetchmail development code supports oauth2, but it isn't in a release > > yet). > > I'm not married to fetchmail. I had never heard of getmail. If it supports > oauth completely unattended, that would solve my use case. I'll look into > it more closely. Thanks for the pointer. > > As far as I understand it though, oauth requires a human operator and a > webbrowser to generate the tokens. I wonder how getmail satisfies that > requirement. Only when initially granting permissions for a client to access (or if permissions were revoked and you need to grant them again). Otherwise it's automatic, you definitely don't need a human operator for each login. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] mailbox auth for system integration
On 2020/02/07 13:41, Philip Paeps via mailop wrote: > I think the only viable solution will be to set up forwarders Or pass it through a proxy which knows how to authenticate. I'm not aware of any that have been written yet but it shouldn't be too complex. > Unless fetchmail starts supporting Oauth, I will lose access to certain > customer mailboxes when Google decides to stop accepting "app passwords". Do you need to use fetchmail? getmail has supported that for some time. (fetchmail development code supports oauth2, but it isn't in a release yet). ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] +-addressing support
On 2020/02/06 17:02, Bill Cole via mailop wrote: > On 6 Feb 2020, at 16:04, Jaroslaw Rafa via mailop wrote: > > > Dnia 6.02.2020 o godz. 12:43:52 Philip Paeps via mailop pisze: > > > > > > Why are there still setups in 2020 that don't support this? > > > > Especially that all main MTAs have been supporting this "since > > always"... > > Sendmail has supported this since quite old releases, Postfix probably > > was > > supporting it from the beginning... Same for Exim. As far as I know, in > > sendmail and Postfix it is even turned on by default (don't know for > > Exim, > > as I used it very little). > > The support in some MTAs and MDAs for treating "+" and/or other characters > as delimiters between a primary local-part and a 'tag' is an entirely local > matter and should never be presumed by any sender. The '+' is in no way > special to SMTP. Exactly. So websites and others should not block their use in addresses - but many do. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Abandoning self hosting and moving to Protonmail - experiences?
On 2020/01/27 13:57, Lennert Van Alboom via mailop wrote: > Alternatives? fastmail ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] suddenly sendmail cannot make tls connections
On 2020/01/24 21:07, John Covici via mailop wrote: > So, I have now solved the problem (sort of). On my other box, I had > no trouble connecting to at least one of those servers and so I had to > figure out why. So, I looked at the /etc/ssl/openssl.cnf and compared > them on both systems and discovered that on the one which could > connect it seems that the seclevel was 2 whereas it was not specified > at all on the system which had trouble. So, it seems that it had > nothing to do with sendmail at all, but everything to do with the > ciphers in some way. I will have to look in to that seclevel and see > what it actually means, but at least its working for now. Others will run into this problem too. Changing your seclevel setting is a workaround but please let the server admins know, if they switch to 2048-bit DH parameters it should fix things for seclevel=2. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] mx abuse listed in spamhaus?
On 2020/01/14 12:32, Laura Atkins wrote: > > On 14 Jan 2020, at 11:58, Stuart Henderson via mailop > wrote: > > On 2020/01/14 11:37, Ken O'Driscoll via mailop wrote: > > On Tue, 2020-01-14 at 10:44 +, J Orlando Letra via mailop wrote: > > does any one have this problem? > > > > As per https://www.abuseat.org/lookup.cgi?ip=64.57.183.53 the IP was > detected sending or relaying IP traffic which matches a known virus > botnet > signature. In this case the "ranbyus" virus. > > Something is infected. > > Once you have cleaned up your server / site you can request removal > from > the list at the end of that page. Be aware, that if you do not clean > your > site before requesting de-listing, your IP may be permanently > re-added to > the list with no option to remove it. > > > So if somebody has access to send from a certain IP address and is able > to trigger connections to a sinkhole, get it listed, then request > de-listing and then connect to the sinkhole again, they may be able > to get that address permanently added with no option to remove? That > sounds sub-optimal. > > > That’s not what happens. What happens is, if the CBL sees an IP repeatedly > delisted without any > change in the IP behavior then the option to request automatic delisting is > removed for that > IP. In order to delist an IP the IP address owner (or someone working on > their behalf) will > need to directly contact the folks at abuseat.org for manual delisting. Ah, so there is an option (manual delisting) - that's quite different (and considerably less worrying) than "no option to remove it". > I’d also posit, that if someone has access to your IP addresses sufficient to > get it listed on > the CBL, they also have access to your IP addresses sufficient to send > malware or other > problematic traffic through it. This is not exactly a compelling argument. I was thinking of it from the other way - if someone who is controlling malware running on a system has a way to _permanently_ get an address blacklisted, that's a problem. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] mx abuse listed in spamhaus?
On 2020/01/14 11:37, Ken O'Driscoll via mailop wrote: > On Tue, 2020-01-14 at 10:44 +, J Orlando Letra via mailop wrote: > > does any one have this problem? > > > > As per https://www.abuseat.org/lookup.cgi?ip=64.57.183.53 the IP was > detected sending or relaying IP traffic which matches a known virus botnet > signature. In this case the "ranbyus" virus. > > Something is infected. > > Once you have cleaned up your server / site you can request removal from > the list at the end of that page. Be aware, that if you do not clean your > site before requesting de-listing, your IP may be permanently re-added to > the list with no option to remove it. So if somebody has access to send from a certain IP address and is able to trigger connections to a sinkhole, get it listed, then request de-listing and then connect to the sinkhole again, they may be able to get that address permanently added with no option to remove? That sounds sub-optimal. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] G-Suite removing LSA functionality
On 2019/12/16 12:42, Brandon Long via mailop wrote: > As for tools, last year I added support for OAUTHBEARER to mutt but by > shelling out to https:// > github.com/google/gmail-oauth2-tools/blob/master/python/oauth2.py for > generating tokens. The > sasl level code to send the tokens is pretty trivial, the annoying part is > launching a browser > and getting the token back from it. This works fine, though it would be nice if one of the (so far) three PRs adding Python 3 support to gmail-oauth2-tools could be merged :-) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Can someone write me a prescription for a sane MTA? I'm allergic to Postfix.
On 2019/12/10 08:31, John Covici via mailop wrote: > So, what would be an appropriate replacement for procmail, I think in > my distro its a hard dependency of sendmail, but maybe there is > something better? If you use software which already implements Sieve (Dovecot and Cyrus are probably the most common), it's often convenient to just use that. If not, there are other programs which act as stand-alone delivery agents - the ones I know of are maildrop (which is normally used with Courier mail server but can also work standalone), and fdm (which is mostly used as a pop3/imap fetcher but you can also configure an "stdin" account type which you can use as a standard delivery agent). ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Can someone write me a prescription for a sane MTA? I'm allergic to Postfix.
On 2019/12/09 14:16, Jaroslaw Rafa via mailop wrote: > Well... I'd rather do such things in procmail Be aware, procmail's last maintainer said, "the code is not safe and should not be used as a basis for any further work". https://marc.info/?l=openbsd-ports=141634350915839=2 ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Moving to a new outbound IP range
On 2019/07/01 15:39, Ken O'Driscoll via mailop wrote: > On Mon, 2019-07-01 at 12:55 +0100, Simplelists - Andrew Beverley via mailop > wrote: > > Would it be better to go for the brand new block? Obviously any > > existing block could be checked in DNSBLs etc, but are there any > > advantages of using an existing block? > > The lack of historical RBL listings is nowhere close a definitive > indication that the IP space wasn't used for abusive purposes at some > point. BGP hijacking, malicious site hosting, hijacked POS endpoints etc. > all get clocked in databases, some of which have long memories and are not > publicly available. It's often not immediately obvious that such a range > has a poor reputation somewhere so you end up wasting time etc. > > A new direct allocation has zero reputation, good or bad. > > If you are lucky enough to have the option, my preference would be to go > for a new allocation since it removes some variables. A brand new allocation could still have been illicitly announced into BGP before and acquired a bad reputation that way. Though AFAIK it's too late for brand-new space in the RIPE region, I think they're just reallocating reclaimed address space now. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] CVE-2019-10149 Exim 4.87 - 4.91 possible remote exploit
On 2019/06/05 17:20, Heiko Schlittermann via mailop wrote:
> The fix for CVE-2019-10149 is public now.
>
> https://git.exim.org/exim.git
> Branch exim-4_91+fixes.
>
> Thank you to
> - Qualys for reporting it.
> - Jeremy for fixing it.
> - you for using Exim.
>
> Sorry for confusion about the public release. We were forced to react,
> as details leaked.
>
> The patch should apply cleanly to all affected versions (4.87->4.91). We
> do not do a security release, as the official Exim version is at 4.92
> already and older releases are considered to be outdated and not
> supported by the developers anymore.
>
> Please do not hesitate to contact us if you need help backporting the
> fix.
And the Qualys write-up is here and it's a fun one.
https://seclists.org/oss-sec/2019/q2/152
Excerpts:
In this particular case, RCE means
Remote *Command* Execution, not Remote Code Execution: an attacker can
execute arbitrary commands with execv(), as root; no memory corruption
or ROP (Return-Oriented Programming) is involved.
...
a local attacker can simply send a mail to
"${run{...}}@localhost" (where "localhost" is one of Exim's
local_domains) and execute arbitrary commands, as root
(deliver_drop_privilege is false, by default):
...
- If Exim was configured to relay mail to a remote domain, as a
secondary MX (Mail eXchange), then a remote attacker can simply reuse
our local-exploitation method with an RCPT TO "${run{...}}@khazad.dum"
(where "khazad.dum" is one of Exim's relay_to_domains).
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Hetzner blocking Gmail IPv6?
On 2019/05/15 19:30, Yiorgos [George] Adamopoulos via mailop wrote: > I just tried to reply to a Hetzner support request from our GSuite > account and got back this: > > 550 Unfortunately we cannot currently accept your e-mail due to the > amount of spam we are receiving from your server. Please check https:// > rbl.your-server.de/?ip=2607:f8b0:4864:20::136 for further details or > contact your server provider. Perhaps gmail should force using IPv4 to send to sites hosted at Hetzner? :-) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Mailing List Address Formats..
On 2019/01/11 10:07, Michael Peddemors wrote: > For the record, we aren't speaking about 'Friendly Names', but the userpart > of the addr-spec address > > But a pointer to an RFC where it is permitted, that I don't find.. RFC5322 and predecessors. Either dot-atom or quoted-string are permitted for the local part of the address. Characters allowed in dot-atom are listed in 3.2.3; many other characters including whitespace are allowed in quoted-string. > (And yes, Thanks Al it has been used in the wild as you pointed out for some > time now, wanted to know if it was 'permitted' by RFC anywhere now, as > seeing more recent list usage with it.. ) > > It's more a 'gotcha' that post delivery processing systems may not expect... That would be a good clue that they're likely to be doing other things wrong too. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
