On top of that a mailbox receiving such a forwarded message could "unpack" it
automagically, provided it trusts the forwarding instance signature.
So the message appears as delivered locally with original signatures intact,
and the MUA opening the message would not have to open an attachment
Hi Laura, *!
/
The ESPs are interested in sender reputation. But, in this context, reputation
means “Our mail gets accepted at the ISPs”. In that context their reputation is
fine. They’re not being blocked. Specific customers may have delivery problems,
but a lot of the modern machine learning
/
> Maybe set up an address like mailto:spamrep...@your-provider.com where users
> should
> forward all messages they consider to be spam?
Not helpful. And please don't encourage regular users to forward spam to abuse
addresses. Forwarded mails are usually missing most relevant information which
Hey Omid,
what's wrong with our postmaster site
https://postmaster.t-online.de/index.en.html
or just contacting the address named in each and every single reject message?
Cheers
Florian
Von: mailop Im Auftrag von Omid Majdi via mailop
Gesendet: Dienstag, 11. Januar 2022 02:05
An:
Hi Stefano,
> do you have any update about this DMARC enforcement "experiment" @t-
> online.de ?
as advertised before ...
/
worst come first
Expect this procedure to hit you the earlier, the more traffic we are already
used to reject from your infrastructure.
\
did we miss to take you on into
Hi, Leandro,
> In which scenarios are there advantages on having IMAP and SMTP on
> different IPs?
[IP -> routing]
when the services are not located in the same LAN or even in a remote data
center, it will become necessary to directly address the different IP addresses
as they are routed to
https://bgp.he.net/AS16276#_prefixes
;-)
> -Ursprüngliche Nachricht-
> Von: mailop Im Auftrag von Klaus Ethgen via
> mailop
> Gesendet: Donnerstag, 12. August 2021 07:09
> An: mailop@mailop.org
> Betreff: Re: [mailop] Digital Ocean spoofing activity
>
> Hi,
>
> I used to block OVH and
Hi, is abuse@hetzner listening here?
pls. contact me off list.
Florian Kunkel
E-Mail Engineering
Deutsche Telekom AG
Deutsche-Telekom-Allee 9, 64295 Darmstadt
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Hi, Tim, Jaroslaw, *
the requirements posted before only apply to ESPs (email service providers |
mass mailers | ... mailhosters).
Mailing lists should not be concerned as far as I can tell from our stats.
The case for new infrastructure is, that you'd allow us to automate detection
and
Hi Dave, *,
/
I represent a platform that sends mail on behalf of our customers but we
maintain a separate 5321.From that points back to us.
We dual-sign messages using the client domain and our own domain, but these do
not align. We rely on DKIM alignment to pass a DMARC test.
Example:
Hi Luke, *!
/
Has anyone gotten a firm answer on these scenarios yet?
5321.from: mailto:boun...@srv12.example.com
5322.from: mailto:cont...@example.com
The vast majority of our customers will have a subdomain on the 5321 from that
isn't present on the 5322 from. I'd like to know
Hi Tom,
/
Would someone from t-online.de please publish the COMPLETE and DEFINITEIVE set
of ALL rules for sending to your customers? Preferably on your web site instead
of in mailops, so that everyone can see them?
I’ve seen bits and pieces here, with many unanswered questions. It’s not at all
Hi Tim,
all this is about domains, not local parts
> This sounds like it would break variable envelope return path
> techniques, unless a mailing list replaces the 5322.from, needlessly
> breaking a valid DKIM signature from the original sender.
so, no, VERP should be possible if within the
Hi Laura, Kai,
On 6 Apr 2021, at 12:38, Laura--- via mailop <mailto:mailop@mailop.org> wrote:
> On 6 Apr 2021, at 10:36, Florian.Kunkel--- via mailop
> <mailto:mailop@mailop.org> wrote:
>
> Just so I understand what t-online.de is announcing.
> t-online.de is looking
!
* to all those sending email without their very own static IP-Address,
* and all newly set up MTA infrastructure
... especially ESPs using IP pools professionally for their numerous customers'
mail.
!
As you might already have observed we are evaluating DKIM signatures
@t-online.de for a
/
Preventing outbound spam on a large system is a far greater challenge than
stopping inbound spam. The technical challenges are similar, but the logistical
challenges of preventing outbound spam without pissing off customers is far
greater than the challenge of preventing inbound spam without
Hi Michael,
> X-TOI-EXPURGATEID: 150726::1592860321-8954-
> 87EE5AE6/19/6861980920
> SUSPECT MAIL-COUNT
>
> Looks like your systems are aware that the sending count is probably
> compromised, but you are NOT rate limiting them?
> Examples..
> Return-Path:
> Return-Path:
as you see, the
17 matches
Mail list logo
