On Sun 16/Jun/2024 16:38:48 +0200 Tobias Fiebig via mailop wrote:
You'd need several domains, all having a rua= pointing to you. I'd
donate a (sub) domain to that effort. I'm donating a couple of
domains to Project Honey Pot. Unlike that project, however, in this
case donated domains will
Moin,
> You'd need several domains, all having a rua= pointing to you. I'd
> donate a (sub) domain to that effort. I'm donating a couple of
> domains to Project Honey Pot. Unlike that project, however, in this
> case donated domains will have to actively send replies.
Actually LUA records wit
On Sat 15/Jun/2024 18:27:15 +0200 Tobias Fiebig via mailop wrote:
Do reports received at dm...@aperture-labs.org contribute to the
output of email-security-scans?
No, of course not; esec.o is tests-are-atomic. Technically I _could_
(or rather: should) try to implement something similar to wh
Moin,
> There is a /human_result/ in DMARC reports. It would be a good idea
> to check whether there are (new) messages there, and bring it to
> human attention in case. Not doing so deprives the field of its
> /human/ attribute.
Ah, makes sense; Still, just noting that most analysis software
On Thu 13/Jun/2024 11:14:04 +0200 Tobias Fiebig via mailop wrote:
What if spamd, while authenticating a malformed signature, notifies
the error in DMARC report? Would that "fix" spamd?
Would be somewhat pointless, though; From the top of my head I am not
sure whether there is a fitting fiel
Moin,
> What if spamd, while authenticating a malformed signature, notifies
> the error in DMARC report? Would that "fix" spamd?
Would be somewhat pointless, though; From the top of my head I am not
sure whether there is a fitting field; And apart from that, I doubt
anyone would read those mail
On Sun 09/Jun/2024 02:43:38 +0200 Tobias Fiebig via mailop wrote:
On Sat, 2024-06-08 at 12:36 +0200, Alessandro Vesely via mailop wrote:
... (unless bugs in email-security-scans are just decorative.)
Which ones exactly?
What if spamd, while authenticating a malformed signature, notifies the
On Sat, 2024-06-08 at 12:36 +0200, Alessandro Vesely via mailop wrote:
> ... (unless bugs in email-security-scans are just decorative.)
Which ones exactly?
With best regards,
Tobias
--
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tob...@fiebig.nl
___
On Sat 08/Jun/2024 13:28:30 +0200 Slavko via mailop wrote:
Dňa 8. júna 2024 10:36:44 UTC používateľ Alessandro Vesely via mailop
napísal:
Yes, as it seems Tobias is going to file a bug against rspamd, I presume you
are going to somehow fix it (unless bugs in email-security-scans are just
de
Dňa 8. júna 2024 10:36:44 UTC používateľ Alessandro Vesely via mailop
napísal:
>Yes, as it seems Tobias is going to file a bug against rspamd, I presume you
>are going to somehow fix it (unless bugs in email-security-scans are just
>decorative.)
I have nothing to do with email-security-scans,
On Fri 07/Jun/2024 17:03:00 +0200 Slavko via mailop wrote:
Dňa 7. júna 2024 14:37:24 UTC používateľ Alessandro Vesely via mailop
napísal:
If I were Slavko I'd fix rspamd by adding bug reporting (if it's not already
there) rather than removing 2047-decoding.
Are you sure, that you did mean
It appears that Tobias Fiebig via mailop said:
>
>Moin,
>
>On Thu, 2024-06-06 at 12:44 +1000, Viktor Dukhovni via mailop wrote:
>> The distinction is essential, because it would be a terrible mistake
>> to, for example, RFC2047-encode the "mailbox" construct in "From",
>> "To", ... headers. An RF
Dňa 7. júna 2024 14:37:24 UTC používateľ Alessandro Vesely via mailop
napísal:
>If I were Slavko I'd fix rspamd by adding bug reporting (if it's not already
>there) rather than removing 2047-decoding.
Are you sure, that you did mean me?
I was just curious about IDNA syntax in this case...
re
On Wed 05/Jun/2024 11:58:53 +0200 John Levine via mailop wrote:
It appears that Tobias Fiebig via mailop said:
Well, that would then be rspamd and the python email parser; Question
is whether that would qualify as a bug, i.e., 'should not validate'; My
understanding would be more in a 'be libe
In message ,
Tobias Fiebig via mailop writes
>My point here is, that 'deliverability' is often more of a priority for
>ESPs than 'following all documents to the letter'. Granted, for the
>bigger ones, usually more like 'outbound deliverability' than 'inbound
>deliverability', though.
>
>Hence
On Thu, Jun 06, 2024 at 10:23:28AM +0200, Tobias Fiebig via mailop wrote:
> > To a degree, but not to the point of accepting total garbage
> > (RFC2047-encoded DKIM-Signature headers), or especially, generating
> > total garbage (producing RFC2047-encoded DKIM-Signature headers).
>
> Just to clar
Moin,
On Thu, 2024-06-06 at 17:53 +1000, Viktor Dukhovni via mailop wrote:
> It is also, IIRC, a DKIM *signer* and verifier. DKIM signing and
> verification needs to interoperate.
> ...
> To a degree, but not to the point of accepting total garbage
> (RFC2047-encoded DKIM-Signature headers), or e
On Thu, Jun 06, 2024 at 08:38:48AM +0100, Vsevolod Stakhov via mailop wrote:
> > Such willful disregard of essential interoperability requirements in
> > "rspamd" means I will not use it unless you back off from your current
> > position, and will strongly discourage others (e.g. postfix-users lis
Moin,
On Thu, 2024-06-06 at 12:44 +1000, Viktor Dukhovni via mailop wrote:
> The distinction is essential, because it would be a terrible mistake
> to, for example, RFC2047-encode the "mailbox" construct in "From",
> "To", ... headers. An RFC2047-ignorant MUA or MTA can still
> correctly decode
On 06/06/2024 03:44, Viktor Dukhovni via mailop wrote:
On Wed, Jun 05, 2024 at 05:29:16PM +0100, Vsevolod Stakhov via mailop wrote:
In fact, the original distinction between structured and unstructured
headers defined in the RFC2047 just makes parsing extremely complicated and
I personally cons
On Wed, Jun 05, 2024 at 05:29:16PM +0100, Vsevolod Stakhov via mailop wrote:
> In fact, the original distinction between structured and unstructured
> headers defined in the RFC2047 just makes parsing extremely complicated and
> I personally consider it as an example of a standard being accepted w
On 05/06/2024 10:25, Viktor Dukhovni via mailop wrote:
On Wed, Jun 05, 2024 at 11:08:31AM +0200, Tobias Fiebig via mailop wrote:
Yeah, I misread 8616 there, then; My brain somewhat autoclicked to
"well, if there can be UTF8 you must be able to mime encode."
No, RFC2047 encoding of headers app
It appears that Tobias Fiebig via mailop said:
>Moin,
>> In this case, if DKIM validators correctly rejected the invalid
>> signatures, this mistake would have been caught and fixed more
>> quickly.
>So, back to the initial question: Would it make sense if i'd file a bug
>against rspamd?
Sure. S
Moin,
> In this case, if DKIM validators correctly rejected the invalid
> signatures, this mistake would have been caught and fixed more
> quickly.
So, back to the initial question: Would it make sense if i'd file a bug
against rspamd?
With best regards,
Tobias
--
Dr.-Ing. Tobias Fiebig
T +31 61
Dňa 5. júna 2024 9:49:11 UTC používateľ Viktor Dukhovni via mailop
napísal:
>For maximal simplicity and robustness use the same encoding of domain
>names (U-labels or A-labels) in "d=" and "i=" as you do (or would, if
>there was "alignment") in "From:".
Thanks to both, i think i got it now.
re
It appears that Tobias Fiebig via mailop said:
>Well, that would then be rspamd and the python email parser; Question
>is whether that would qualify as a bug, i.e., 'should not validate'; My
>understanding would be more in a 'be liberal in what you accept and
>conservative and what you send'-sense
On Wed, Jun 05, 2024 at 11:30:27AM +0200, Slavko via mailop wrote:
> Do you want to tell, that if d= and/or s= tags contains internationalized
> domain name/label, it must be in A-label (ASCII encoded) form? Or how it is
> supposed to be handled please?
For maximal simplicity and robustness use t
It appears that Slavko via mailop said:
>Do you want to tell, that if d= and/or s= tags contains
>internationalized domain name/label, it must be in A-label (ASCII
>encoded) form? Or how it is supposed to be handled please?
See RFC 8616. That is precisely what it is about.
R's,
John
_
Dňa 5. 6. o 11:00 John R Levine via mailop napísal(a):
I wouldn't verify that either. It's just wrong. You're not allowed to
MIME encode strings in a DKIM-Signature header.*
I don't argue, i am just curious, as i never think about it yet.
Do you want to tell, that if d= and/or s= tags contai
On Wed, Jun 05, 2024 at 11:08:31AM +0200, Tobias Fiebig via mailop wrote:
> Yeah, I misread 8616 there, then; My brain somewhat autoclicked to
> "well, if there can be UTF8 you must be able to mime encode."
No, RFC2047 encoding of headers applies only to header parts that are an
ABNF *phrase* in
Moin,
> I wouldn't verify that either. It's just wrong. You're not allowed
> to MIME encode strings in a DKIM-Signature header.*
Yeah, I misread 8616 there, then; My brain somewhat autoclicked to
"well, if there can be UTF8 you must be able to mime encode."
> * - I'm pretty sure that if you a
On Wed, 5 Jun 2024, Tobias Fiebig wrote:
If you're not sending SMTPUTF8 mail, the DKIM signature headers
should be ASCII with no encoding needed. But if you are ending
SMTPUTF8 mail, you can put UTF-8 directly in the header and it
doesn't need any futher encoding either.
Yeah, even more odd, th
Hello John,
> If you're not sending SMTPUTF8 mail, the DKIM signature headers
> should be ASCII with no encoding needed. But if you are ending
> SMTPUTF8 mail, you can put UTF-8 directly in the header and it
> doesn't need any futher encoding either.
Yeah, even more odd, the actual data did not
According to Tobias Fiebig via mailop :
>Moin,
>
>to share some closure on this with the rest of the list; What was
>ultimately the issue was an RFC8616 based DKIM-Signature header, i.e.,
>containing UTF-8 encoded fields (in this case, even though there were
>no non-ascii characters in them). ...
Moin,
to share some closure on this with the rest of the list; What was
ultimately the issue was an RFC8616 based DKIM-Signature header, i.e.,
containing UTF-8 encoded fields (in this case, even though there were
no non-ascii characters in them). While rspamd on my machine did not
have an issue, f
Moin,
got it, thx.
With best regards,
Tobias
On Mon, 2024-06-03 at 21:36 +0200, Tobias Fiebig via mailop wrote:
> Moin,
>
> tl;dr: Could someone do https://email-security-scans.org from
> meta.com,
> storing mails on the server and sharing the link with me to help me
> debug a deliverability iss
36 matches
Mail list logo
