Re: [mailop] Line too long

[John R Levine via mailop]

On Fri, 17 May 2024, Brandon Long wrote:

I don't know anyone who uses BINARYMIME.  Microsoft's MTAs say they do
but I've never tried to see if it works.


We did some testing with it and got some really inconsistent end to end 
responses even from services which advertised it.  The idea of saving 
bytes by not using base64 was appealing.


Back in 2016 I proposed CDAT which is like BDAT but with deflate 
compression (what gzip uses.)  That would shrink base64 to no bigger than 
the original data, but nobody was interested.


https://www.ietf.org/archive/id/draft-levine-smtp-compress-00.txt


And BINARYMIME is incompatible with the line length limit unless your
content happens to have new-lines in the right places or is shorter than
1000 bytes.


Right, the binary data probably isn't text so if it has any \r\n pairs 
it's just an accident.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Line too long

[Brandon Long via mailop]

On Fri, May 17, 2024 at 4:18 PM John Levine  wrote:

> It appears that Brandon Long via mailop  said:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >
> >RFC 3030 which provides for the BDAT command and BINARYMIME which treats
> >the message not as text at all
> >and so I wouldn't expect that that text limit would apply, though the RFC
> >doesn't discuss any limits.
>
> It says that even if you support BDAT you still have to support DATA,
> so there's no difference in what you're allowed to send. Also note
> that RFC5322 includes the 1000 character limit independent of the
> transport.
>
> I don't know anyone who uses BINARYMIME.  Microsoft's MTAs say they do
> but I've never tried to see if it works.
>

We did some testing with it and got some really inconsistent end to end
responses even from
services which advertised it.  The idea of saving bytes by not using base64
was
appealing.

And BINARYMIME is incompatible with the line length limit unless your
content happens to have new-lines in the right places or is shorter than
1000 bytes.

Brandon
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Alex Liu via mailop]

I dont know this is that new with regard to DMARC. missing citation:
https://www.usenix.org/system/files/sec20-chen-jianjun.pdf

It is, however, the first time someone tries to combine with BIMI.

Every a few months we see a paper / blogpost that passes SPF / DKIM /
DMARC. So maybe requiring both SPF and DKIM for BIMI would be a good idea.

On Fri, May 17, 2024 at 3:14 PM Taavi Eomäe via mailop 
wrote:

> On 17/05/2024 18:37, Slavko via mailop wrote:
>
> I didn't get what is **new** in it, nor how length of RSA keys is related...
>
> Turning the original content into a comment seemed novel to us, should in
> theory yield better forgeries than just adding new boundaries. Gmail's
> "show original" also seems to hide such comments for some reason (making it
> extra nasty).
>
>
> The l= DKIM tag was problematic in time of RFC, the Content-Type
> constructs core of message, thus have to be (over)signed already.
>
> As written, it has been known for a while. But given how prevalent it
> really is and how it has opened up new avenues of abuse, we felt it was
> time to call for some action once again.
>
>
> Best Regards
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>


-- 
Regards,
*Enze "**Alex" **Liu*
PhD Student
Department of Computer Science and Engineering
e7...@eng.ucsd.edu
University of California, San Diego
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Line too long

[John Levine via mailop]

It appears that Brandon Long via mailop  said:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>RFC 3030 which provides for the BDAT command and BINARYMIME which treats
>the message not as text at all
>and so I wouldn't expect that that text limit would apply, though the RFC
>doesn't discuss any limits.

It says that even if you support BDAT you still have to support DATA,
so there's no difference in what you're allowed to send. Also note
that RFC5322 includes the 1000 character limit independent of the
transport.

I don't know anyone who uses BINARYMIME.  Microsoft's MTAs say they do
but I've never tried to see if it works.

>In general, I don't see much utility in limiting the length of lines in the
>body of messages in the modern
>age.  Headers and command/responses, sure.

I asked Ned Freed about this one time and he said that in his threaded
mail server they had thousand byte buffers, and it would have been
quite painful to try and handle lines that didn't fit in them. It's
Oracle's server, used by a lot of enterprise systems.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Spamhaus and Vultr

[J Doe via mailop]

On 2024-05-12 13:46, Al Iverson via mailop wrote:


