[mailop] Samsung and SIZE
I happened to see Samsung's email app send a SIZE parameter (rfc1870) to MAIL command without the capability being advertised. I wonder if this is a known thing, it's a difficult question to google. For me anyway. I don't know details about phone or app versions, other than that it's probably recent. This is just a random note. I doubt it affects anyone but it's still wrong. -mm- (plus, how often do I get to post here?) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Samsung and SIZE
Why is it a problem? The server ignores commands that it don't have capability for anyways. Only wonkiness of Samsung Mail (same in Microsoft Outlook), I have noticed, is that new email happens to arrive in the middle of the inbox if the sending server has its date incorrectly set. (EXTREMELY irritating if the server is off by more than a day or similar). So I do this in my SMTP server to correct the date of all incoming emails: accept remove_header = date add_header = Date: $tod_full What it does, is deleting the header "Date:" and then adds a new header "Date:" with the actual server time of MY server. If SIZE causes a problem in someone's server, just configure the server to delete the SIZE parameter of incoming emails (could even be done in certain firewalls). -Ursprungligt meddelande- Från: Mark E. Mallett via mailop Skickat: den 13 januari 2024 18:19 Till: mailop@mailop.org Ämne: [mailop] Samsung and SIZE I happened to see Samsung's email app send a SIZE parameter (rfc1870) to MAIL command without the capability being advertised. I wonder if this is a known thing, it's a difficult question to google. For me anyway. I don't know details about phone or app versions, other than that it's probably recent. This is just a random note. I doubt it affects anyone but it's still wrong. -mm- (plus, how often do I get to post here?) ___ 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 Sat, Jan 13, 2024, Sebastian Nielsen via mailop wrote: > Why is it a problem? The server ignores commands that it don't have > capability for anyways. Says who? 555 MAIL FROM/RCPT TO parameters not recognized or not implemented -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the Reply-To header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Samsung and SIZE
Then you need to reconfigure server to ignore said parameters. Originalmeddelande Från: ml+mailop--- via mailop Datum: 2024-01-13 19:58 (GMT+01:00) Till: mailop@mailop.org Kopia: ml+mai...@esmtp.org Ämne: Re: [mailop] Samsung and SIZE On Sat, Jan 13, 2024, Sebastian Nielsen via mailop wrote:> Why is it a problem? The server ignores commands that it don't have> capability for anyways.Says who? 555 MAIL FROM/RCPT TO parameters not recognized or not implemented-- Please don't Cc: me, use only the list for replies, even if themailing list software screws up the Reply-To header.___mailop mailing listmailop@mailop.orghttps://list.mailop.org/listinfo/mailop___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Samsung and SIZE
Dňa 13. januára 2024 19:14:58 UTC používateľ Sebastian Nielsen via mailop napísal: >Then you need to reconfigure server to ignore said parameters. RFC 5321, sect. 4.1.1: ...In the absence of specific extensions offered by the server and accepted by the client, clients MUST NOT send such parameters and servers SHOULD reject commands containing them as having invalid syntax. And section 4.1.1.2: If service extensions were negotiated, the MAIL command may also carry parameters associated with a particular service extension. IMO, in other words, server (SHOULD reject) is RFC compliant, client is not (MUST NOT send). regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Samsung and SIZE
On Sat, Jan 13, 2024 at 07:44:22PM +, Slavko via mailop wrote: > Dňa 13. januára 2024 19:14:58 UTC používateľ Sebastian Nielsen via mailop > napísal: > >Then you need to reconfigure server to ignore said parameters. > IMO, in other words, server (SHOULD reject) is RFC compliant, client > is not (MUST NOT send). Also section 4.5.3.1.7: | SMTP server systems that must impose restrictions SHOULD implement the | "SIZE" service extension of RFC 1870 So support for SIZE is kind of mandated since 15 years. Bastian -- Lots of people drink from the wrong bottle sometimes. -- Edith Keeler, "The City on the Edge of Forever", stardate unknown ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Samsung and SIZE
Dňa 14. januára 2024 7:55:13 UTC používateľ Bastian Blank via mailop napísal: >On Sat, Jan 13, 2024 at 07:44:22PM +, Slavko via mailop wrote: >> Dňa 13. januára 2024 19:14:58 UTC používateľ Sebastian Nielsen via mailop >> napísal: >> >Then you need to reconfigure server to ignore said parameters. >> IMO, in other words, server (SHOULD reject) is RFC compliant, client >> is not (MUST NOT send). > >Also section 4.5.3.1.7: > >| SMTP server systems that must impose restrictions SHOULD implement the >| "SIZE" service extension of RFC 1870 Not all, only when they "must impose restrictions". In other words, it is not mandated -- in the same section one can read "message size restrictions should be avoided if at all possible". regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Samsung and SIZE
- Original Message - > From: "Sebastian Nielsen via mailop" > Why is it a problem? The server ignores commands that it don't have capability > for anyways. > > Only wonkiness of Samsung Mail (same in Microsoft Outlook), I have noticed, is > that new email happens to arrive in the middle of the inbox if the sending > server has its date incorrectly set. (EXTREMELY irritating if the server is > off > by more than a day or similar). > > So I do this in my SMTP server to correct the date of all incoming emails: > > accept >remove_header = date >add_header = Date: $tod_full > > What it does, is deleting the header "Date:" and then adds a new header > "Date:" > with the actual server time of MY server. I don't have 5322 swapped in just now, but doesn't rewriting that header violate it? That header is supposed to be attached by the originating MUA, and I don't *think* transit MTAs are permitted to rewrite it... 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] Samsung and SIZE
>> 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. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
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
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
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] 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
>> 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] 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 i
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] Samsung and SIZE
On 2024-01-15 at 16:03 -0800, Randolf Richardson, Postmaster wrote: > > 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 That's the limit for the *physical* line. The Subject: header could span multiple lines and thus be larger. Not that a Subject so large would make sense. I doubt your client would be able to show it to the user. Processing the email as if the subject was made of just the first 255 characters seems acceptable to me. OTOH, I have seen people writing long emails, all in the Subject: line, with hundreds of bytes. Yes, some people advocate for subject-only emails, but it didn't seem done on purpose. https://www.lifewire.com/what-is-eom-end-of-message-1171156 It didn't make sense. The user somehow confused the field where they should write... ___ 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
