Re: [mailop] Samsung and SIZE
- Original Message - > From: "Sebastian Nielsen via mailop" >>> 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, you've changed the field here; if you're only talking about a *terminating* MTA, not a transit one -- accepting incoming traffic for your own mailboxes -- then how tightly you need to adhere to the RFCs is probably "not as much". But it would only be the MUA; the originating MTA shouldn't be rewriting headers it's not supposed to either. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [ADMIN] BIMI, Logos etc
Noted, will discontinue further replies. -Tim On Mon, Jan 15, 2024 at 2:26 PM Graeme Fowler via mailop wrote: > On 14 January 2024 15:55:43 Graeme Fowler via mailop > wrote: > >> Unless anyone has anything new, valid, on-point and worthy of further >> discussion, I'd suggest that we're done here. >> > > I'm no longer suggesting. Just stop rehashing the thread. It's dead. It's > not pining for the fjords. > > Thanks > > Graeme, preparing the mod- and ban- hammers for those who appear desperate > to trash the utility of the list. > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus contact?
> On Mon, Jan 15, 2024 at 11:00AM Udeme wrote: > > > Mark: looks like as of seconds ago the SBL´s been resolved & removed from > > the SBL? > > Yes! That's great, but unfortunately and confusingly, it's switched to a > different listing instead: https://www.spamhaus.org/query/ip/66.175.222.108 You'll likely be interested in the reputation score, which is presently showing as "Poor" for that IP address (66.175.222.108): Reputation Lookup || Cisco Talos Intelligence Group https://www.talosintelligence.com/reputation_center/lookup?search=66.175.222.108 If any of your lists don't satisfy the "confiremd opt-in" requirement, then correcting that will help over time. (If you need any assistance with this, feel free to contact me off-list.) -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Samsung and SIZE
> >> I was thinking about not advertising SIZE myself, because our limits are > >> already very high so people can send large attachments internally. > > I would still suggest setting a sensible limit, like 100 MB or similar, to > avoid the problem that certain MUAs tend to timeout, crash or stall while > sending the email. The email is soo large so the MUAs own timeout for sending > email trips and then it cancels the request. > > I have seen my share of MUAs that behave in weird ways when encountering > things larger than it can handle, so you have to always cope for them in the > mail server. Implementing different types of restrictions, and filtering > things out of subjects and certain headers to evade crashing MUAs. 998 characters (not including CRLF), as I recall, is the maximum limit, which is specified in RFC 5322 (section 2.1.1): RFC 5322 :: Internet Message Format https://datatracker.ietf.org/doc/html/rfc5322#section-2.1.1 So, I make sure my software works within these limits, and although I do try to keep automated message subject lines short-and-pithy, I'm actually don't care if someone else's MUA crashes because it can't handle 998 characters -- that's a serious problem with the MUA software that needs to be resolved. > As I said before, stumbled upon a MUA which tend to crash when subjects > become too long. The thing is that the MUA stores emails on the harddrive, so > when subject is very long, pathlen (C:\Users\\.\mail\[subject].eml) > exceeds 255 characters (MAX_PATH), and when pathlen exceeds 255 then MUA > fails to write the email file, and subsequently silently crash. That's an incredibly stupid design decision. Seriously... Storing eMail messages in files named by the subject line carries many risks with it, including the need to program for the following: 1. duplicate filenames (when a subject name is used more than once) 2. use of absolute path characters (e.g., "/boot/grub/grub.cfg") 3. use of pipe characters (e.g., "| deltree /y C:\Windows") 4. use of redirection characters (e.g., "> /etc/passwd") 5. use of invalid characters that result in a file creation error There are other problems too, which I choose to leave this to the reader's imagination. Anyway, such sofwtare either needs to be fixed, or replaced. And when message are stored on the local file system by an MUA, the usual practice is for some code to generate a filename that is based on something rational, such as some sort of a unqiue sequence number. > Resulting in user getting locked out from his mail account (as the MUA would > silently crash immediately upon downloading the culprit email from server) > until I delete the email with the excessive subject on server. That's stupid software. Get it fixed, or replace it with something else that's been written by people who understand why such a stupid design choice also creates potential security problems (in addition to the stability problems that you noted). > So email operators, don't be afraid of putting limits, replaces and such, it > just help people with troubles when things become too large. Nope. It's not a matter of "being afraid" -- it's a matter of me choosing not to hobble my system to accomodate someone else who's trying to use broken software. If someone is running software that requires everyone else reduce the limits below what is clearly documented in the relevant RFCs (see my RFC link, above), then I'm very likely not going to do it (unless they pay enough money to make it worthy of my time and effort, or they are a major provider being unreasonable that my users want to communicate with, etc.) since what they're asking for is ... stupid. Subject lines longer than 255 characters crashes your MUA? Yeah, that's not my problem as long as the subject lines I'm sending to you are within the 998 character maximum. Fix or replace your MUA, or let it keep crashing -- the choice is yours, and it's not my problem. > Email isn't directly made to send really huge things. Correct. Originally, eMail didn't even have any provisions for including file attachments. This was added later, albeit in a way that enlarged binary data using base-64 encoding (to cleverly accomodare the use of 7-bit ASCII communications in a reliable way), and although it works well now (thanks again to RFCs making it clear for software vendors to implement support for it), it would have been nice if more efficient options were available, such as 8-bit raw data inclusion, in the original specifications (just for starters). Internet communications have improved tremendously over the past few deaces, and the availability of high-speed internet has also become widespread, so overall this isn't really a major
Re: [mailop] Spamhaus contact?
It appears that Atro Tossavainen via mailop said: >> On Spamhaus' suggestion, I built a reverification system late last year and >> tested it on a small group of users. Yesterday, I kicked off a >> reverification to a much larger segment of users. Yup, I got it yesterday for a list I'm on that's hosted at groups.io. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Samsung and SIZE
>> I was thinking about not advertising SIZE myself, because our limits are >> already very high so people can send large attachments internally. I would still suggest setting a sensible limit, like 100 MB or similar, to avoid the problem that certain MUAs tend to timeout, crash or stall while sending the email. The email is soo large so the MUAs own timeout for sending email trips and then it cancels the request. I have seen my share of MUAs that behave in weird ways when encountering things larger than it can handle, so you have to always cope for them in the mail server. Implementing different types of restrictions, and filtering things out of subjects and certain headers to evade crashing MUAs. As I said before, stumbled upon a MUA which tend to crash when subjects become too long. The thing is that the MUA stores emails on the harddrive, so when subject is very long, pathlen (C:\Users\\.\mail\[subject].eml) exceeds 255 characters (MAX_PATH), and when pathlen exceeds 255 then MUA fails to write the email file, and subsequently silently crash. Resulting in user getting locked out from his mail account (as the MUA would silently crash immediately upon downloading the culprit email from server) until I delete the email with the excessive subject on server. So email operators, don't be afraid of putting limits, replaces and such, it just help people with troubles when things become too large. Email isn't directly made to send really huge things. Best regards, Sebastian Nielsen ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [ADMIN] BIMI, Logos etc
On 14 January 2024 15:55:43 Graeme Fowler via mailop wrote: Unless anyone has anything new, valid, on-point and worthy of further discussion, I'd suggest that we're done here. I'm no longer suggesting. Just stop rehashing the thread. It's dead. It's not pining for the fjords. Thanks Graeme, preparing the mod- and ban- hammers for those who appear desperate to trash the utility of the list. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus contact?
>> On Spamhaus' suggestion, I built a reverification system late last year and >> tested it on a small group of users. Yesterday, I kicked off a >> reverification to a much larger segment of users. > > Looking forward to seeing this in our traps. Yeah, we're seeing that from 66.175.222.12 Richard On 2024-01-15 1:09 p.m., Atro Tossavainen via mailop wrote: We're an email groups service, like Google Groups. Based on evidence provided by Spamhaus, it appears that some groups that migrated from Yahoo Groups when Y! Groups shut down contained some Spamhaus spamtrap addresses. That might be the explanation for why some of your customers' lists contain addresses that ceased to exist before groups.io started to. It does look rather suspicious when that happens. On Spamhaus' suggestion, I built a reverification system late last year and tested it on a small group of users. Yesterday, I kicked off a reverification to a much larger segment of users. Looking forward to seeing this in our traps. This is a third-party observation that has nothing to do with Spamhaus. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus contact?
The listing’s details explain the problem. I’d start with researching the details there. As for a timeline, I’d shift the “concerns” towards fixing what caused the listing. That being said, I can’t speak for Spamhaus. Good luck. On Mon, Jan 15, 2024 at 2:16 PM Mark Fletcher wrote: > On Mon, Jan 15, 2024 at 11:00 AM Udeme wrote: > >> Mark: looks like as of seconds ago the SBL’s been resolved & removed from >> the SBL? >> > > Yes! That's great, but unfortunately and confusingly, it's switched to a > different listing instead: > https://www.spamhaus.org/query/ip/66.175.222.108 > > Thanks, > Mark > ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
On Fri, Jan 12, 2024 at 5:58 PM Jaroslaw Rafa via mailop wrote: [snip] Dnia 12.01.2024 o godz. 14:04:59 Tim Starr via mailop pisze: > > BIMI's value is not dependent upon MUAs > > never doing anything outside its spec. > > Yes, it is. Because it depends on the condition that the logo is displayed > only if it is a verified BIMI logo. > Nope. It depends on mailreaders displaying logos they think will be helpful to their users. BIMI is a way for senders to nominate candidates for their own logos, which mailreaders are free to accept or reject, as they see fit. -Tim ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus contact?
> We're an email groups service, like Google Groups. Based on evidence > provided by Spamhaus, it appears that some groups that migrated from Yahoo > Groups when Y! Groups shut down contained some Spamhaus spamtrap addresses. That might be the explanation for why some of your customers' lists contain addresses that ceased to exist before groups.io started to. It does look rather suspicious when that happens. > On Spamhaus' suggestion, I built a reverification system late last year and > tested it on a small group of users. Yesterday, I kicked off a > reverification to a much larger segment of users. Looking forward to seeing this in our traps. This is a third-party observation that has nothing to do with Spamhaus. -- Atro Tossavainen, Founder, Partner Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. +372-5883-4269, https://www.koliloks.eu/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus contact?
On Mon, Jan 15, 2024 at 11:00 AM Udeme wrote: > Mark: looks like as of seconds ago the SBL’s been resolved & removed from > the SBL? > Yes! That's great, but unfortunately and confusingly, it's switched to a different listing instead: https://www.spamhaus.org/query/ip/66.175.222.108 Thanks, Mark ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus contact?
Mark: looks like as of seconds ago the SBL’s been resolved & removed from the SBL? -Udeme On Mon, Jan 15, 2024 at 1:41 PM Mark Fletcher via mailop wrote: > Hi All, > > One of groups.io's servers was listed by Spamhaus starting Saturday > afternoon (https://www.spamhaus.org/sbl/query/SBL638016). I've been > trying to contact them ever since, but they've been silent. I am humbly > asking for help. > > We're an email groups service, like Google Groups. Based on evidence > provided by Spamhaus, it appears that some groups that migrated from Yahoo > Groups when Y! Groups shut down contained some Spamhaus spamtrap addresses. > On Spamhaus' suggestion, I built a reverification system late last year and > tested it on a small group of users. Yesterday, I kicked off a > reverification to a much larger segment of users. I then told Linode, our > hosting provider, about it, and asked them to contact Spamhaus, as directed > by their SBL listing. Linode did that, but has not heard back. I also tried > contacting Spamhaus this morning, but haven't heard back yet. I am > wondering what else I need to do. > > Thanks, > Mark > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Spamhaus contact?
Hi All, One of groups.io's servers was listed by Spamhaus starting Saturday afternoon (https://www.spamhaus.org/sbl/query/SBL638016). I've been trying to contact them ever since, but they've been silent. I am humbly asking for help. We're an email groups service, like Google Groups. Based on evidence provided by Spamhaus, it appears that some groups that migrated from Yahoo Groups when Y! Groups shut down contained some Spamhaus spamtrap addresses. On Spamhaus' suggestion, I built a reverification system late last year and tested it on a small group of users. Yesterday, I kicked off a reverification to a much larger segment of users. I then told Linode, our hosting provider, about it, and asked them to contact Spamhaus, as directed by their SBL listing. Linode did that, but has not heard back. I also tried contacting Spamhaus this morning, but haven't heard back yet. I am wondering what else I need to do. Thanks, Mark ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else noticing an increase in spam from Office365 distribution lists?
> FWIW, after a log file review we are contemplating blocking > "azurewebsites.net" as well as "@onmicrosoft.com". Our logs are showing small quantities of SMTP traffic from "azurewebsites.net" that are usually being blocked due to SPF failures, and usually sending to weird, nonsencial non-existent eMail addresses where the local-part is a series of randomly-selected letters and digits, sometimes intermixed with names of birds, furniture, food, vehicles, colours, etc., all of which are recipient addresses that don't exist and have never existed. I'm assuming it's a source of eMail debris from broken systems. I'm almost tempted to set up a honeypot to see whatever trash it's trying to spew out, but I'd rather do something more productive (like flossing my teeth). > Curious if others are coming to the same conclusion? I'm currently leaning in a block-on-sight direction since I'm seeing zero legitimate eMail coming from hosts self-identifying as hosts in the "azurewebsites.net" domain name in the HELO and EHLO commands. > Regards, > Mark > _ > L. Mark Stone, Founder > North America's Leading Zimbra VAR/BSP/Training Partner > For Companies With Mission-Critical Email Needs > > - Original Message - > From: "Mark Alley via mailop" > To: "Andrew C Aitchison" > Cc: "mailop" > Sent: Sunday, January 14, 2024 6:30:22 PM > Subject: Re: [mailop] Anyone else noticing an increase in spam from Office365 > distribution lists? > > > > Ah, yep, thanks for catching that typo. > On 1/14/2024 4:56 PM, Andrew C Aitchison wrote: > > > On Sun, 14 Jan 2024, Mark Alley via mailop wrote: > > > BQ_BEGIN > This is anecdotal, but I think it illustrates even at a smaller scale the > persistent problem Microsoft currently has with their tenancy. > > I did some quick perusal of the last month's data from our email logs, and > out of a total of 22,473 external emails that contain a .onmicrosoft.com > subdomain in the RFC5322.FROM field -- 22,086 were blocked because of various > reasons: > > * 21,228 spam > * 1 malware > * 759 phishing > * 5 impostor > * 93 "hard" failed SPF without a DMARC record since onmicrosoft.com > doesn't have one. (probably forwarded) > > 387 "clean" emails were delivered successfully initially, and 151 of those > initial delivers were then later retroactively classified as being spam or > phishing. > > So even at this scale, we're left with a minutia of ~0.01% > > > > 236/22473 ~= 1% > > > BQ_BEGIN > "legitimate" emails, most of which are from misconfigured Exchange Online > mailboxes or Office365 groups from various businesses. > > So, YMMV widely, but for most organizations, as John said, definitely not > going to be missing /too /much. Most of what I see that's legitimate in our > traffic would be 3 or 4 specific subdomain additions to a safelist from the > hypothetical block rule, and that would be it. > > - Mark Alley > > BQ_END > > > BQ_END > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Samsung and SIZE ("Date:" header tampering)
> >> 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. This is a common problem with a lot of eMail clients, and spammers even sometimes use this to sneak their messages into inboxes in more subtle ways. It's certainly can be a frustrating problem, especially when a sender has the incorrect date set on their computer. I'm still using Pegasus Mail (on Linux under WINE) which shows the newly received messages first (until I reload the folder). It's a nice feature, but I know that most eMail clients don't do this (and I'm not suggesting you change eMail software). Does your eMail software provide an option to sort by the most recent "Received:" header? In Mozilla Thunderbird, "View menu -> Sort by -> Received" will sort messages either by the "Received:" header or by the date and time you received the message -- either way, this resolves the problem if you're using Thunderbird. (I don't know whether other eMail software like Evolution, SnappyMail, MS-OutLook, etc., have this capability.) > 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. One of these two options may work better for you: 1. Reject, with a 5yz status during the SMTP session, messages that contain an invalid "Date:" header, and configure an additional invalidity criteria to include: dates that are older than 1 week; and dates that are more than 2 days in the future. 2. Rename the existing "Date:" header to "X-Original-Date:" before adding your own "Date:" header. I recommend option 1 over option 2, but if this isn't possible with your mail server (I'd be happy to write a script to detect this if anyone needs this functionality during BEFOREQUEUE processing), then option 2 will at least preserve the contents of the original "Date:" header (which helps to mitigate problems, like those that I'm describing hereunder...). (I strongly discourage the modification of headers provided by the sender -- it's always better to add custom headers instead.) > Whats so wrong with it. Two words: Court evidence If the eMails in your possession are to be used in a future court case, you put yourself at risk for evidence tampering, which could result in all your evidence being excluded from the case, or you could be charged with an offence that results in fines or even incarceration, depending on laws, what opposing counsel demands, the Judge's discretion, jurisdiction requirements, etc. Additionally, there are other problems, such as a sender describing something they sent to you based on their message's date and time, and you not being able to find it (at least not immediately) because your date and time is different -- sometimes eMail can be queued on the client-side where the "Date:" header was already created, or it's delayed in one or more mail server queues for any number of reasons (e.g., prolonged network outages, awaiting manual inspection by overburdened staff, etc.), which is tracked by "Received:" headers. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else noticing an increase in spam from Office365 distribution lists?
FWIW, after a log file review we are contemplating blocking "azurewebsites.net" as well as "@onmicrosoft.com". Curious if others are coming to the same conclusion? Regards, Mark _ L. Mark Stone, Founder North America's Leading Zimbra VAR/BSP/Training Partner For Companies With Mission-Critical Email Needs - Original Message - From: "Mark Alley via mailop" To: "Andrew C Aitchison" Cc: "mailop" Sent: Sunday, January 14, 2024 6:30:22 PM Subject: Re: [mailop] Anyone else noticing an increase in spam from Office365 distribution lists? Ah, yep, thanks for catching that typo. On 1/14/2024 4:56 PM, Andrew C Aitchison wrote: On Sun, 14 Jan 2024, Mark Alley via mailop wrote: BQ_BEGIN This is anecdotal, but I think it illustrates even at a smaller scale the persistent problem Microsoft currently has with their tenancy. I did some quick perusal of the last month's data from our email logs, and out of a total of 22,473 external emails that contain a .onmicrosoft.com subdomain in the RFC5322.FROM field -- 22,086 were blocked because of various reasons: * 21,228 spam * 1 malware * 759 phishing * 5 impostor * 93 "hard" failed SPF without a DMARC record since onmicrosoft.com doesn't have one. (probably forwarded) 387 "clean" emails were delivered successfully initially, and 151 of those initial delivers were then later retroactively classified as being spam or phishing. So even at this scale, we're left with a minutia of ~0.01% 236/22473 ~= 1% BQ_BEGIN "legitimate" emails, most of which are from misconfigured Exchange Online mailboxes or Office365 groups from various businesses. So, YMMV widely, but for most organizations, as John said, definitely not going to be missing /too /much. Most of what I see that's legitimate in our traffic would be 3 or 4 specific subdomain additions to a safelist from the hypothetical block rule, and that would be it. - Mark Alley BQ_END BQ_END ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
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] Samsung and SIZE
Dnia 15.01.2024 o godz. 07:54:47 Sebastian Nielsen via mailop pisze: > Problem is, that when MUA or first MTA has a incorrect date set, the email > comes like last in inbox... have seen emails set with 1970-01-01 00:00:00 > Or, even worse, it has a date that is like, several months off, so you > have to SEARCH your inbox after that unread email that was popped into the > middle. The solution to the problem is, use a MUA that auto-positions on the FIRST UNREAD message when opening the inbox... Many MUAs have that feature, and it helped me many times to not miss the email, even if it has a date set to many days backwards... -- 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 daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Displaying logos
Dnia 15.01.2024 o godz. 08:07:28 Sebastian Nielsen via mailop pisze: > A better solution would otherwise to make a BIMI extension to SMIME in > that case, that will override the server BIMI in SMIME signed emails. > Where the BIMI logo becomes part of the SMIME certificate by an > non-critical extension. (SHA512 hash + URL of BIMI logo) That's probably the best idea, because BIMI will then become simply an additional feature to something that is actually useful (S/MIME certificate). This may also promote use of S/MIME for actual end-to-end email authentication, which undoubtedly *is* the most reliable from of email authentication, but is very rarely used today. Going through all this process you have described just to get a BIMI-validated logo seems still a waste of time and effort for me. We return here to the original question: what is the actual added value that BIMI gives? For me it looks like a typical case of "solving a problem one has first created themselves", ie. first we create another artificial barrier of entry for someone wanting to operate own email server, that by itself gives little to zero added value (the value does not justify the effort needed to set it up), and then we try to find a solution to make that barrier of entry "lower" and less obtrusive. Instead of returning again and again to the question, is this barrier of entry actually needed at all? And a final remark regarding your draft: believe it or not, but there *are* people in the world who want to run their own mail server, but do not use - and do not want to use - smartphones. So, no NFC or QR code scanning. -- 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 daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Samsung and SIZE
Thats why I validate the DKIM signatures before touching that header, meaning the DKIM signature is already validated and fine. Then I put my validation header, which the MUA then can “consume”, but also delete other validation headers so no malicious party can pre-fill the email with a valid validation header. None is validating DKIM locally, and if someone do, it would be easy to write an exception for that user. Also, another thing that borks the DKIM signatures is the 8BITMIME to 7BITMIME down-conversion which is required for my scripts inside mail server to work properly. Also, another thing I do, is cut off subjects at 100 characters. Reason I do that, is that subjects over 100 characters tend to crash certain MUAs so I have to keep the subjects low to avoid certain MUAs from silently crashing. Från: Hans-Martin Mosner via mailop Skickat: den 15 januari 2024 08:56 Till: mailop Ämne: Re: [mailop] Samsung and SIZE Am 15.01.24 um 07:54 schrieb Sebastian Nielsen via mailop: 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. Mailers creating DKIM signatures are likely to include Date:, so your "correction" would invalidate many DKIM signatures. It's up to your users to decide which is less inconvenient, especially if you always modify the header instead of only when the date is off by more than a day or so. Cheers, Hans-Martin ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