Even if this wasn't happening, you should still go sign up for DQS.

Cheers,
Al Iverson


Hi Lyle and Al,

Thanks for your responses to my query.

I have signed up for SpamHaus' DQS service and tested my e-mail config
via their test website and all is good to go!

- J
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Taavi Eomäe via mailop]

On 17/05/2024 18:37, Slavko via mailop wrote:

I didn't get what is **new** in it, nor how length of RSA keys is related...


Turning the original content into a comment seemed novel to us, should 
in theory yield better forgeries than just adding new boundaries. 
Gmail's "show original" also seems to hide such comments for some reason 
(making it extra nasty).




The l= DKIM tag was problematic in time of RFC, the Content-Type
constructs core of message, thus have to be (over)signed already.


As written, it has been known for a while. But given how prevalent it 
really is and how it has opened up new avenues of abuse, we felt it was 
time to call for some action once again.



Best Regards



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Mark E. Mallett via mailop]

On Fri, May 17, 2024 at 02:11:04PM -0700, Brandon Long via mailop wrote:
> I guess the part that's new to me is the apparent widespread (enough) use
> of the l=
> parameter.  I don't recall ever noticing its use before, though can't say
> it was ever top
> of mind when looking at various headers of messages.

I had noticed receiving some with l=1 not too long ago and went looking
and saw some others with l=0. I thought it was pretty weird, especially
the 1, but didn't record any details about it.

mm  (although it was kind of interesting that it passed)

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Line too long

[Brandon Long via mailop]

RFC 3030 which provides for the BDAT command and BINARYMIME which treats
the message not as text at all
and so I wouldn't expect that that text limit would apply, though the RFC
doesn't discuss any limits.

In general, I don't see much utility in limiting the length of lines in the
body of messages in the modern
age.  Headers and command/responses, sure.

I assume people implemented to the Postel idea, and maybe even corrected
messages when forwarding...
but such corrections break dkim signatures now, which caused us to
reevaluate message "corrections"
when comparing the options of "being rejected/marked as spam" vs "rejected
for message formatting violations".

I think this is a general problem with text based protocols, people think
they're easy and can be done by hand,
and then things get complicated but you still deal with people doing
/bin/sendmail foo < file or whatever without
actually using libraries to properly compose messages... and so that works
until it doesn't.

It turns out people just want to get their mail, they don't want to be
proper email/smtp formating pedantics.

Brandon

On Fri, May 17, 2024 at 12:01 AM Cyril - ImprovMX via mailop <
mailop@mailop.org> wrote:

> Hi everyone!
>
> I've got an email from one of my user telling me our server refused an
> email because of a line too long.
> The issue is referenced in the RFC at
> https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1.6 and we
> follow and respect that recommandation.
>
> I would not have raised this question here except that the user recently
> moved from Cloudflare to us, and they shared with us a past email sent by
> Sendgrid, that went through Cloudflare, and landed in their gmail inbox
> successfully, **despite having a line of 1201 characters.
>
> So, I wonder, is there another RFC that specifies a bigger line length, or
> are the RFC here just for decoration?
>
> Thank you for your help!
>
> Best regards,
> Cyril - ImprovMX 
> ___
> 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] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[John R Levine via mailop]

On Fri, 17 May 2024, Brandon Long wrote:
I guess the part that's new to me is the apparent widespread (enough) 
use of the l= parameter.  I don't recall ever noticing its use before, 
though can't say it was ever top of mind when looking at various headers 
of messages.


I have to admit I'm surprised too.  I thought everyone knew it was bad.

In my file of DKIM signatures in newsletter/mailing list mail I've gotten 
over the past 15 years, I have about 200,000 signatures of which 6500 have 
l=something.  I divided it in half, and since 2018 there are 98,000 
signatures of which only 500 have l=something.


It's not very common and it's gotten less common, like one message in 
2000, but it does exist.



The example in the post of someone using l=1 really sounds like a
workaround for


I looked, I see a bunch of l=1 in mailings from the libertarians at 
reason.com which makes a perverse kind of sense.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Brandon Long via mailop]

On Fri, May 17, 2024 at 1:07 PM John Levine via mailop 
wrote:

