Marcel Becker via mailop writes:
> That’s a FAQ:
> https://wordtothewise.com/2024/01/yahoogle-faqs/
Thanks, Marcel! I guess we're going to be all right. :)
I also note that Google and Yahoo are very much in synch on these
things. Good to know, as another large chunk of our target mailboxes
Can someone help me understand what will happen when an MTA that Google
would classify as large, thus triggering their strict compliance
requirements, sends what isn't list email, and where the idea of an
unsubscribe option doesn't make sense?
In March, the Norwegian tax authority will send email
John Levine via mailop writes:
> I realize conspiracy theories are fun, but I actually talked to the
> people who designed MTA-STS at the time they were developing it.
I guess I was a bit harsh, and also could have made it more clear that
I'm guessing at what could be the reason for such a
Chris Adams via mailop writes:
> Since POSIX has nothing to do with network communication protocols for
> email, that's a funny hill to die on. The RFC defines the response
> format, which doesn't have to be a text file on a POSIX system at all
> (could be generated on the fly, could be on a
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
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
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
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-
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! :)
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
Tobias Fiebig via mailop writes:
> If you'd like to look into this a bit more, could you maybe run another
> test, but check the box for 'store my emails'?
Will do - have been waiting for the web site to send me another mail for
a while, now, but it seems I'll have to leave it until morning.
Tobias Fiebig via mailop writes:
> https://email-security-scans.org/
Nice! A couple of comments, though:
My system has five mail items still queued, that won't be delivered.
Two because of broken DNSSEC, three because of invalid TLSA records.
(It's report ppk95bat9arnakovq5nmljen4n342u, by
Tim Bray via mailop writes:
> apt install unbound
>
> It comes configured fairly safely, listening only on localhost.
>
> and edit /etc/resolv.conf to say
>
> nameserver 127.0.0.1
>
> And there isn't much else to it for single machine. Indeed it is
> quite a good way to bring DNSSEC up to the
Felix Zielcke via mailop writes:
> T-Online (or Deutsche Telekom) require that somewhere on your domain is
> your address visible. Even if you don't have a web page at all. And
> just use the domain for sending mails.
If only there were some standardized mechanism for this information...
Ken O'Driscoll via mailop writes:
> Mailing lists etc. breaking your DKIM signature is pretty much
> expected behaviour and not a reason to disavow it entirely.
...and that doesn't need to be a problem, either, now that modern
mailing list software knows how to play nice with DMARC, like e.g.
I've been receiving a lot of spam lately from IP addresses within the
networks belonging to this organization; enough that I decided to send
some abuse complaints their way. I usually don't bother, but they have
a customer who pumps out large numbers of copies of the same two emails;
one is for
Brandon Long via mailop writes:
> A 5-10 minute delay for us is already in the realm of the second retry
> and pretty unusual unless something's going on.
OK, so maybe nowadays we ought to have that first NDR (the "for some
reason, I couldn't deliver this right away, but I'll keep trying" one)
"Rolf E. Sonneveld via mailop" writes:
> What would be a good strategy for this customer to update his list of
> contacts?
In the olden days, one would simply write a script, using expect(1) or
similar, to go through the addresses, connect to the target MTAs, and do
an SMTP VRFY on the
Brandon Long via mailop writes:
> And even if you do block at smtp time, in forwarding situations you're
> just making someone else generate the backscatter... [...]
>
> And of course, those bounces going to a mailing list just cause havoc
> for some list providers, either greatly increasing
I just briefly skimmed this very long thread, looking at messages here
and there. To the participants: "Darkness at noon", by Arthur Koestler,
is a powerful and thought-provoking book, warmly recommended.
-tih
--
Most people who graduate with CS degrees don't understand the significance
of
_dmarc.google.com IN TXT "v=DMARC1; p=reject;
rua=mailto:mailauth-repo...@google.com;
: host aspmx.l.google.com[173.194.73.26] said:
550-5.2.1 The user you are trying to contact is receiving mail at a rate
that 550-5.2.1 prevents additional messages from being delivered. For more
Jeremy Harris via mailop writes:
> On 11/07/2019 16:58, Ross Tajvar via mailop wrote:
>> do any major mail services actually validate these records when receiving
>> mail? Do any major mail clients?
>
> DANE is relevant to sending mail, not receiving.
> That doesn't answer your question, though.
Al Iverson via mailop writes:
> Rob, you're treating it as an attack when I don't really think it is.
In all probability, it wasn't intended as one, but, probably because of
frustration, it came out looking that way. On a public mailing list, it
was (in effect, if not on purpose) calibrated to
I think maybe it's time to start redirecting this recipient to /dev/null
locally, just to avoid these postmaster messages. This is from yesterday:
: host mta7.am0.yahoodns.net[67.195.228.94] said: 554
delivery error: dd Sorry, your message to dmarc_y_...@yahoo.com cannot be
delivered.
Brielle Bruns writes:
> EXIM is generating that list based on RFC 4871 (Section 5.5 lists
> recommended).
There's a discrepancy in the wording, though.
The RFC says, about the list given: "The following header fields SHOULD
be included in the signature, if they are present in the message being
This was fixed, but now it's happened again:
: tih@thuvia:~; host -t txt _dmarc.yahoo.com
_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100;
rua=mailto:dmarc_y_...@yahoo.com;;
From my postmaster mail:
: host mta6.am0.yahoodns.net[98.137.159.27] said: 554
delivery error: dd
Syed Alam writes:
> Since 8th of March we determined an enormous global increase of below
> bounce message from Yahoo MX:
>
> 554 delivery error: dd Sorry, your message to x...@yahoo.com cannot be
> delivered. This mailbox is disabled (554.30). - mta4101.mail.bf1.yahoo.com
I've noticed, too.
28 matches
Mail list logo
