Re: [mailop] Samsung and SIZE
On 15 Jan 2024, at 06:54, Sebastian Nielsen via mailop wrote: >>> That header is supposed to be attached by the originating MUA, and I don't >>> *think* transit MTAs are permitted to rewrite it... > > Problem is, that when MUA or first MTA has a incorrect date set, the email > comes like last in inbox... have seen emails set with 1970-01-01 00:00:00 Or, > even worse, it has a date that is like, several months off, so you have to > SEARCH your inbox after that unread email that was popped into the middle. > > Thus to avoid that irritating problem, both for my users, and for myself, I > just set the Date: header to the server time, correcting any incorrect dates. > > Whats so wrong with it. Well, most obviously, the receiver loses information about the original transmission time of the message. True, nowadays that’s not far off the reception date, but you never know, maybe there is substantial downtime in the mail infrastructure between sender and recipient, and it makes a difference to know that several days have elapsed before when sender sent, and receiver receives. Apple Mail, and I’d be surprised if not other mailers, use the IMAP internal-date for message sorting. So for such users, this hack adds nothing, and takes info away. I’d advise against. And thanks for the info about Samsung clients. I don’t have any here, but I was thinking about not advertising SIZE myself, because our limits are already very high so people can send large attachments internally. I guess I’ll just advertise a large number and hope nobody hits it. Pro tip: Apple’s MailDrop feature uses the declared SIZE to decide if a message should be a candidate for MailDrop attachments. Cheers, Sabahattin ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Haraka status? Exim the only choice? (v Postfix)
On 7 May 2021, at 15:31, Steven Champeon via mailop wrote: > I know that sendmail rulesets have been compared to modem line noise and > Mr. Dithers' cursing, and can attest to the fact that writing them is > far more satisfying than reading them, but you have almost infinite > customization capacity if you can stand it. I once mentioned to a friend > (who used to write for sendmail.net when that was a thing) that you > could probably fit all of the people with as much experience writing > sendmail rulesets as I had into a Volvo station wagon, and his reply was > "you could fit more if you pulped them first", so don't take this as a > recommendation for sendmail; I'll eventually have to give up on it and > surrender to whatever the vox populi says I need to use. Well, this dinosaur started using Sendmail in 2004 at the great old age of 22, with completely hand-crafted cf (because!!!), as at the time it was unique in having DSN support, and to be honest I struggle to see what’s so terrible about it even now. It’s primary failing seems to be that it (still!) cannot deliver multi-recipient mail concurrently without using it in a queue-only mode, which introduces a delay (however small) and in any case doesn’t use the network efficiently to deliver multi-recipients per destination MX. If somebody knows how I might fix that, then I might go back to Sendmail from Exim (having gone by way of Postfix and even Xmail). The persistent security holes in Exim, though I am quite aware the maintainers are fixing them when they find them, do make the claims of some of Exim’s more militant defenders about its superior security compared to Sendmail look a little bit silly (though I will freely acknowledge that its setuid-root and monolithic philosophy has distinct advantages, as well as being really quite cute). I also admit to being annoyed that Debian insists on compiling Exim against GNUTLS instead of OpenSSL, which just makes using Exim harder on that platform. Postfix isn’t bad, but I find it just a bit too reductionist. In theory you can use its facilities in a general way, but in practice you need extra daemons and plugins. I have this particular requirement to do envelope and header rewriting, but only to the sender addresses, and based on the initial recipient. I still can’t figure out how that would be done “the Postfix way”, though I’m sure there’s probably a way with a proxy or something. It also does destination-based routing using the domain and not the MX, for the purposes of concurrent deliveries, and depending on your setup a big part of getting your configuration right is deciding how much load you’re prepared to sacrifice to outbound SMTP both during idle periods when scripting environments aren’t chewing up memory, and also during active periods, while they are. This turns out to be surprisingly challenging. Cheers, Sabahattin ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
