It appears that Tom Ivar Helbekkmo via mailop said:
>Tobias Fiebig writes:
>
>> I share your sentiment. I am not a fan of MTA-STS, and honestly not
>> really sure which problem it solves.
>
>I'm reasonably sure. The problem is: "people are starting to want DANE,
>which means we need to implement
It appears that Alex Burch via mailop said:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>I am using unicode in the From: not the MAIL FROM. Do you have to specify
>it SMTPUTF8 in the MAIL FROM to use it in the From header? I don't see
>anything about that here: https://www.rfc-editor.org/rfc/rfc6531
See section
Alex Burch via mailop skrev den 2023-03-03 00:38:
I am using unicode in the From: not the MAIL FROM. Do you have to
specify it SMTPUTF8 in the MAIL FROM to use it in the From header? I
don't see anything about that here:
https://www.rfc-editor.org/rfc/rfc6531
I was under the impression that if t
https://www.rfc-editor.org/rfc/rfc6532#section-3
> Also note that messages in this format require the use of the
> SMTPUTF8 extension [RFC6531] to be transferred via SMTP.
On Thu, Mar 2, 2023 at 3:38 PM Alex Burch wrote:
> I am using unicode in the From: not the MAIL FROM. Do you have to specify
I am using unicode in the From: not the MAIL FROM. Do you have to specify
it SMTPUTF8 in the MAIL FROM to use it in the From header? I don't see
anything about that here: https://www.rfc-editor.org/rfc/rfc6531
I was under the impression that if the client offered SMTPUTF8 extension
then you could
I don't think anyone sics lawyers on anything that small.
The sure magnitude of the abusers who use various copyrighted names and the
effort in international jurisdiction to hunt them down, good luck.
I do wish we did more at least with the bigger ones like Microsoft did
several years ago, but I
Did you specify SMTPUTF8 on the MAIL FROM command? Is swaks that smart?
doesn't look like it.
https://github.com/jetmore/swaks/blob/6bc61708489dc9789246e8fe58d32a0ff4fec8f4/swaks#L1055
Our validation cares, though it uses the same error message in either case,
so I guess it should say RFC6532 if
If Gmail is using OVH IP space, that's new ;)
EHLO command received, args: smtp-relay.gmail.com
MAIL command received, args: FROM:
54.39.168.33x10 venus.contentmarketingdigest.com
54.39.168.34x18 earth.contentmarketingdigest.com
54.39.168.35x3 mars.contentmarketingdigest
RFC 6532 indicates that you can use unicode characters like an umlaut ü
(U+00FC) if the receiving MTA supports SMTPUTF8 extension:
https://www.rfc-editor.org/rfc/rfc6532
But when I test this to Gmail its rejected:
swaks -p 25 -f 't...@acems1.com' --h-From: '"Alex" ' --to '
acaburchte...@gmail.com
Once upon a time, Tom Ivar Helbekkmo said:
> Tobias Fiebig via mailop writes:
> > If I read RFC8461 correctly, this is not required for MTA-STS policies:
>
> Until they formally override POSIX, they have to abide by it.
Since POSIX has nothing to do with network communication protocols for
emai
Tobias Fiebig via mailop writes:
> If I read RFC8461 correctly, this is not required for MTA-STS policies:
Until they formally override POSIX, they have to abide by it.
-tih
--
Most people who graduate with CS degrees don't understand the significance
of Lisp. Lisp is the most important idea
Tobias Fiebig via mailop writes:
> If I read RFC8461 correctly, this is not required for MTA-STS policies:
...begging the question whether MTA-STS is ever even interesting.
-tih
--
Most people who graduate with CS degrees don't understand the significance
of Lisp. Lisp is the most important i
Tobias Fiebig writes:
> I share your sentiment. I am not a fan of MTA-STS, and honestly not
> really sure which problem it solves.
I'm reasonably sure. The problem is: "people are starting to want DANE,
which means we need to implement DNSSEC, which will cost us money, so we
need to design an i
On Thu, 2023-03-02 at 14:53 -0500, John Levine via mailop wrote:
> In my experience very few DKIM verifiers know what to do with
> s=tlsrpt. I wouldn't look for it.
Well, the looking code is already there; But given this is
essentially a unicorn i am unlikely ever to see, i'll just
go with 'Ok' fo
On 2023-03-02 at 15:11:25 UTC-0500 (Thu, 02 Mar 2023 21:11:25 +0100)
Tobias Fiebig via mailop
is rumored to have said:
> I share your sentiment. I am not a fan of MTA-STS, and honestly not
> really sure which problem it solves.
It solves Google's problem of not wanting to deploy DNSSEC.
--
Bil
Heho,
> If I recall correctly, POSIX says that a line of text is not a line
> of text unless it ends in a proper line ending marker. I'm unsure of
> the details, here, but I am sure that when, a few years ago, I dug
> deeply into this, I concluded that the last line of a UNIX text file
> absolute
Tobias Fiebig via mailop writes:
> Besides: The CRLF thing is actually a bit funny; The RFC iirc just says
> 'delimited by', so i am not too sure whether it really must be at the
> end of the file; And then there is an errata clarifying that you can
> also delimit with LF instead of CRLF as menti
Heho,
> ...and now it gives me 9 out of 10, acknowledging that my MTA
> verifies DNSSEC and honors TLSA records.
My own domain (and the sending for email-security-scans.org) scores
9/10 as well; Mostly because OpenSMTPd lacks DANE and MTA-STS
validation... and TLS-RPT sending... that is a whole no
Tom Ivar Helbekkmo via mailop writes:
> I'll give it another go tonight, then! :)
...and now it gives me 9 out of 10, acknowledging that my MTA verifies
DNSSEC and honors TLSA records.
Of course, I'll never get a 10 out of 10. I'll implement TLS reports,
by and by, but MTA-STS will be support
It appears that Tobias Fiebig via mailop said:
>I am still not really sure what to make of it; Based on (the three)
>TLS-RPT i have seen so far, 'not using s=tlsrpt' is actually the lived
>practice. With the state of the RFC, i am not even sure whether
>s=tlsrpt would be valid to set in the first
On 2023-03-02 at 12:53:34 UTC-0500 (Thu, 2 Mar 2023 17:53:34 +
(UTC))
L. Mark Stone via mailop
is rumored to have said:
We got a ding on our DNSSEC score, because the PTR record isn't
signed. Is this really as big an issue as the explanatory test makes
out?
No. It isn't ANYTHING.
--
Bi
On Wed, 2023-03-01 at 22:02 -0500, John Levine via mailop wrote:
> In retrospect the service tag was a mistake. It's not widely
> implemented, so if you use anything other than s=email you will lose
> mail because recipient systems will get confused. The MTAs that
> receive mta-sts messages genera
Hello Mark,
> We got a ding on our DNSSEC score, because the PTR record isn't
> signed. Is this really as big an issue as the explanatory test makes
> out?
The tool looks for a perfect world, which there isn't. Un-signed rDNS
is not really a bad thing (of course, a hypothetical attacker could
Thanks for this tool, which I just ran.
We don't support IPv6, which were pretty much all of our bad scores, so not
bothered.
We got a ding on our DNSSEC score, because the PTR record isn't signed. Is this
really as big an issue as the explanatory test makes out?
"Some names needed for emai
> On 1 Mar 2023, at 16:21, John R Levine via mailop wrote:
>
>> Still, i am a bit wondering; Looking at the data flushed in so far (and
>> already multiple bugs filed against implementations)... there are a lot
>> of funny milters and often unmaintained software integrated in funny
>> docker st
Tobias Fiebig writes:
> the 'issue' was indeed that you moved the addresses to Cc: instead of
> To:; Us not checking there is actually somewhat of an oversight.
Aha! That's my MUA doing that, of course. I handle email with Gnus.
> Fixed and pushed.
I'll give it another go tonight, then! :)
Heho,
the 'issue' was indeed that you moved the addresses to Cc: instead of
To:; Us not checking there is actually somewhat of an oversight.
Fixed and pushed.
With best regards,
Tobias
On Thu, 2023-03-02 at 09:13 +0100, Tom Ivar Helbekkmo wrote:
> Tobias Fiebig via mailop writes:
>
> > If you
Tobias Fiebig via mailop writes:
> If you try this again tomorrow you have to start a new test, as tests
> that do not receive a reply within an hour get removed (minimizing data
> storage etc.)
I just did - same results, and test ID is gq7oj8xk44aw452j4e4fzf7vhpu4v3.
-tih
--
Most people who g
28 matches
Mail list logo