> It appears that Taavi Eomäe via mailop  said:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >Hi!
> >
> >As part of coordinated disclosure, I am sharing it here as well. In
> >short, using the approach described below, attackers can replace the
> >entire contents of a letter, in a way the letters still pass DKIM’s
> >cryptographic checks. ...
>
> There is nothing whatsoever new here.
>
> We knew l= was a bad idea when we published it, and that you could do
> all sorts of naughty things by adding or fiddling with MIME parts.
> Some loud people insisted that it would solve the mailing list
> problem, which of course it didn't, but we're stuck with it now.
>
> I suppose it couldn't hurt to remind people that using l= is a bad
> idea but if they haven't already gotten the memo sometime in the past
> decade, I wouldn't hold my breath.
>

I guess the part that's new to me is the apparent widespread (enough) use
of the l=
parameter.  I don't recall ever noticing its use before, though can't say
it was ever top
of mind when looking at various headers of messages.

The example in the post of someone using l=1 really sounds like a
workaround for
receivers requiring DKIM signing but senders having fear of messages getting
modified and rejected.  I am both in awe at the hacker make it work ethos
displayed
as well as the complete disregard for authentication.  I'm curious what
mitigation
gmail deployed short of just ignoring the l= value entirely, which would be
my
impulse though depending on how widespread it might require an annoying
amount
of outreach and rollout time to force correction.

Brandon
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[John Levine via mailop]

It appears that Taavi Eomäe via mailop  said:
>-=-=-=-=-=-
>-=-=-=-=-=-
>Hi!
>
>As part of coordinated disclosure, I am sharing it here as well. In 
>short, using the approach described below, attackers can replace the 
>entire contents of a letter, in a way the letters still pass DKIM’s 
>cryptographic checks. ...

There is nothing whatsoever new here. 

We knew l= was a bad idea when we published it, and that you could do
all sorts of naughty things by adding or fiddling with MIME parts.
Some loud people insisted that it would solve the mailing list
problem, which of course it didn't, but we're stuck with it now.

I suppose it couldn't hurt to remind people that using l= is a bad
idea but if they haven't already gotten the memo sometime in the past
decade, I wouldn't hold my breath.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Does iCloud accept forwards?

[John Levine via mailop]

It appears that Mark Fletcher via mailop  said:
>Can you please have your email administrators check your SPF / DKIM
>>  settings and ensure that mail sent from your domain has valid DMARC
>> signatures in accordance with the DMARC policies that you have defined for
>> your domain.
>
>As you can see we are not able to validate your SPF and DKIM records:
>
>> < Dkim :dkim=fail reason="signature verification failed" (2048-bit key)
>> header.d=groups.io header.i=@groups.io header.b=Y9CUx0w1>

Something is strange there. I get lots of mail from groups.io and it
all has valid DKIM signatures. They also rewrite From: headers to
avoid overeager DMARC policies.

R's,
John

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Andris Reinman via mailop]

The mailauth command can detect these signatures
https://github.com/postalsys/mailauth/blob/master/cli.md

For example

$ mailauth report path-to-email.eml

"canonBodyLength": 87122,
"canonBodyLengthTotal": 87563,
"canonBodyLengthLimited": true,
"canonBodyLengthLimit": 87122,
"mimeStructureStart": 87076,


This signature uses the l-tag (canonBodyLengthLimited is true). 87122 bytes
of canonicalized body were used for the signature hash (canonBodyLength),
while the actual canonicalized body length was 87563 bytes
(canonBodyLengthTotal) and the first byte of the actual mime tree (the
first byte of the first boundary in the canonicalized body) was at 87076
bytes (mimeStructureStart) which means that only 46 bytes of the mime
structure were covered by the signature and 441 bytes were not signed at
all. So, this message content is most likely forged, and the BIMI logo
should not be displayed even though the signature is "valid".

Best regards,
Andris Reinman

Kontakt Gellner, Oliver via mailop () kirjutas kuupäeval
R, 17. mai 2024 kell 21:42:

