Re: [mailop] Mailserver software
On 2024-07-15, Jeff Pang via mailop wrote: > When I deploy a new mailserver, I consider postfix, exim and qmail. > From practical experience, what are the advantages, disadvantages, and > adaptation scenarios of postfix, exim, and qmail? I run exim on my servers and postfix on my laptops. I find exim fairly easy to configure, and you can do a lot of stuff (for example: I have fairly fancy customized greylisting; I run two backup servers using the same config file with conditions on the presence of a flag file; I have several domain-specific deliverability criteria; I run mailing lists; and so on). I'm sure it can all be done with postfix too, but I have too much investment in exim to think about it :) The exim mailing list also generally provides fast and useful help in the (very rare) instances when the documentation isn't enough. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Cloud hosts for responsible mail servers?
On 2024-07-09, Ralph Seichter via mailop wrote: > * Philip Paeps via mailop: > >> With such low volume, you will really struggle to get email delivered >> to the larger mailbox providers, whose filtering is largely based on >> reputation. It's almost impossible to build up (and maintain) a >> reputation unless you can manage at least O(hundreds) of messages to >> them per day. > > I disagree, because I have never struggled to get mail from my servers > delivered to Google, Microsoft, etc. Telekom appears to soft-block > unfamiliar mail servers by default, and I had to notify them whenever > a new server went online, but that was a one-time measure for each > individual server. Call it a minor nuisance. Similarly. I've been running my own mailserver for personal, family and club domains (including a mailing list of several hundred at one point) for 20 years or so. In the early days, there were no problems; nowadays if I change server (I run one primary and two backups, changin the provider only if one goes bust or becomes useless, so changes are rare) I have to go through Microsoft's hoops (and t-online, but they're more trouble than it's worth usually), but I haven't run into my problem. One of my users forwards all their mail to gmail, including the spam, so sometimes I get rate-limited by gmail, but who cares. (Unlike most people on this list, I do not think it is a provider's job to censor people's email. Users should be able to see their spam if they wish. I'm slightly curious about spam volumes - in my incoming personal mail, last time I checked about 75% of it was spam. Is that typical, or very low?) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone from Google - Sudden Gmail bounces??
On 2024-03-31, Slavko via mailop wrote: > Dňa 31. marca 2024 15:02:31 UTC používateľ Odhiambo Washington via mailop > napísal: > >>> Something bad seems to have gained the ability to use that IP... >>> >> >>Not that easy unless there is some recent exploit that I am not aware of. > > Don't seems as neighbor problem... Cisco Talos thinks there is a lot of spam coming from 41.212.32.190 It also thinks 41.212.32.14 has been very spammy in recent months. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google unsolicited mail rejected with 421
On 2024-03-14, Marco Moock via mailop wrote: > sendmail tried to deliver it 20 times during the night - this morning > I deleted the mail from mqueue. That's a fairly aggressive retry strategy. If there's something about that message gmail doesn't like, then retrying that often might be enough to reinstate the limit each time. Generally best to back off the retry rate after a couple of hours. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google unsolicited mail rejected with 421
On 2024-03-14, Marco Moock via mailop wrote: > Hello! > > Yesterday I replied somebody directly on debian-users (he uses a crappy > mailer and sends to the author and the mailing list...). > > Gmail doesn't like this mail, but rejects it with a tempfail. I've now > deleted it from mqueue. > > Mar 14 06:54:17 srv1.xyz sm-mta[498019]: 42DK6aqc496761: > to=, delay=09:47:40, xdelay=00:00:03, mailer=esmtp, > pri=5370980, relay=alt4.gmail-smtp-in.l.google.com., dsn=4.7.28, > reply=421 4.7.28 Gmail has detected an unusual rate of unsolicited mail > originating, stat=Deferred: 421-4.7.28 Gmail has detected an unusual > rate of unsolicited mail originating > > It was only this message. Why don't they reject them with 5xx when they > treat the mail as unsolicited? > It was only this mail, my server wasn't abused by spammers. > > Although, I send only a very small amount of mail to Google. Do they > use that to calculate the rate? They don't reject with 5xx because they're not rejecting that message, they are rate-limiting you or the network you're on. I get this often, because one user forwards their mail to gmail, including all the spam. Google rejects the spam, and from time to time also rate-limits me. Which I don't care about, because I send very little mail, and it goes through on the next run. Google is brain-dead about "unsolicited" mail - whatever machine learning it's doing, is crap. 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. Julian. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] % in SRS ?
On 2024-03-08, Bill Cole via mailop wrote: > On 2024-03-08 at 12:07:23 UTC-0500 (Fri, 08 Mar 2024 17:07:23 +) > Julian Bradfield via mailop > is rumored to have said: >> Is there any reason not to use the old routing character '%' instead? > Yes: it is an old routing character > > As such, some sites may misinterpret it in ways that are NOT appropriate > for SRS. How so? Even in the old world, the only site that ever needed to interpret it was the receiving site after the @. It has no special status, and is just another character that can appear in an unquoted local-part. It never had a status in Internet email (RFC822 routing was with the @route.domain: syntax). I don't deny that somebody *could* construct a configuration that did something weird with it, but I bet there isn't an existence proof; and if they did something weird for addresses not part of their domain, they wouldn't be compliant with either old or new RFCs, so who cares? Julian. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] % in SRS ?
An idle question: people who do SRS or similar things usually use '=' as the replacement for '@' in the rewritten address localpart=origdomain@mydomain Is there any reason not to use the old routing character '%' instead? I did this some years ago when I hacked in SRS to keep gmail happy with one user's forwards, and never noticed a problem, but I've always wondered why people don't do this, since surely nobody in the world still runs a server that actually relays % addresses, and the people doing the SRS certainly don't. Julian. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Filter out emoji from email adresses
On 2024-03-07, Sebastian Nielsen via mailop wrote: > Exactly, but when the mail client tries to display the crap in the name > field, it causes it to crash. Guess it tries to render Emoji in a field that > is not designed to accept Emoji, thus it just silentcrash into desktop. > So people can't access their mail. If you have a mail client that is so badly written that it crashes when it encounters a missing character in a font, you need to replace or fix the mail client, or file a bug report against the library causing the problem. An emoji is just another character. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] mimecast "antispoofing"
I just had a bounce, when a member of the list posted, from what is presumably a mimecast served company, to one of my club lists. The member's own copy of the list posting was bounced by his provider with 550 Rejected by header based Anti-Spoofing policy: [member's address redacted] - https://community.mimecast.com/docs/DOC-1369#550 [_gg8dmJZP_u-QdQxhMDwLg.uk114] I suppose that this means they don't accept a message "From:" an address they serve - but the message was DKIM-signed by the company my member sent from, so they should know it's not a spoof! (And my list is DKIM-clean.) What should they be doing according to "best practice"? Julian. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Dot as the first character of a line ? (RFC 5321, Section 4.5.2)
On 2024-03-01, Cyril - ImprovMX via mailop wrote: > @Julien Bradfield: > I've initially shared the exact line in the code on what Aiosmtpd - not my > software - is doing, which it is saying is following the RFC by removing > the first character if it's a dot. I could share emails that went I did refer you to the smart questions FAQ. Describe the symptoms, not your guesses. > through Aiosmtpd and another that didn't, which would only show that the > one that didn't still has a starting dot whereas the other doesn't. I don't > see what I can add on top of that. It seems clear, precise and detailed as > it includes references and links. If anything is missing, coud you please > ask clearly and precisely what do you expect more from it? If you make the very strong claim that Gmail is not following the RFC, you need to show (a) The source email as received by your MTA from the MUA or other MTA (b) The email as displayed in Gmail (c) A transcript of the SMTP session by which your MTA delivered the mail to Gmail. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Dot as the first character of a line ? (RFC 5321, Section 4.5.2)
On 2024-03-01, Cyril - ImprovMX via mailop wrote: > Upon further investigation, we realized that GMail does NOT respect that > RFC. They keep the dot. And if you add two dots, as per the RFC, GMail will > keep the two dots, making the URL broken. What *exactly* did you do to realize this? If I send mail from my personal server (running exim) to gmail, lines beginning with dots arrive correctly with DKIM intact. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] tiscali.it/tiscalinet.it reject RFC821 FROM domain as a CNAME because "domain does not have neither a valid MX or A record"
On 2024-02-29, Stefano Bagnara via mailop wrote: > Today an italian mailvox provider started refusing our emails with this > message >> 550 5.1.0 sender rejected: > domain does not have neither a valid MX or A record > > The "e.#customerdomain" is a CNAME record that points to app.mailvox.it and > app.mailvox.it has both A and MX records. This situation is specifically permitted and covered in the DNS and Mail Routing RFCs, but may be less known than other configurations. As the problem went away, perhaps they introduced a bug when doing something else. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
On 2024-02-09, Marco Moock via mailop wrote: > I don't know if any MTA out there supports [DKIM] directly or supports > Milter. Exim supports it, even in the rather old version in Debian 10 that I use. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
On 2024-02-08, Archange via mailop wrote: [...] > No, I agree with you (I’m running two forwarders that have no issues so > far). And having a DMARC enforcing policy without DKIM is a bad idea. > > I would have wished that DMARC would require both SPF and DKIM, but now > it is too late for that. Hopefully they are not a lot of domain that do > DMARC without DKIM. But if DMARC required alignment on both SPF and DKIM, forwarding would break, wouldn't it? And SPF without alignment is of very little value. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] puzzling rejections from icloud
I run some small mailing lists for a club, and there's one member with an address at icloud.com that rejects (with a generic "policy" message) many of the messages sent to the club lists. Sometimes it's possibly explicable because the message was sent by somebody whose provider doesn't DKIM-sign. However, I've just seen one I don't understand at all. The message is from a btopenworld.com user, sent to a list at the club. When I send messages out, I change nothing except the envelope sender (and one or two diagnostic headers). So it should pass SPF (from the club), DKIM (from the sender) and be aligned for DKIM. icloud's message is: 5.7.1 Your message was rejected due to btopenworld.com's DMARC policy. See https://support.apple.com/en-us/HT204137 for info As mentioned, the message should pass DMARC. For diagnostic purposes I have a dummy gmail user as a member of all lists, and gmail tells me that this message does indeed pass SPF, DKIM, and DMARC. I trust Google more than Apple to get these things right :) Does anybody have a similar experience with icloud, or any other suggestions? thanks, Julian. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] MIME multipart/related & type argument
On 2023-06-11, Slavko via mailop wrote: > Now i did search in both, the my MX's SPAM archive and > my own maildir. I found really small amount of multipart/related > with type= argument in my maildir, all was pointing to text/html. > I found relative many multipart/related nessages in SPAM > archive, almost all has type= parameter and allmost all pointing to > multipart/alternative. I have valid ham messages with type="multipart/alternative" . It's also, I think, common for well designed multimedia messages: if you send a message, with images or files referred to in the text, a good client will prepare the following structure: multipart/related type="multipart/alternative" multipart/alternative multipart/text plain version multipart/html flashy version image/... image/... application/x-whatever An example of a bad client is AppleMail, which puts all the attachments alongside the html message, and then wraps that up in an alternative, so that the plain text version does not have the attachments. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] MIME multipart/related & type argument
On 2023-06-11, Slavko via mailop wrote: > from time to time i get SPAM with Content-Type with extra > type= argument, eg.: > > Content-Type: multipart/related; type="multipart/alternative"; ... > > I spend a lot of time to find where that type= argument is > defined. I guess, that they try do define which nested part > is "main". But not enough time to read the basic RFCs, apparently. Try reading RFC2387. Yes, your guess is right. For multipart/related, type= is a mandatory parameter. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Suggestions for Researching Gmail/Google Workspace Issue
On 2023-05-12, Jenny Nespola via mailop wrote: > Hope you are well. I was wondering what else I may be missing when > researching a Gmail/Workspace placement issue. I have a client that [ snip ] > Once you engage, the mail will stay in the inbox or if you pull from spam, > but anyone new (with a communication from that domain/IP combo) will go to > spam. [ snip ] This is very obvious, but you don't say you've done it: is the SPF and DKIM set up correctly for the new site? In my experience a while ago, if you have neither SPF nor DKIM, then gmail rejects; if you have SPF but not DKIM, it accepts but quarantines. I don't know whether that's still the case. (Oh, and of course if the site has a DMARC record, what does it say?) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] mailgun anybody? (variable sender address) time
On 2023-03-24, Heiko Schlittermann via mailop wrote:
> fh--- via mailop (Fr 24 Mär 2023 03:56:53 CET):
>> > does anybody from mailgun read here?
>> > Your messages are tmprejected at our systems, w/o any chance to pass
>> > ever.
>> b/c they were sending spams?
>
> I can't tell, because we rejected them with 4xx and they do not pass the
> greylisting with a changing sender address.
I use the following snippets in my greylisting code, which pretty much
deals with the changing sender address problem, and also, partially,
the mail farm problem.
---
# to do greylisting sensibly on mail farms, we want to use
# the /24 of an IPv4 address, or the /48 of an IPv6 address
# try with ipv first
SENDER_HOST_PREFIX = ${if match{$sender_host_address}{:}{${mask:$sender_host_ad\
dress/48}}{${mask:$sender_host_address/24}}}
# also, because of all those sites that put a key into the sender address,
# if the localpart is longer than, say, 30 charactersm, we'll just replace
# it with a fixed string
SENDER_ADDRESS_COMPACTED = ${if >{${strlen:$sender_address_local_part}}{30} {ke\
yedsender@$sender_address_domain}{$sender_address}}
---
# and this is the normal greylist check
condition = ${readsocket{/var/run/greylistd/socket}\
{--grey \
SENDER_HOST_PREFIX \
SENDER_ADDRESS_COMPACTED \
$local_part@$domain}\
{5s}{}{false}}
---
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail blocking of good customer
On 2023-02-28, Jaroslaw Rafa via mailop wrote: > Dnia 28.02.2023 o godz. 11:10:05 Julian Bradfield via mailop pisze: >> Maybe worth pointing that people do greylisting, and with >> greylisting it's helpful to retry quite soon. Immediately isn't >> useful, but within five minutes is. (I personally have one-minute >> greylisting set.) > > I do greylisting, and that's how I found out about the immediate retries. I > run postgrey with default setting which is 5 minutes, and I often see in > logs multiple retries within those 5 minutes, with first ones being really > almost immediate (15-30 seconds). I have no other MXes, so I can't observe > retries to other MXes, but I often see retries FROM different IP address > than the original attempt, which count as new entries for greylisting, as > greylisting works on triplet (client IP address, sender, recipient). That too. Which is why I greylist not on individual addresses, but on /24s (or on /48s for IPv6). Of course there are still senders with larger mail farms, and some with widely scattered mail farms, but there's only so much I can be bothered to do .. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail blocking of good customer
On 2023-02-28, Jaroslaw Rafa via mailop wrote: > Another nonsense thing for me is that some senders - again, mostly the big > ones - retry almost *immediately* (often from a different IP address) if > they encounter a 4xx, and after a few such unsuccessful retries (within only > a few minutes) they eventually give up. I wonder what had in mind someone > who designed it that way? In a very broad sense, 4xx means some transient > problem on the receiving side that will eventually get fixed, and then the > mail will be accepted. But fixing any problem requires time. Did someone > who designed this behavior expect that the problem will "miraculously" > disappear if they retry immediately a few times? Maybe worth pointing that people do greylisting, and with greylisting it's helpful to retry quite soon. Immediately isn't useful, but within five minutes is. (I personally have one-minute greylisting set.) I often see immediate retries to the next MX, which of course is a reasonable thing to do (and often bypasses my greylist, owing to the way I do it - I view this as a feature:). ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Compromised email account trends
On 2023-02-22, Taavi Eomäe via mailop wrote: >> Why should I need to use a program registered to the service provider >> in order to read my email? (Or in my case, register myself as a >> developer with Microsoft in order to allow me and my colleagues to >> read our own mail.) > > > You are confusing one vendor's implementation with the standard. Really? RFC6749: 2. Client Registration Before initiating the protocol, the client registers with the authorization server. The means through which the client registers with the authorization server are beyond the scope of this specification but typically involve end-user interaction with an HTML registration form. [ ... ] When registering a client, the client developer SHALL: o specify the client type as described in Section 2.1, o provide its client redirection URIs as described in Section 3.1.2, and o include any other information required by the authorization server (e.g., application name, website, description, logo image, the acceptance of legal terms). ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Compromised email account trends
On 2023-02-22, Taavi Eomäe via mailop wrote: > This discussion is getting awfully close to reinventing OAuth2. > > It's quite clear by now that long-lived tokens that are nearly > impossible to properly revoke just don't work well in any human-operated > contexts. > > Hopefully we'll see an increase in the adoption of OAuth2 instead of > rather crude ways of mitigating only half of the issue. Large players > started pushing Oauth2 for both SMTP and IMAP for a really good reason > after all. Ugh. Why should I need to use a program registered to the service provider in order to read my email? (Or in my case, register myself as a developer with Microsoft in order to allow me and my colleagues to read our own mail.) In what way is it easier to revoke an OAuth2 token than it is to change a password? Most people have no clue about how OAuth2 works. They just know that it's something that gets in the way of working practices they've been using for 40 years. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] tls certificates
For the last couple of decades, I've been running Exim, using long-lived self-signed certificates for TLS, and since the last but one upgrade a couple of years ago, these certificates haven't even been for the right machine:) Almost everybody seems happy to talk to me, including gmail and microsoft, so I've never worried about it. Every day I get a few "TLS fatal alert" messages in the log file, but either they're from attackers, or from real sites (e.g. mailgun.net) that then (presumably) fall back to unencrypted sessions, since mail is then sent through. However, yesterday I noticed a string of alerts from a bank that were not followed by mail delivery. 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 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 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? Thanks for any advice! ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders
On 2022-10-21, Kai 'wusel' Siering via mailop wrote: [ in reply to a poster who had pain setting up new mxes ] > To stay ontopic here, the question is: _why_ were you getting "blocks left > and right"? And what were they? > > Was it a "fresh & clean" IPv4 address or one that had been abused in the > past? What did the RBL checking tools tell you about that IP? > > Did the IP belong to an ISP that people that have to deal with remote abuse > do wrinkle their nose at? > > And, most importantly: did you have to contact any postmaster to get that > IPv4 address, with matching PTR and A records, proper SPF and DKIM entries, > whitelisted to access their MXes at all? Yes. In the last 18 months, I've had cause to move both my primary and secondary MXes to different VPS providers. For both of them, Microsoft had the addresses on their internal blocklist. In both cases, the addresses themselves had no history, but were on the same /24 as hosts that did have a history. In both cases, I successfully jumped through the Microsoft hoops, and got them unblocked. This required not just being compliant, but providing proof of purchase and date of purchase of the addresses. It took a few days and three or four emails each time. Gmail is also a bit sensitive, but in my experience can be assuaged purely mechanically by carefully following all compliance requirements, including the ones I wouldn't otherwise bother with. Which is just as well, because there's no known way of contacting a human at Gmail, whereas Microsoft give you a real human after the first escalation. Currently neither I nor any of my users have any t-online.de correspondents, so I haven't tried dealing with them. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
