It appears that Tobias Fiebig via mailop said:
>John: Btw, what I am wondering; Given the last par of 6.3 in 7489,
>shouldn't dmarcbis switch to DMARC2, given that there are changes to
>existing tags ..
We briefly considered that and decided against it because the vast
majority of actual DMARC re
Heho,
> It's in RFC 9091 and in the DMARC update currently in draft form at
> the IETF. The intention was always that you could put private
> clauses in DMARC records which get ignored by clients that don't
> understand them, but the ABNF was overly clever. That's fixed in the
> new draft too.
On Wed, 1 Mar 2023, Jaroslaw Rafa via mailop wrote:
Dnia 28.02.2023 o godz. 16:57:51 John Levine via mailop pisze:
I have tried a vast array of things to make forwarding work to Gmail,
including ARC, and the results are at best spotty. So I tell my users
if you want to do that, here's how to
Dnia 28.02.2023 o godz. 16:57:51 John Levine via mailop pisze:
> I have tried a vast array of things to make forwarding work to Gmail,
> including ARC, and the results are at best spotty. So I tell my users
> if you want to do that, here's how to tell Gmail to pick up your mail
> from your mailbox
Heho,
On Tue, 2023-02-28 at 17:53 -0500, John R Levine wrote:
> > dmarcv1 is a typo in the description (i correctly check for DMARC1,
> > otherwise this would have shown up earlier);
> ??
>
er... DKIMv1... -.-' The check checks for v=DMARC1, not DKIMv1 as the
description implies; Currently fixing
dmarcv1 is a typo in the description (i correctly check for DMARC1,
otherwise this would have shown up earlier);
??
The actual complaint is psd=n; Lemme see if i can make the report more
clear re: where it complained.
Do you maybe have some context on psd=n? I can't find it in 7489.
It's in R
Heho,
dmarcv1 is a typo in the description (i correctly check for DMARC1,
otherwise this would have shown up earlier);
The actual complaint is psd=n; Lemme see if i can make the report more
clear re: where it complained.
Do you maybe have some context on psd=n? I can't find it in 7489.
With bes
It appears that Tobias Fiebig via mailop said:
>Heho,
>
>after our paper on mail sending configurations some time ago [1], we
>now glued that together into a self-service site:
>
>https://email-security-scans.org/
>
>I'd be happy to hear your feedback, especially if things do not work as
>expecte
It appears that Mark E. Jeftovic via mailop said:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>If you're using Sender Rewrite (SRS) with proper SPF / DKIM data and
>doing a normal rational amount of spam filtering and running a clean
>shop in terms of policing abuse, then there should be absolutely nothing
>co
It appears that ml+mailop--- via mailop said:
>On Tue, Feb 28, 2023, Andrew C Aitchison via mailop wrote:
>
>> Is there an SMTP equivalent of the HTTP 30x status codes ?
>
>Maybe this: RFC 5321:
> 551 User not local; please try (See Section 3.4)
Yes, but I doubt that anyone has actually acted
It appears that Tobias Geerinckx-Rice via mailop said:
>Is DNSSEC-signing PTR records common? Will it affect delivery in
>practice?
It's not common and I would be astonished if anyone checked as part of delivery.
I have an IPv6 tunnel from Hurricane Electric, who do not do DNSSEC on
their rDNS
If you're using Sender Rewrite (SRS) with proper SPF / DKIM data and
doing a normal rational amount of spam filtering and running a clean
shop in terms of policing abuse, then there should be absolutely nothing
controversial or egregious about email forwarding.
Forwarding email using your own
On 2023-02-28 at 13:31:13 UTC-0500 (Tue, 28 Feb 2023 18:31:13 +
(GMT))
Andrew C Aitchison via mailop
is rumored to have said:
On Tue, 28 Feb 2023, Michael Peddemors via mailop wrote:
On 2023-02-28 08:00, Mark E. Jeftovic via mailop wrote:
Hey all,
Looks like customers trying to forward
On 2023-02-28 10:46, ml+mailop--- via mailop wrote:
On Tue, Feb 28, 2023, Andrew C Aitchison via mailop wrote:
Is there an SMTP equivalent of the HTTP 30x status codes ?
Maybe this: RFC 5321:
551 User not local; please try (See Section 3.4)
Attractive idea, but impractical in the rea
On Tue, Feb 28, 2023, Andrew C Aitchison via mailop wrote:
> Is there an SMTP equivalent of the HTTP 30x status codes ?
Maybe this: RFC 5321:
551 User not local; please try (See Section 3.4)
--
Please don't Cc: me, use only the list for replies.
On Tue, 28 Feb 2023, Michael Peddemors via mailop wrote:
On 2023-02-28 08:00, Mark E. Jeftovic via mailop wrote:
Hey all,
Looks like customers trying to forward email from their own domains
here, to their O365 mailboxes are getting throttled with:
Stop 'remote forwarding'... simple..
Save
On 2023-02-28 08:00, Mark E. Jeftovic via mailop wrote:
Hey all,
Looks like customers trying to forward email from their own domains
here, to their O365 mailboxes are getting throttled with:
"451 4.7.500 Server busy. Please try again later".
O365 enterprise customers are able to whitelist th
Hey all,
Looks like customers trying to forward email from their own domains
here, to their O365 mailboxes are getting throttled with:
"451 4.7.500 Server busy. Please try again later".
O365 enterprise customers are able to whitelist the forwarder, others
are just getting perpetual deferrals
Heho,
> For DMARC, there is a parsing bug. My DMARC record consists of three
> concatenated strings, which should be joined as usual. The view
> shown in the report strips the leading and trailing double quotes,
> but not the intermediate ones:
>
> v=DMARC1; p=none; " "rua=mailto:dmarca...@tana
Heho,
> Thanks for this. I tried it a few days ago (I think because you
> posted it to opensmtpd-misc? :-)
Yeah, also shared it there, hoping for more motivation to implement
DANE/MTA-STS in OpenSMTPd. Next escalation step is releasing code i
wrote for other projects and threatening to send pat
Heho,
> Looks like an useful utility for testing these things out live.
Thanks!
> One thing though, the EHLO and rDNS comparison is case-sensitive,
> there should really be no need?
No, there indeed isn't; Thanks, good catch! Already patched and will
deploy in a bit (some more bugs to address fr
On Tue, 2023-02-28 at 12:31 +0100, Jaroslaw Rafa via mailop wrote:
>
> I do greylisting, and that's how I found out about the immediate
> retries. I run postgrey with default setting which is 5 minutes, and
> I often see in logs multiple retries within those 5 minutes, with
> first ones being real
On Mon, 2023-02-27 at 21:38 -0700, Luke wrote:
>
> First, we send a lot of email; 9 billion messages on black friday
> alone. Each message generates an average of 8 events (deferrals,
> opens, clicks, spam reports, unsubscribes etc). Storage cost is a
> small part of the reason for minimizing MTA
Hi Tobias,
Thanks for this. I tried it a few days ago (I think because you
posted it to opensmtpd-misc? :-) and without doing anything my
‘score’ went from 7 to 8 since I last checked! At this rate I
expect a 10 by Friday.
Is DNSSEC-signing PTR records common? Will it affect delivery in
Hi,
Looks like an useful utility for testing these things out live.
One thing though, the EHLO and rDNS comparison is case-sensitive, there
should really be no need?
On 27/02/2023 13:59, Tobias Fiebig via mailop wrote:
Heho,
after our paper on mail sending configurations some time ago [1],
On Mon 27/Feb/2023 12:59:04 +0100 Tobias Fiebig via mailop wrote:
I'd be happy to hear your feedback, especially if things do not work as
expected (then, your test ID and ideally stored emails would be really
helpful, so i can double check what went wrong).
My DMARC and DKIM results were ma
On 2023-02-28, Jaroslaw Rafa via mailop wrote:
> Dnia 28.02.2023 o godz. 11:10:05 Julian Bradfield via mailop pisze:
>> Maybe worth pointing that people do greylisting, and with
>> greylisting it's helpful to retry quite soon. Immediately isn't
>> useful, but within five minutes is. (I person
Dnia 28.02.2023 o godz. 11:10:05 Julian Bradfield via mailop pisze:
> On 2023-02-28, Jaroslaw Rafa via mailop wrote:
> > Another nonsense thing for me is that some senders - again, mostly the big
> > ones - retry almost *immediately* (often from a different IP address) if
> > they encounter a 4xx,
On 2023-02-28, Jaroslaw Rafa via mailop wrote:
> Another nonsense thing for me is that some senders - again, mostly the big
> ones - retry almost *immediately* (often from a different IP address) if
> they encounter a 4xx, and after a few such unsuccessful retries (within only
> a few minutes) the
Dnia 27.02.2023 o godz. 21:38:01 Luke via mailop pisze:
> Second factor (and the main factor) is our customers. We send 32 deferral
> events over the course of 72 hours to our customers' data warehouses for
> each message that reaches max queue time. That's 32 events they are
> consuming and storin
30 matches
Mail list logo