>
> > On 17.05.2024 at 16:24 Taavi Eomäe via mailop wrote:
> >
> > Although some of these dangers have been known for a while (some parts
> are even described in the RFC itself), things like the threat landscape,
> our approach and the extent to which this can be abused have changed. In
> our opinion previously suggested and (rarely) implemented mitigations do
> not reduce these risks sufficiently.
> >
> > We hope that with some cooperation from mail operators improved defense
> measures can be implemented to strengthen DKIM for everyone.
> >
> >
> > A longer description with images is available here:
> https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/
>
> While it’s not new information that the length attribute of DKIM poses a
> security risk, it’s still worthwhile to draw attention to it every once in
> a while and the usual suspects who keep on using it.
>
> What would be interesting is a list of software that is able to ignore
> DKIM signatures which contain a length attribute and how to configure this
> behavior.
>
> —
> BR Oliver
>
> 
>
> dmTECH GmbH
> Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
> Telefon 0721 5592-2500 Telefax 0721 5592-2777
> dmt...@dm.de * www.dmTECH.de
> GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
> Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
> 
> Datenschutzrechtliche Informationen
> Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser
> ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in
> Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder
> sich bei uns bewerben, verarbeiten wir personenbezogene Daten.
> Informationen unter anderem zu den konkreten Datenverarbeitungen,
> Löschfristen, Ihren Rechten sowie die Kontaktdaten unserer
> Datenschutzbeauftragten finden Sie hier<
> https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832
> >.
> ___
> 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] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Gellner, Oliver via mailop]

> On 17.05.2024 at 16:24 Taavi Eomäe via mailop wrote:
>
> Although some of these dangers have been known for a while (some parts are 
> even described in the RFC itself), things like the threat landscape, our 
> approach and the extent to which this can be abused have changed. In our 
> opinion previously suggested and (rarely) implemented mitigations do not 
> reduce these risks sufficiently.
>
> We hope that with some cooperation from mail operators improved defense 
> measures can be implemented to strengthen DKIM for everyone.
>
>
> A longer description with images is available here: 
> https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/

While it’s not new information that the length attribute of DKIM poses a 
security risk, it’s still worthwhile to draw attention to it every once in a 
while and the usual suspects who keep on using it.

What would be interesting is a list of software that is able to ignore DKIM 
signatures which contain a length attribute and how to configure this behavior.

—
BR Oliver



dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Jeroen Massar via mailop]

And the reason why wanting to require both SPF _and_ DKIM passing would be a 
good thing...

Unfortunately one cannot do that.

Greets,
 Jeroen

--

> On 17 May 2024, at 16:12, Taavi Eomäe via mailop  wrote:
> 
> Hi!
> 
> As part of coordinated disclosure, I am sharing it here as well. In short, 
> using the approach described below, attackers can replace the entire contents 
> of a letter, in a way the letters still pass DKIM’s cryptographic checks. 
> This also means these forged letters can be easily replayed to reach their 
> victims. This subverts many of the expectations operators have about DKIM 
> signatures, DMARC and BIMI.
> 
> Although some of these dangers have been known for a while (some parts are 
> even described in the RFC itself), things like the threat landscape, our 
> approach and the extent to which this can be abused have changed. In our 
> opinion previously suggested and (rarely) implemented mitigations do not 
> reduce these risks sufficiently.
> 
> We hope that with some cooperation from mail operators improved defense 
> measures can be implemented to strengthen DKIM for everyone.
> 
> 
> A longer description with images is available here: 
> https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/
> 
> 
> 
> Best Regards,
> Taavi Eomäe
> Zone Media OÜ
> 
> ___
> 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] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Slavko via mailop]

Dňa 17. mája 2024 14:12:41 UTC používateľ "Taavi Eomäe via mailop" 
 napísal:

>A longer description with images is available here: 
>https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/

I didn't get what is **new** in it, nor how length of RSA keys is related...

The l= DKIM tag was problematic in time of RFC, the Content-Type
constructs core of message, thus have to be (over)signed already.

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Marco Moock via mailop]

Am Fri, 17 May 2024 16:04:56 +0100 (BST)
schrieb Andrew C Aitchison via mailop :

> If the mail system uses a DKIM pass to show the *other pieces*
> of the message as trusted, then bad things can happen.

