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
- 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
>
> >> 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
>> 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
> >> 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
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
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
>
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
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...
>> 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
- 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
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
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
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
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
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,
n 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 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
18 matches
Mail list logo
