You just regard all email which passes DMARC as trusted, as if the mail was
S/MIME signed by the sender personally.The sender has chosen to trust that
shared provider. Its not "your problem" as a receiver if that mail is
fraudulent.If you act on a fraudulent email, sent by a fraudster via a shar
Dnia 10.02.2024 o godz. 05:02:12 Sebastian Nielsen via mailop pisze:
> Disadvantages --> Every email will look like an empty email containing a
> attachment that you have to click to open.
Many antispam filters will right away classify such an email as spam.
> Also, that’s how forwarding ALWAYS h
Dnia 12.02.2024 o godz. 01:36:09 Benny Pedersen via mailop pisze:
> if spf should be pr email addresses, thay could add ipv6 pr sender
> email :=)
>
> and have ipv4 with nullMX or simply remove ipv4 in mx, will it ever
> happen ?
Yeah, use only IPv6 for sending mail and cut off deliverability to
Dnia 10.02.2024 o godz. 12:42:36 L. Mark Stone via mailop pisze:
> 1. We have trained our Zimbra users who want their email to be copied
> someplace else to configure the someplace else to log in and collect their
> email from Zimbra, after having educated them that Forwarding is
> problematic and
Dnia 10.02.2024 o godz. 07:52:43 Sebastian Nielsen via mailop pisze:
> Try it yourself in your email software.
> Click Forward.
> Sending this email will basically rewrite the headers and add Fwd: into
> subject.
>
> You can also click "Forward as an attachment", which will forward the
> original
Dnia 11.02.2024 o godz. 00:10:54 Thomas Walter via mailop pisze:
> Remember when we had an SMTP status code 551?
>
> 551 User not local; please try
Would be an ideal solution if sending SMTP servers would actually react to
it like web browsers react to HTTP 301 or 302 status code, ie. automatic
>>Many antispam filters will right away classify such an email as spam.
No, that’s not true, UNLESS the antispam filter resides as a local software in
the client's software as a plugin to the email client, which would of course
detect the "attached file" even its not technically an attached file
Jaroslaw Rafa via mailop skrev den 2024-02-12 11:34:
Dnia 12.02.2024 o godz. 01:36:09 Benny Pedersen via mailop pisze:
if spf should be pr email addresses, thay could add ipv6 pr sender
email :=)
and have ipv4 with nullMX or simply remove ipv4 in mx, will it ever
happen ?
Yeah, use only IPv6
On 12.02.24 11:59, Jaroslaw Rafa via mailop wrote:
Dnia 11.02.2024 o godz. 00:10:54 Thomas Walter via mailop pisze:
Remember when we had an SMTP status code 551?
551 User not local; please try
Would be an ideal solution if sending SMTP servers would actually react to
it like web browsers
The problem with encapsulating like that is it basically makes it impossible to
respond to the original email sender. It destroys functionality that has been
around since the early stages of email. If we’re going to break email for
people, then we should at least give them some good reason to br
Dnia 12.02.2024 o godz. 12:15:08 Sebastian Nielsen via mailop pisze:
>
> However, if an end user SENDS something via the proxy, let's say a forum
> post, the proxy usually bears the responsibility for the content, which we
> have seen in numerous court cases where a proxy have been used to hide th
Dnia 10.02.2024 o godz. 11:18:17 Al Iverson via mailop pisze:
> That error message, though, makes it sounds
> like IP reputation which is a rare error.
Actually, it has been mentioned here on this list several times. It usually
happens "out of the blue", for servers that were able to send OK previ
>> it basically makes it impossible to respond to the original email sender
Nope, you just open the encapsulated email (open the .EML attachment), and
respond to that.
Some mail clients show the encapsulated email in a “frame” which has its own
reply buttons.
Best regards, Sebastian Niel
>> An "anonymous" proxy, configured specifically to hide the original poster
No, all proxies are per definition anonymous unless they specifically add the
header X-Forwaded-For.
Otherwise, the IP becomes “automatically” hidden, if it passes communication
unmodified.
That’s why they have become r
Dnia 12.02.2024 o godz. 14:44:43 Sebastian Nielsen via mailop pisze:
>
> Nope, you just open the encapsulated email (open the .EML attachment), and
> respond to that.
Very cumbersome. Speaking from my own experience.
--
Regards,
Jaroslaw Rafa
r...@rafa.eu.org
--
"In a million years, when k
> On 12 Feb 2024, at 13:44, Sebastian Nielsen via mailop
> wrote:
>
> >> it basically makes it impossible to respond to the original email sender
> Nope, you just open the encapsulated email (open the .EML attachment), and
> respond to that.
>
> Some mail clients show the encapsulated email
Am 10.02.2024 um 15:52:22 Uhr schrieb Andre van Eyssen:
> On Fri, 9 Feb 2024, Marco Moock via mailop wrote:
>
> > Outlook supports that and knowing about it is a question of
> > training.
>
> I'd like to suggest that understanding of email is declining in the
> general population. "Training"
Dnia 12.02.2024 o godz. 14:47:41 Sebastian Nielsen via mailop pisze:
> When you pass traffic on layer 7, you are the de facto recipient of the
> traffic, and when you then “resend” that received traffic somewhere else
> than its actually destined, you become responsible. That’s why a reverse
> pro
Am 09.02.2024 um 22:06:05 Uhr schrieb Sebastian Nielsen via mailop:
> Or people could stop forwarding emails in idiotic ways, because when
> you forward an email, you are actually forging the original sender.
>
>
> Ergo, if you forward a email from genuineu...@genuineserver.com to
> myacco...@gm
Am 09.02.2024 um 13:59:57 Uhr schrieb Andy Smith via mailop:
> When these people are your paying customers, or you are being paid
> to get email to these people, there is limited up side in berating
> people about their choice of mail service. A fact which of course is
> used and abused by the hug
>>Do they also allow you to search for the original sender?
No not via sender search, as the encapsulated email is part of the BODY of the
container email.
So usually you have to search via body search.
>>And, again, what is the overall benefit to the end user from this scheme?
Benefit is
Hi,
On Mon, Feb 12, 2024 at 02:44:43PM +0100, Sebastian Nielsen via mailop wrote:
> >> it basically makes it impossible to respond to the original email sender
>
> Nope, you just open the encapsulated email (open the .EML attachment), and
> respond to that.
Going back to my anecdote that last m
> On 12 Feb 2024, at 14:33, Sebastian Nielsen via mailop
> wrote:
>
> >>Do they also allow you to search for the original sender?
> No not via sender search, as the encapsulated email is part of the BODY of
> the container email.
> So usually you have to search via body search.
So you are st
On 2024-02-12 at 07:13:13 UTC-0500 (Mon, 12 Feb 2024 13:13:13 +0100)
Thomas Walter via mailop
is rumored to have said:
> There are other issues with this though. For example you are exposing
> information you might not want to.
Beyond that, it would enable both malicious reflection attacks and
It appears that Sebastian Nielsen via mailop said:
>-=-=-=-=-=-
>-=-=-=-=-=-
>You just regard all email which passes DMARC as trusted, as if the mail was
>S/MIME signed by the sender personally.The sender has
>chosen to trust that shared provider. Its not "your problem" as a receiver if
>that ma
> Dnia 9.02.2024 o godz. 13:03:28 Philip Paeps via mailop pisze:
> >
> > Most people don't actually use email anymore. Email is for
> > marketing and receipts.
>
> Yeah, that's probably the main reason why they can live with such
> problematic service like Gmail.
I've encountered more
Hey Bill,
On 12.02.24 17:31, Bill Cole via mailop wrote:
On 2024-02-12 at 07:13:13 UTC-0500 (Mon, 12 Feb 2024 13:13:13 +0100)
Thomas Walter via mailop
is rumored to have said:
There are other issues with this though. For example you are exposing
information you might not want to.
Beyond th
It appears that Laura Atkins via mailop said:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>The problem with encapsulating like that is it basically makes it impossible
>to respond to the original email sender. It destroys
>functionality that has been around since the early stages of email. If we’re
>going to br
How is everyone handling senders that sign their emails with RSA-SHA1 DKIM
keys?
I'm a bit surprised to see eBay and Match.com sending out messages using
SHA-1.
I'm seeing a lot of signatures coming in that use SHA-1 but most of the
domains are questionable at best. But eBay and Match.com caught
Note: not specifically in response to the message I'm replying to!
Having just read the last 30 or so messages in this thread, I'm afraid it's
all starting to feel very very circular.
1. Forwarding is a basic feature of MUAs and mail systems, whether by user
choice, rules, or "forward all" re
On 2/9/2024 6:50 AM, Scott Mutter via mailop wrote:
I think the issue with SPF and DKIM is that it's becoming trivial for
ALL email to have SPF and DKIM that pass muster. At which point,
you're right back where you started.
At the start, we had no way to assess email streams. Good mixed wit
On 2024-02-12 at 14:23:39 UTC-0500 (Mon, 12 Feb 2024 20:23:39 +0100)
Thomas Walter via mailop
is rumored to have said:
> Hey Bill,
>
> On 12.02.24 17:31, Bill Cole via mailop wrote:
>> On 2024-02-12 at 07:13:13 UTC-0500 (Mon, 12 Feb 2024 13:13:13 +0100)
>> Thomas Walter via mailop
>> is rumored
SHA-1 was SHOULD NOT for a decade, but still in too wide of use, so we
chartered DCRUP at the IETF to deprecate it (and keys < 1024 bits) and also
to separately add ed25519.
Here's the RFC deprecating SHA-1: https://datatracker.ietf.org/doc/rfc8301/
Chances are both your examples are using the sa
On 2/9/2024 1:16 AM, Taavi Eomäe via mailop wrote:
My hope is that at some point we would be able to do "BIMI" with just
S/MIME signed mail at some point. Seems like a good combination.
1. S/MIME has been around for 25 years. While it has gained
respectable amounts of implementation in MU
> BIMI is a marketing protocol, for promoting brand logos. What anti-abuse
> benefit do you believe accrues with its use, and how exactly do you believe
> it will achieve that?
>
> d/
But Dave - It only costs $1300USD per domain and $500USD for each
additional domain for the cert, not including
On 12.02.24 21:21, Bill Cole via mailop wrote:
The mail server providing the redirection may not be doing what the original
address owner OR the owner of the address to which they are redirecting
actually wants. Redirection could allow malicious server operators to direct
3rd parties to send
On Mon, Feb 12, 2024 at 2:48 PM Damon via mailop wrote:
>
> I do believe attaching anti-spam/anti-phish benefits to the promotion
> of BIMI was a poor choice.
>
Wait. Somebody managed to combine two dumpster fire topics into one?
Forwarding and BIMI? Well done...
-- Marcel
_
On Mon, 12 Feb 2024, Dave Crocker wrote:
1. S/MIME has been around for 25 years. While it has gained
respectable amounts of implementation in MUAs, it has achieved use
only in specialized environments.
Google could greatly accelerate its uptake by automatically providing
every freemai
On 2/12/2024 4:37 PM, Mark Milhollan via mailop wrote:
On Mon, 12 Feb 2024, Dave Crocker wrote:
1. S/MIME has been around for 25 years. While it has gained
respectable amounts of implementation in MUAs, it has achieved use
only in specialized environments.
Google could greatly accelerat
On Mon, 12 Feb 2024, Dave Crocker wrote:
On 2/12/2024 4:37 PM, Mark Milhollan via mailop wrote:
On Mon, 12 Feb 2024, Dave Crocker wrote:
1. S/MIME has been around for 25 years. While it has gained
respectable amounts of implementation in MUAs, it has achieved use
only in specialized
It appears that Mark Milhollan via mailop said:
>On Mon, 12 Feb 2024, Dave Crocker wrote:
>
>> 1. S/MIME has been around for 25 years. While it has gained
>>respectable amounts of implementation in MUAs, it has achieved use
>>only in specialized environments.
>
>Google could greatly acce
On 2/12/2024 7:16 PM, John Levine via mailop wrote:
Right now if
you get a message from Gmail or Yahoo with a valid DKIM signature, you
can be quite confident that it came from whichever Gmail or Yahoo user
is in the From header.
By way of using this as an example of the need for larger syste
On 2/12/2024 7:13 PM, Mark Milhollan via mailop wrote:
On Mon, 12 Feb 2024, Dave Crocker wrote:
Certificates are not magic symbols of safety.
I never said they were. I said, paraphrasing though I see I should
have been explicit, that Google could increase the number of people
using S/MIME
43 matches
Mail list logo