I don't know any end users system that shows those results to the user.
I only know MTA's filtering on that results.
Are there other cases?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Andrew C Aitchison via mailop]

On Fri, 17 May 2024, Taavi Eomäe via mailop wrote:

As part of coordinated disclosure, I am sharing it here as well. In short, 
using the approach described below, attackers can replace the entire contents 
of a letter, in a way the letters still pass DKIM’s cryptographic checks. 
This also means these forged letters can be easily replayed to reach their 
victims. This subverts many of the expectations operators have about DKIM 
signatures, DMARC and BIMI.


Although some of these dangers have been known for a while (some parts are 
even described in the RFC itself), things like the threat landscape, our 
approach and the extent to which this can be abused have changed. In our 
opinion previously suggested and (rarely) implemented mitigations do not 
reduce these risks sufficiently.


We hope that with some cooperation from mail operators improved defense 
measures can be implemented to strengthen DKIM for everyone.


A longer description with images is available here: 
https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/


Of course.
DKIM signs *pieces* of an email.

If the mail system uses a DKIM pass to show the *other pieces*
of the message as trusted, then bad things can happen.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Taavi Eomäe via mailop]

Hi!

As part of coordinated disclosure, I am sharing it here as well. In 
short, using the approach described below, attackers can replace the 
entire contents of a letter, in a way the letters still pass DKIM’s 
cryptographic checks. This also means these forged letters can be easily 
replayed to reach their victims. This subverts many of the expectations 
operators have about DKIM signatures, DMARC and BIMI.


Although some of these dangers have been known for a while (some parts 
are even described in the RFC itself), things like the threat landscape, 
our approach and the extent to which this can be abused have changed. In 
our opinion previously suggested and (rarely) implemented mitigations do 
not reduce these risks sufficiently.


We hope that with some cooperation from mail operators improved defense 
measures can be implemented to strengthen DKIM for everyone.



A longer description with images is available here: 
https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/




Best Regards,
Taavi Eomäe
Zone Media OÜ



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Line too long

[Cyril - ImprovMX via mailop]

Thank you all for the feedback.

I absolutely agree with you Olivier, this makes complete sense!

Cyril - ImprovMX


Le vendredi 17 mai 2024 à 10:42, Gellner, Oliver via mailop  
a écrit :

> On 17.05.2024 at 08:48 Cyril - ImprovMX via mailop wrote:
> 
> > I've got an email from one of my user telling me our server refused an 
> > email because of a line too long.
> > The issue is referenced in the RFC at 
> > https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1.6 and we 
> > follow and respect that recommandation.
> > I would not have raised this question here except that the user recently 
> > moved from Cloudflare to us, and they shared with us a past email sent by 
> > Sendgrid, that went through Cloudflare, and landed in their gmail inbox 
> > successfully, **despite having a line of 1201 characters.
> 
> 
> If you know that your MTA is the final destination of the email you could 
> accept it even if the line is too long. However given the fact that you run 
> an email forwarding service I wouldn't be liberal in what I accept, as 
> there's always the risk that the next hop is going to reject the invalid 
> message.
> 
> --
> BR Oliver
> 
> 
> dmTECH GmbH
> Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
> Telefon 0721 5592-2500 Telefax 0721 5592-2777
> dmTECH@dm.demailto:dmt...@dm.de * www.dmTECH.dehttp://www.dmtech.de
> 
> GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
> Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
> 
> Datenschutzrechtliche Informationen
> Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
> ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
> Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder 
> sich bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen 
> unter anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren 
> Rechten sowie die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
> hierhttps://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832.
> 
> ___
> 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] Line too long

[Marco Moock via mailop]

Am 17.05.2024 um 17:51:33 Uhr schrieb Andre van Eyssen via mailop:

> Turns out *some* mail platforms cope with having binaries just
> stuffed into the mail and some silently fail.

The postmasters who allow non-standard e-mail are the problem here. If
every MTA rejected such messages, the origin would quickly fix it every
time.

-- 
kind regards
Marco

Send unsolicited bulk mail to 1715961093mu...@cartoonies.org
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Line too long

[Gellner, Oliver via mailop]

On 17.05.2024 at 08:48 Cyril - ImprovMX via mailop wrote:

