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
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 woul
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 S
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
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 a
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 seem
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
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
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 surpr
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
> >
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
>cryptogr
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 se
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,
"mimeStructureStar
> 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 p
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,
>
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
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 filt
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
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
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 tell
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 w
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 re
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, **des
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 invali
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 ca
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 thi
26 matches
Mail list logo