> I've got an email from one of my user telling me our server refused an email 
> because of a line too long.
> The issue is referenced in the RFC at 
> https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1.6 and we follow 
> and respect that recommandation.
> I would not have raised this question here except that the user recently 
> moved from Cloudflare to us, and they shared with us a past email sent by 
> Sendgrid, that went through Cloudflare, and landed in their gmail inbox 
> successfully, **despite having a line of 1201 characters.

If you know that your MTA is the final destination of the email you could 
accept it even if the line is too long. However given the fact that you run an 
email forwarding service I wouldn't be liberal in what I accept, as there's 
always the risk that the next hop is going to reject the invalid message.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Line too long

[Andre van Eyssen via mailop]

On Fri, 17 May 2024, Cyril - ImprovMX via mailop wrote:

I would not have raised this question here except that the user recently 
moved from Cloudflare to us, and they shared with us a past email sent 
by Sendgrid, that went through Cloudflare, and landed in their gmail 
inbox successfully, **despite having a line of 1201 characters.


I just can't help but wonder why they're sending email with lines that 
long. Is it symtomatic of a deeper problem?


Background for askin': many years ago, one of the Java developers crossed 
the border into sysadmin land and complained that application-sent mail 
was bouncing for line length. Upon examination of his code, we found he 
was just dumping binaries straight into email without any (e.g., base64) 
encoding. Education was provided, encoding was done and amazingly a lot of 
the "I didn't get your email!" type complaints started going away.


Turns out *some* mail platforms cope with having binaries just stuffed 
into the mail and some silently fail.


--
Andre van Eyssen.  Phone: +61 417 211 788
mail: an...@purplecow.org  http://andre.purplecow.org
About & Contact:  http://www.purplecow.org/andre.html
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Line too long

[ml+mailop--- via mailop]

On Fri, May 17, 2024, Cyril - ImprovMX via mailop wrote:

> So, I wonder, is there another RFC that specifies a bigger line length,

No.

> or are the RFC here just for decoration?

"We don't care. We don't have to. We are the phone company".

Of course you could argue to "be nice and accept invalid stuff"
(which might cause problems -- see "SMTP smuggling").
Maybe you can check whether those services allow to send out
lines that are too long?

-- 
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] [NEWSLETTER] Line too long

[Stephan Hradek via mailop]

Hi Cyril

The RFC you linked states "This number may be increased by the use of SMTP 
Service Extensions."

This sounds to me like: Longer lines might work, but are not guaranteed.

So why not stick to the official limit of 998 + CRLF?

What's the purpose of having longer linses?

After all they can be folded, can't they? 
https://datatracker.ietf.org/doc/html/rfc5322

> Am 17.05.2024 um 08:48 schrieb Cyril - ImprovMX via mailop 
> :
> 
> Hi everyone!
> 
> I've got an email from one of my user telling me our server refused an email 
> because of a line too long.
> The issue is referenced in the RFC at 
> https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1.6 and we follow 
> and respect that recommandation.
> 
> I would not have raised this question here except that the user recently 
> moved from Cloudflare to us, and they shared with us a past email sent by 
> Sendgrid, that went through Cloudflare, and landed in their gmail inbox 
> successfully, **despite having a line of 1201 characters.
> 
> So, I wonder, is there another RFC that specifies a bigger line length, or 
> are the RFC here just for decoration?
> 
> Thank you for your help!
> 
> Best regards,
> Cyril - ImprovMX 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop



smime.p7s
Description: S/MIME cryptographic signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Line too long

[Cyril - ImprovMX via mailop]

Hi everyone!

I've got an email from one of my user telling me our server refused an email 
because of a line too long.
The issue is referenced in the RFC at 
https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1.6 and we follow 
and respect that recommandation.

I would not have raised this question here except that the user recently moved 
from Cloudflare to us, and they shared with us a past email sent by Sendgrid, 
that went through Cloudflare, and landed in their gmail inbox successfully, 
**despite having a line of 1201 characters.

So, I wonder, is there another RFC that specifies a bigger line length, or are 
the RFC here just for decoration?

Thank you for your help!

Best regards,
Cyril - [ImprovMX](https://improvmx.com)___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop