Re: [mailop] How to ensure ownership from a Microsoft email?

[Cyril - ImprovMX via mailop]

Thank you all for your input.

@Graeme, I'd join @John on this; if Microsoft can validate a domain DNS, they 
should make it mandatory to sign using the domain name and not some 
unverifiable *.onmicrosoft.com.
Nowadays even more when you want to have domain alignment with DMARC.

@Olivier, your input is interesting. I agree that an account can be 
compromised, but I'm more worried about ways to send an email on behalf of a 
domain without compromising the account, which isn't great.

Cyril - ImprovMX


Le mercredi 5 juin 2024 à 13:53, Gellner, Oliver via mailop  
a écrit :

> On 05.06.2024 at 09:48 Cyril - ImprovMX via mailop wrote:
> 
> > I got a few suspicious emails from a user.
> > I wanted to check the DKIM Signature of that domain to validate the 
> > ownership but the emails are coming from Microsoft, which signs the email 
> > using "{domain name}http://aotearoaenergy.onmicrosoft.com;
> > In my case, the sender is from aotearoa.energy and the d= part of the 
> > dkim-signature is http://aotearoaenergy.onmicrosoft.com
> 
> > Now, I wonder. Can I trust Microsoft that if they send an email on behalf 
> > of aotearoa.energy, they initially validated the ownership or is there a 
> > way to bypass that?
> 
> 
> There is some validation, but researchers have discovered various ways to 
> send emails on behalf of a domain without:
> https://www.usenix.org/conference/usenixsecurity21/presentation/shen-kaiwen
> https://research.utwente.nl/en/publications/forward-pass-on-the-security-implications-of-email-forwarding-mec
> https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/
> Besides that Microsoft does not enforce MFA for email accounts, so a weak or 
> reused password of one user is all that it takes to send authenticated emails 
> from that domain.
> 
> I'd closely check the headers whether anything looks suspicious.
> 
> --
> BR Oliver
> 
> 
> dmTECH GmbH
> Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
> Telefon 0721 5592-2500 Telefax 0721 5592-2777
> dmTECH@dm.demailto:dmt...@dm.de * www.dmTECH.dehttp://www.dmtech.de
> 
> GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
> Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
> 
> Datenschutzrechtliche Informationen
> Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
> ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
> Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder 
> sich bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen 
> unter anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren 
> Rechten sowie die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
> hierhttps://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832.
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] How to ensure ownership from a Microsoft email?

[Cyril - ImprovMX via mailop]

Hi everyone!

I got a few suspicious emails from a user.
I wanted to check the DKIM Signature of that domain to validate the ownership 
but the emails are coming from Microsoft, which signs the email using "{domain 
name}[.onmicrosoft.com](http://aotearoaenergy.onmicrosoft.com)"
In my case, the sender is from aotearoa.energy and the d= part of the 
dkim-signature is aotearoaenergy.onmicrosoft.com

Now, I wonder. Can I trust Microsoft that if they send an email on behalf of 
aotearoa.energy, they initially validated the ownership or is there a way to 
bypass that?

For those curious, the story is absolutely shady but valid at every step:

I got an initial email from "TP Icap", but with the domain "icap.com" saying 
they acquired aotearoa.energy.
I checked and it's true, TP Icap really acquired the service Aotearoa.

If you go to aotearoa.energy, you'll see a blank "NGINX" page, and if you go to 
www.aotearoa.energy, you'll get ... a logo.

A few days later, I got an email from them about an onboarding questionnaire 
that I have to fill (but first need to create an account on another service, 
Process Unity system).
This questionnaire includes general informations (company name, address, etc) 
but also asks me about bank details!

All of this because Microsoft is unable to properly sign an email with the 
sender's domain to prove ownership...

Cyril - [ImprovMX](https://improvmx.com)___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Line too long

[Cyril - ImprovMX via mailop]

Thank you all for the feedback.

I absolutely agree with you Olivier, this makes complete sense!

Cyril - ImprovMX


Le vendredi 17 mai 2024 à 10:42, Gellner, Oliver via mailop  
a écrit :

> On 17.05.2024 at 08:48 Cyril - ImprovMX via mailop wrote:
> 
> > I've got an email from one of my user telling me our server refused an 
> > email because of a line too long.
> > The issue is referenced in the RFC at 
> > https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1.6 and we 
> > follow and respect that recommandation.
> > I would not have raised this question here except that the user recently 
> > moved from Cloudflare to us, and they shared with us a past email sent by 
> > Sendgrid, that went through Cloudflare, and landed in their gmail inbox 
> > successfully, **despite having a line of 1201 characters.
> 
> 
> If you know that your MTA is the final destination of the email you could 
> accept it even if the line is too long. However given the fact that you run 
> an email forwarding service I wouldn't be liberal in what I accept, as 
> there's always the risk that the next hop is going to reject the invalid 
> message.
> 
> --
> BR Oliver
> 
> 
> dmTECH GmbH
> Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
> Telefon 0721 5592-2500 Telefax 0721 5592-2777
> dmTECH@dm.demailto:dmt...@dm.de * www.dmTECH.dehttp://www.dmtech.de
> 
> GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
> Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
> 
> Datenschutzrechtliche Informationen
> Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
> ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
> Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder 
> sich bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen 
> unter anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren 
> Rechten sowie die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
> hierhttps://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832.
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Line too long

[Cyril - ImprovMX via mailop]

Hi everyone!

I've got an email from one of my user telling me our server refused an email 
because of a line too long.
The issue is referenced in the RFC at 
https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1.6 and we follow 
and respect that recommandation.

I would not have raised this question here except that the user recently moved 
from Cloudflare to us, and they shared with us a past email sent by Sendgrid, 
that went through Cloudflare, and landed in their gmail inbox successfully, 
**despite having a line of 1201 characters.

So, I wonder, is there another RFC that specifies a bigger line length, or are 
the RFC here just for decoration?

Thank you for your help!

Best regards,
Cyril - [ImprovMX](https://improvmx.com)___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Cyril - ImprovMX via mailop]

>
> That's precisely the problem: As long as you don't enforce STARTTLS, you
> do not raise the bar or improve security by disabling TLS 1.0 or 1.1,
> because the least secure "protocol", namely no encryption at all, is still
> enabled.
>

Yes! I entirely agree with that!

Le jeu. 14 mars 2024 à 10:45, Gellner, Oliver via mailop 
a écrit :

> On 14.03.2024 at 09:37 Cyril - ImprovMX via mailop wrote:
>
> > We previously were accepting only TLS 1.2 and higher and I was surprised
> to see the amount of senders not being able to find common ciphers (I had
> mostly encounters with Cisco users), so we decided to also accept TLS 1.0
> and 1.1.
> > But in my opinion, moving the needle upward by not accepting deprecated
> versions would force those users to be compliant and improve the general
> security.
>
> That's precisely the problem: As long as you don't enforce STARTTLS, you
> do not raise the bar or improve security by disabling TLS 1.0 or 1.1,
> because the least secure "protocol", namely no encryption at all, is still
> enabled.
> For services which only allow encrypted connections I'm all for removing
> support for TLS 1.1 and everything below. But we cannot enforce TLS on the
> public MX servers as long as no large ESPs make this move first.
>
> --
> BR Oliver
> 
>
> dmTECH GmbH
> Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
> Telefon 0721 5592-2500 Telefax 0721 5592-2777
> dmt...@dm.de<mailto:dmt...@dm.de> * www.dmTECH.de<http://www.dmtech.de>
> GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
> Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
> 
> Datenschutzrechtliche Informationen
> Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser
> ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in
> Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder
> sich bei uns bewerben, verarbeiten wir personenbezogene Daten.
> Informationen unter anderem zu den konkreten Datenverarbeitungen,
> Löschfristen, Ihren Rechten sowie die Kontaktdaten unserer
> Datenschutzbeauftragten finden Sie hier<
> https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832
> >.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Cyril - ImprovMX via mailop]

>
> Given that TLS encryption in SMTP is hop-by-hop rather than end-to-end,
> I am not convinced that this is a significant reduction in security.
>

Wouldn't it be because you assume that at some point, the security will be
either non-existent or low (TLS 1.0/1.1 or fallback to unsecured
transaction), which is the entire point of forcing to upgrade the security?

Or, if I take the idea the other way around, assuming that "TLS encryption
in SMTP is hop-by-hop" and implying that some hop won't be as secure, isn't
then having TLS encryption a false sense of security ?

(If my message appears aggressive or disrespectful, I'm sorry, that isn't
my intention).

Le jeu. 14 mars 2024 à 10:24, Andrew C Aitchison via mailop <
mailop@mailop.org> a écrit :

> On Thu, 14 Mar 2024, Marco Moock via mailop wrote:
>
> > Am 14.03.2024 schrieb Cyril - ImprovMX via mailop :
> >
> >> But in my opinion, moving the needle upward by not accepting
> >> deprecated versions would force those users to be compliant and
> >> improve the general security.
> >
> > Most of them will simply fall back to no encryption. That is the
> > default setting and only a small amount of servers makes using STARTTLS
> > mandatory for outgoing mail - too many situations when it fails.
>
> Given that TLS encryption in SMTP is hop-by-hop rather than end-to-end,
> I am not convinced that this is a significant reduction in security.
>
> For IMAP and POP, encryption is end-to-end, but there you know, and
> presumably have control over, your users.
>
> --
> Andrew C. Aitchison  Kendal, UK
> and...@aitchison.me.uk
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Cyril - ImprovMX via mailop]

We previously were accepting only TLS 1.2 and higher and I was surprised to
see the amount of senders not being able to find common ciphers (I had
mostly encounters with Cisco users), so we decided to also accept TLS 1.0
and 1.1.

But in my opinion, moving the needle upward by not accepting deprecated
versions would force those users to be compliant and improve the general
security.

If we decide to keep old versions in place because not everyone can
upgrade, will we still accept TLS 1.0 in 10 years from now ? 20 ? 50 ?

And if that's the case, why bother working on more secure ciphers ?

Le mer. 13 mars 2024, 22:24, Thomas Walter via mailop  a
écrit :

>
>
> On 13.03.24 18:55, Slavko via mailop wrote:
> > Dňa 13. marca 2024 16:32:42 UTC používateľ Andrew C Aitchison via mailop
>  napísal:
> >
> >> Has anyone checked what traffic is still using TLS 1.0 or TLS 1.1 ?
> >
> > Yes, some infected machines from DZ, BR, AR, ID and so :-)
> So we are removing a perfectly good marker to increase spam scores?
>
> Just saying... :-)
>
> Regards,
> Thomas Walter
>
> --
> Thomas Walter
> Datenverarbeitungszentrale
>
> FH Münster
> - University of Applied Sciences -
> Corrensstr. 25, Raum B 112
> 48149 Münster
>
> Tel: +49 251 83 64 908
> Fax: +49 251 83 64 910
> www.fh-muenster.de/dvz/
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Dot as the first character of a line ? (RFC 5321, Section 4.5.2)

[Cyril - ImprovMX via mailop]

We finally found the original issue. It was related to the library from the
sender that was dot stuffing using a regex without the Global flag in
place...

They sent a PR to the library.

I learned some stuff with this issue !

Thanks everyone for your help here.

Best regards,
Cyril
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Recommended ciphers used for ESMTP connections

[Cyril - ImprovMX via mailop]

Thank you everyone for your responses. It makes sense to not have a
restricted set of ciphers.
Eray, your explanation made perfect sense and adding the precision about no
known downgrade attack makes me revise the cipers we use.

I'm also going to read the PDF eBulldog shared.

Thank you all so much for your input, I appreciate it!

Best regards
Cyril

Le mar. 5 mars 2024 à 09:47, Eray Aslan via mailop  a
écrit :

> On Mon, Mar 04, 2024 at 05:30:54PM +0100, Cyril - ImprovMX via mailop
> wrote:
> > On our send, we decided to use the ciphers suggested by Mozilla on their
> > SSL Configuration Generator (https://ssl-config.mozilla.org/) (level
> > "Intermediate") but I'm aware it's more for the HTTPS connections that
> > ESMTP / TLS.
>
> Exactly. SMTP is not HTTPS. Too restrictive a setting either results in
> interoperability problems or plain text transmission. Leaving TLS1.0
> enabled is fine with SMTP. If you support TLS1.2 and the client supports
> TLS1.2, there is no known downgrade attack to TLS1.0.
>
> [...]
> > And we only accept TLS at v1.2 and higher.
>
> It is 2024 but this is still, unfortuntely, not advisable. In SMTP,
> increased security is achieved via raising the ceiling. Raising the
> floor is counter productive. It is opportunistic encryption and
> multi-hop. Different design choices different implications.
>
> --
> Eray
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Recommended ciphers used for ESMTP connections

[Cyril - ImprovMX via mailop]

Hi everyone,

Some users are reaching out to us telling they have issues connecting to
our service because of incompatibility between the set of ciphers offered
during the connection.

On our send, we decided to use the ciphers suggested by Mozilla on their
SSL Configuration Generator (https://ssl-config.mozilla.org/) (level
"Intermediate") but I'm aware it's more for the HTTPS connections that
ESMTP / TLS.

So maybe there is another set of ciphers recommended for creating secured
connections in email that I'm not aware of. Do you have any recommendations
for this or is the ones from Mozilla (Intermediate) is good enough?

If you want to avoid loading the link, here are the ciphers suggested by
them:

Ciphers: 
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305

Cipher
suites: 
TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

And we only accept TLS at v1.2 and higher.

Thank you in advance.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Dot as the first character of a line ? (RFC 5321, Section 4.5.2)

[Cyril - ImprovMX via mailop]

Thanks everyone for your responses. I responded during the weekend but my
email was too big and got rejected. It's not relevant anymore.

Pointing out the fact that the dot-stuffing works on the two sides (adding
then removing) shows that in the current scenario, the issue is either
caused by the sender or by us, and not between us and Gmail.

I still don't have the root cause of this as we are investigating it. The
sender claims they are adding an extra dot when needed, and the aiosmtpd
library on which we relies does remove them. I'm starting to wonder if the
issue isn't related to something else.
I'm discussing with the sender on ways to get a raw email from them and
check where the email starts breaking the DKIM signature.

I'll keep you updated once we get to the root of the issue for those who
are interested to find out.

Have a nice week!
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Dot as the first character of a line ? (RFC 5321, Section 4.5.2)

[Cyril - ImprovMX via mailop]

@Julien Bradfield:
I've initially shared the exact line in the code on what Aiosmtpd - not my
software - is doing, which it is saying is following the RFC by removing
the first character if it's a dot. I could share emails that went
through Aiosmtpd and another that didn't, which would only show that the
one that didn't still has a starting dot whereas the other doesn't. I don't
see what I can add on top of that. It seems clear, precise and detailed as
it includes references and links. If anything is missing, coud you please
ask clearly and precisely what do you expect more from it?

@John Levine , I'm not sure which line you are mentioning,
the one I used from the RFC ("... If the first character is a period and
there are other characters on the line, the first character is deleted.")
does mention "deleted", not "inserted".
>From where did you get your quote?


Le ven. 1 mars 2024 à 20:04, John Levine  a écrit :

> It appears that Cyril - ImprovMX via mailop  said:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >
> >Just to clarify, I'm not trying to pin some issue on a company (Google)
> but
> >I'm trying to understand why aiosmtpd seems to follow an RFC that
> >appears to be clear on the behavior, that GMail doesn't do but doesn't
> >appear to be the only one (as my user is generating a document that also
> >doesn't seems to follow it).
> >
> >I'm more thinking about a different interpretation on the RFC that leads
> to
> >various behavior between aiosmtpd and (some) others.
>
> You might want to reread the paragraph before the one you quoted in your
> last message:
>
>o  Before sending a line of mail text, the SMTP client checks the
>   first character of the line.  If it is a period, one additional
>   period is inserted at the beginning of the line.
>
> It's quite clear, and if your software isn't adding a second dot in front
> of the
> line that starts with a dot, it's wrong.
>
> R's,
> John
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Dot as the first character of a line ? (RFC 5321, Section 4.5.2)

[Cyril - ImprovMX via mailop]

Just to clarify, I'm not trying to pin some issue on a company (Google) but
I'm trying to understand why aiosmtpd seems to follow an RFC that
appears to be clear on the behavior, that GMail doesn't do but doesn't
appear to be the only one (as my user is generating a document that also
doesn't seems to follow it).

I'm more thinking about a different interpretation on the RFC that leads to
various behavior between aiosmtpd and (some) others.

Le ven. 1 mars 2024 à 18:10, Dave Crocker  a écrit :

>
> On 3/1/2024 8:57 AM, Mark Fletcher via mailop wrote:
>
> You're talking about 'dot stuffing'. When you receive a message via SMTP,
> in the DATA section, if you receive a line that starts with a dot (and has
> additional characters after that), you remove that first dot.
>
> Then, when you send the message back out via SMTP, for lines that start
> with a dot, you prepend a dot before sending the line on the wire.
>
>
> Just to make sure it's clear to everyone that this is in the SMTP spec:
>
> RFC 5321: Simple Mail Transfer Protocol <#m_6162241132587272556_>
>
>  https://www.rfc-editor.org/rfc/rfc5321#section-4.5.2
> 
>
>
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorkingbbiw.netmast:@dcrocker@mastodon.social
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Dot as the first character of a line ? (RFC 5321, Section 4.5.2)

[Cyril - ImprovMX via mailop]

Hey everyone,

I got a really strange issue today which boils down to how we interpret the
RFC.

A user reached out to us saying their email, when going through ImprovMX,
where then failing the DKIM Signature.

Upon investigation, we discovered that indeed, checking the DKIM signature
was failing because of a body mismatch. Digging further, we discovered that
a dot was removed from the message when going through our servers.

It turns out that one of their link in the email is broken into multiple
line (following the RFC on that) and surprisingly, the dot from
"www.domain" was starting as the new line, which gives:

.domain.com/path/


The RFC 5321, Section 4.5.2
 says :

 When a line of mail text is received by the SMTP server, it checks the
> line. If the line is composed of a single period, it is treated as the end
> of mail indicator. If the first character is a period and there are other
> characters on the line, the first character is deleted.


 Which is why aiosmtpd is doing :
https://github.com/aio-libs/aiosmtpd/blob/master/aiosmtpd/smtp.py#L1489

We discovered the issue because the destination server, Google, was putting
the email in spam as it wasn't respecting the DMARC (of course, the DKIM
Signature was broken).

Upon further investigation, we realized that GMail does NOT respect that
RFC. They keep the dot. And if you add two dots, as per the RFC, GMail will
keep the two dots, making the URL broken.

So, I'm reaching out to you in the hope to have some help on what do to.

Part of me want to reply to that user that we have to follow the RFC, but
maybe we are following the wrong RFC? I don't know, honestly.

Thank you for your help !
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is forwarding to Gmail basically dead?

[Cyril - ImprovMX via mailop]

> Even if you catch spam emails with SPF, I think you should be able to
> distinguish between legitimate emails -- this is forwarding emails.

SPF/DKIM/DMARC and spam are two entirely different things.
Talking about spam and SPF is like talking about fish and fruit salad.

I think John Levine now has an automated snippet to mention this every 15
minutes ;)

Le mer. 14 févr. 2024 à 13:34, Byunghee HWANG (황병희) via mailop <
mailop@mailop.org> a écrit :

> Hellow Cyril,
>
> On Wed, 2024-02-14 at 11:06 +0100, Cyril - ImprovMX via mailop wrote:
> > That's a good argument. I can do even better:
> >
> > Email is not designed for spam. Stop spamming. Problem solved.
>
> Yes, you are right. And I know what you're thinking.
>
> But please give me a chance to say this.
>
> Even if you catch spam emails with SPF, I think you should be able to
> distinguish between legitimate emails -- this is forwarding emails.
>
> Isn't it?
>
> That's why I like Google. Google accepts forwarding emails even if
> SPF/DMARC fails.
>
>
> Sincerely, Byunghee
>
> ps. Your mail was my spam trap -- HTML Email.
>
> --
> ^고맙습니다 _布德天下_ 감사합니다_^))//
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is forwarding to Gmail basically dead?

[Cyril - ImprovMX via mailop]

That's a good argument. I can do even better:

Email is not designed for spam. Stop spamming. Problem solved.

...

Le mer. 14 févr. 2024 à 01:56, Benny Pedersen via mailop 
a écrit :

> Byunghee HWANG  via mailop skrev den 2024-02-14 01:00:
>
> > I really strongly agree with this opinion. That's why I wish people in
> > the world didn't use SPF. SPF is a serious obstacle when forwarding.
>
> spf is not designed for forwarding, stop forwarding, problem solved
>
> dmarc need spf to find aligned mails
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is forwarding to Gmail basically dead?

[Cyril - ImprovMX via mailop]

I agree with Slavko here.
Uceprotect must not be used to block spammers as it wrongly list entire
block that includes legitimate sender in it, for the sole purpose that some
spammers are in that block.

But to get circle back at email forwarding and Gmail issues, there is one
point that bothers me with ARC and I'd like that someone could tell me that
I'm wrong (with valid arguments, of course).

ARC tells the receiver party that the sender is not the original one, but
that sender signed the previous state of AR headers (SPF, DKIM and DMARC
state), which they now somehow broke but "it's okay because the original
source was different".

Now, if I'm a bad person, I can easily create fake previous headers that
looks like it's coming from, say, the IRS, and say that it's passing the
SPF and DMARC with great success. I would sign my ARC with my domain, which
I control, and in theory, the receiving party would receive an email from
me, supposedly originated from the IRS with valid SPF and DMARC because I
told so, and signed it ?

This would work if you could trust me in that scenario, but how can you?

I'm definitely opposed on building a (white) list of allowed domains, as it
would give even more power to the big ones (you'd certainly include GAFAM
in it) and gives nearly an impossible state for all the small ones, or the
new ones.

If you exclude that whitelisting, ARC (for validating) is absolutely
useless.
Am I wrong?

Le ven. 9 févr. 2024 à 08:03, Slavko via mailop  a
écrit :

> Dňa 9. februára 2024 6:11:29 UTC používateľ Marco Moock via mailop <
> mailop@mailop.org> napísal:
>
> >dnsbl exists and some lists (e.g. uceprotect L3) entirely list ISPs
> >that have a huge amount of spammers in their network.
> >The more servers that block those ISPs, the less customers will use
> >them for mail.
>
> No, that is wrong understanding of UCEPROTECT's L2 & L3,
> they are for signaling to ISPs, that something is wrong in their
> network(s).
>
> As i prove some months ago, L2 listed whole /22 block due
> 4 or 7 (i don't remember exactly, you can search archive) issues.
> Do you consider that as huge? I don't...
>
> But yes, using its L2/L3 to reject will solve all your issues with
> incoming mails and you save a lot of disk space :-D
>
> regards
>
>
> --
> Slavko
> https://www.slavino.sk/
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is forwarding to Gmail basically dead?

[Cyril - ImprovMX via mailop]

This is an interesting topic (I'm running an email forwarding service
so...).

Please correct me if I'm wrong but I think it's not entirely that bad.

First, I agree with Jarland that ARC doesn't fixes anything, it only gives
more power to those who already have too much.

But forwarding an email from a domain that have DMARC enabled (with a
policy different than "none") could still work if the sender signed their
email with DKIM. Isn't it correct?

In order for DMARC to be valid, you need at least SPF OR DKIM to PASS, but
also have domain alignment between the From header and either the SPF
sending domain, or the DKIM signing domain.
When forwarding, you break SPF as you are probably not on the list of
authorized sending servers, but if the DKIM alignment and validity is there
in the beginning, the email should still pass DMARC.

The only case where email forwarding is in trouble is for senders enabling
DMARC without sending DKIM-signed emails.

Am I missing something?


Le jeu. 8 févr. 2024 à 06:38, Marco Moock via mailop  a
écrit :

> Am Wed, 07 Feb 2024 20:51:15 -0600
> schrieb Jarland Donnell via mailop :
>
> > Is it time to throw in the towel on email forwarding?
>
> I think so.
> Every mechanism has its own disadvantages.
>
> > Nearly 100% of users who forward email do so because they want it in
> > Gmail.
>
> Which type of users?
> Due to privacy, forwarding to GMail is already a nightmare.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Spamcop from a forwarding standpoint

[Cyril - ImprovMX via mailop]

Thank you Richard, I'll reach out outside of the list.

Best,
Cyril

Le jeu. 25 janv. 2024 à 17:23, Thomas Mechtersheimer via mailop <
mailop@mailop.org> a écrit :

> About 20 years ago I was able to register IP addresses of our
> designated mail forwarding servers at SpamCop (via mail to
> deput...@admin.spamcop.net), so that they would not get listed,
> and we don't receive reports for those.
> This still seems to be active today.
>
> Unfortunately I have not been able to update this registration since
> SpamCop introduced the Mailhost configuration somewhere around 2013.
> Looks like nowadays every recipient has to add the forwarding servers
> manually.
>
> --
> Thomas Mechtersheimer
> CSL Computer Service Langenbach GmbH
> Hansaallee 191-193
> 40549 Düsseldorf
> Telefon: +49 (211) 8 67 67-0
> Telefax: +49 (211) 8 67 67-10
> mailto: thomas.mechtershei...@csl.de
>
> CSL wird 50 - was Kunden sagen: https://csl.de
>
> Geschäftsführer: Renate Altmann-Spangenberg
> Amtsgericht Düsseldorf HRB 34900
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Spamcop from a forwarding standpoint

[Cyril - ImprovMX via mailop]

Thank you Andy,

I've been in touch with some users and they are generally open minded. I
think the link you shared is really helpful and it will definitely help
everyone (us, the user, spamcop), so thank you very much for that!

Best,
Cyril

Le jeu. 25 janv. 2024 à 10:52, Andy Smith via mailop  a
écrit :

> Hi,
>
> On Thu, Jan 25, 2024 at 09:58:17AM +0100, Cyril - ImprovMX via mailop
> wrote:
> > Unfortunately for us, Spamcop believe we are the one sending spam when
> they
> > trace back the Received headers, because we are the last hop before
> landing
> > to that user's inbox.
> >
> > Is there a way to tell in the headers that we are merely forwarding
> emails
> > (we do have spam protection in place, but some of them always manage to
> get
> > through) ?
>
> There's no way for you to do this, because SpamCop has no way to
> know that you are "part of" the recipient's infrastructure.
>
> SpamCop instructs its users not to ever report forwarded email if
> you like I should think you could continue marking every report as
> resolved or not applicable due to the fact that it's forwarded and
> SpamCop would side with you (I've no special knowledge on this).
>
> Something that a SpamCop user CAN do is register (with them) the
> forwarding path, and then SpamCop will know about that. Here's the
> help for that:
>
>
> https://forum.spamcop.net/forum/7-mailhost-configuration-of-your-reporting-account/
>
> That's something only the SpamCop user can do though, and if they're
> not understanding the issue and blindly hitting "report" then that
> won't help you.
>
> The exact same problem happens when people report spam that they
> received through a mailing list. The SpamCop user needs to be a bit
> careful.
>
> Thanks,
> Andy
>
> --
> https://bitfolk.com/ -- No-nonsense VPS hosting
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Spamcop from a forwarding standpoint

[Cyril - ImprovMX via mailop]

Hey everyone!

I'm running ImprovMX.com, an email forwarding service and I'd appreciate
your advice on a situation I can't find a solution for.

Some of my users are using Spamcop to notify them of spam abuse, which is
good thing to do to fight spam.
Unfortunately for us, Spamcop believe we are the one sending spam when they
trace back the Received headers, because we are the last hop before landing
to that user's inbox.

Is there a way to tell in the headers that we are merely forwarding emails
(we do have spam protection in place, but some of them always manage to get
through) ?

Or is there someone from Spamcop in this list I can discuss with about how
to find a working solution?

I thought about ARC, which would be a good solution to this, but ARC is
useless (can't trust the signing domain) so it's out of the question.

Thank you for your help!

Best regards,
Cyril
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [ADMIN] I'm going for a lie down

[Cyril - ImprovMX via mailop]

Good luck for the surgery (if it's not already done) and get well by taking
the time you need. Health is important.

I'd say we'd hold the fort but the members here are all nice folks so I'm
not worried ;)

Le ven. 8 déc. 2023, 20:03, Jay R. Ashworth via mailop 
a écrit :

> - Original Message -
> > From: "Graeme Fowler via mailop" 
> > To: "mailop" 
> > Cc: "Simon Lyall" 
> > Sent: Tuesday, December 5, 2023 1:01:01 PM
> > Subject: [mailop] [ADMIN] I'm going for a lie down
>
> > Hi folks
> >
> > Apologies for not mentioning this any earlier, but at 0700 tomorrow I’m
> > reporting to hospital to have my right hip replaced. I’m going to be
> largely
> > incommunicado for a while. Be nice to each other, behave, try the veal,
> tip
> > your waitress etc :)
> >
> > Dont’ give Simon or Patrick a hard time in terms of moderation, please.
>
> Wait; this list has moderation?
>
> :-)
>
> Best of luck; we're really good at this sort of thing these days...
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth  Baylink
> j...@baylink.com
> Designer The Things I Think   RFC
> 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land
> Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647
> 1274
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft CERT Report Response Marked As Spam

[Cyril - ImprovMX via mailop]

Looking at the failing tests, I wonder if Microsoft didn't give the task of
responding to a first year student with no supervision on how to write a
proper email.

I mean, "REPLYTO_WITHOUT_TO_CC" is really bad, and they even manage to fail
SPF! ("FORGED_SPF_HELO").
On top of that, it lacks important headers (MISSING_HEADERS) and manages to
fail the others (DATE_IN_PAST_03_06).

At this stage, it's a joke, right?

Le mer. 8 nov. 2023 à 13:57, L. Mark Stone via mailop  a
écrit :

> We filed an abuse report with Microsoft for some bad emails.
>
> Normally we don't bother, but these emails were concerning enough that we
> thought we should bring them to Microsoft's attention.  While it would be
> nice if Microsoft did a better job at filtering outbound emails, that's not
> the point of this post here.
>
> We got back a "Microsoft CERT Report  Received" email, which
> email went straight to Junk, with the following SpamAssassin tests firing:
>
> X-Spam-Status: Yes, score=5.824 required=3.8
> tests=[DATE_IN_PAST_03_06=1.076,
>  DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
> DKIM_VALID_AU=-0.1,
>  DKIM_VALID_EF=-0.1, FORGED_SPF_HELO=1, HTML_FONT_LOW_CONTRAST=0.001,
>  HTML_MESSAGE=0.001, MISSING_HEADERS=2, RCVD_IN_DNSWL_HI=0.001,
>  RCVD_IN_MSPIKE_H2=-0.001, REPLYTO_WITHOUT_TO_CC=1.946,
> SPF_HELO_PASS=-0.001,
>  SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01,
>  URI_TRUNCATED=0.001] autolearn=disabled
>
> In case anyone else is waiting for responses from Microsoft, recommend you
> check your Junk/Spam folder.
>
> Hope that helps,
> Mark
> _
> L. Mark Stone, Founder
> North America's Leading Zimbra VAR/BSP/Training Partner
> For Companies With Mission-Critical Email Needs
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] How to handle hostname and PTR mismatch?

[Cyril - ImprovMX via mailop]

Ok thank you.

In this case, does it makes sense to check the FQDN and if it doesn't have
a A record, the email should be refused? Or maybe it should only be flagged?

Le mer. 1 nov. 2023 à 16:27, Michael Peddemors via mailop 
a écrit :

> You are good..
>
> https://improvmx.com/  That has clear contact information, if anyone is
> concerned about traffic related to that domain.
>
> However operators that do this..
>
> PTR = mta033bb.pmx1.epsl1.com
>
> http://epsl1.com/
>
> "epsl1.com’s DNS address could not be found. Diagnosing the problem."
>
> I have no sympathy for.. Especially for their size.. and I believe a
> M3AAWG member? Transparency is key..
>
> On 2023-11-01 07:05, Cyril - ImprovMX via mailop wrote:
> > Thank you Michael, that's interesting, but I'm not sure about one thing:
> >
> > My sending servers all have a valid PTR that matches my services
> > (mailX.mxY.infra.improvmx.com <http://mailX.mxY.infra.improvmx.com>,
> > such as mail1.mxa.infra.improvmx.com
> > <http://mail1.mxa.infra.improvmx.com>) but if you try to open that
> > domain on a browser, you'll get nothing.
> > There is a valid A and PTR but that's all.
> >
> > So, what do you mean by having a valid URL associated?
> >
> > Thanks !
> >
> > Le sam. 28 oct. 2023 à 01:03, Michael Peddemors via mailop
> > mailto:mailop@mailop.org>> a écrit :
> >
> > IMHO there are reasons for the EHLO or HELO to use the internal
> server
> > name, which may not be associated with a public IP Address, so
> > expecting
> > the EHLO to match the PTR can and will get you into trouble.
> >
> > It is more important to make sure that the domain in the PTR record,
> > has
> > a URL associated..
> >
> > There are those that try to make sure that forward/reverse match, but
> > they often do that wrong.. (eg only one forward needs to match the
> > reverse).
> >
> > Just always make sure that your EHLO is a FQDN, not just a hostname,
> > and
> > for gods' sake not an IP literal, or 'localhost.localdomain' etc..
> >
> > Public resources need to be transparent, HELO/EHLO is an identifier,
> > and
> > often an internal identifier, rather than a public one.  Make sense?
> >
> > On 2023-10-27 06:19, Cyril - ImprovMX via mailop wrote:
> >  > Hi!
> >  >
> >  > It's been quite common to refuse a server connecting that doesn't
> > have a
> >  > proper PTR, but I was wondering if there was any recommendation
> > (either
> >  > official via RFC or standard practice) about a server connecting
> > with a
> >  > PTR that is different from the announced hostname at the
> > HELO/EHLO command.
> >  >
> >  > For instance, if my server has a PTR with mail1.example.com
> > <http://mail1.example.com>
> >  > <http://mail1.example.com <http://mail1.example.com>>, and I
> > connect by saying "HELO
> >  > send.example.com <http://send.example.com>
> > <http://send.example.com <http://send.example.com>>". If the
> > receiving server
> >  > loads all the IPs for "send.example.com <http://send.example.com>
> > <http://send.example.com <http://send.example.com>>" but
> >  > doesn't find my server's IP, should it refuse the email or accept
> > it ?
> >  >
> >  > Thank you for your help here.
> >  >
> >  > Best regards,
> >  > Cyril
> >  >
> >  > ___
> >  > mailop mailing list
> >  > mailop@mailop.org <mailto:mailop@mailop.org>
> >  > https://list.mailop.org/listinfo/mailop
> > <https://list.mailop.org/listinfo/mailop>
> >
> >
> > --
> > "Catch the Magic of Linux..."
> >
>  
> > Michael Peddemors, President/CEO LinuxMagic Inc.
> > Visit us at http://www.linuxmagic.com <http://www.linuxmagic.com>
> > @linuxmagic
> > A Wizard IT Company - For More Info http://www.wizard.ca
> > <http://www.wizard.ca>
> > "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices
> Ltd.
> >
>  
> > 604-682-0300 Beautiful Bri

Re: [mailop] How to handle hostname and PTR mismatch?

[Cyril - ImprovMX via mailop]

Thank you Michael, that's interesting, but I'm not sure about one thing:

My sending servers all have a valid PTR that matches my services (
mailX.mxY.infra.improvmx.com, such as mail1.mxa.infra.improvmx.com) but if
you try to open that domain on a browser, you'll get nothing.
There is a valid A and PTR but that's all.

So, what do you mean by having a valid URL associated?

Thanks !

Le sam. 28 oct. 2023 à 01:03, Michael Peddemors via mailop <
mailop@mailop.org> a écrit :

> IMHO there are reasons for the EHLO or HELO to use the internal server
> name, which may not be associated with a public IP Address, so expecting
> the EHLO to match the PTR can and will get you into trouble.
>
> It is more important to make sure that the domain in the PTR record, has
> a URL associated..
>
> There are those that try to make sure that forward/reverse match, but
> they often do that wrong.. (eg only one forward needs to match the
> reverse).
>
> Just always make sure that your EHLO is a FQDN, not just a hostname, and
> for gods' sake not an IP literal, or 'localhost.localdomain' etc..
>
> Public resources need to be transparent, HELO/EHLO is an identifier, and
> often an internal identifier, rather than a public one.  Make sense?
>
> On 2023-10-27 06:19, Cyril - ImprovMX via mailop wrote:
> > Hi!
> >
> > It's been quite common to refuse a server connecting that doesn't have a
> > proper PTR, but I was wondering if there was any recommendation (either
> > official via RFC or standard practice) about a server connecting with a
> > PTR that is different from the announced hostname at the HELO/EHLO
> command.
> >
> > For instance, if my server has a PTR with mail1.example.com
> > <http://mail1.example.com>, and I connect by saying "HELO
> > send.example.com <http://send.example.com>". If the receiving server
> > loads all the IPs for "send.example.com <http://send.example.com>" but
> > doesn't find my server's IP, should it refuse the email or accept it ?
> >
> > Thank you for your help here.
> >
> > Best regards,
> > Cyril
> >
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
>
>
> --
> "Catch the Magic of Linux..."
> 
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> A Wizard IT Company - For More Info http://www.wizard.ca
> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> 
> 604-682-0300 Beautiful British Columbia, Canada
>
> This email and any electronic data contained are confidential and intended
> solely for the use of the individual or entity to which they are addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and are not intended to represent those of the company.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] How to handle hostname and PTR mismatch?

[Cyril - ImprovMX via mailop]

That's interesting! I was about to block the mismatching Hostname vs PTR,
but it's helpful to see that's not the recommended way (I still block if
the sender doesn't have PTR though).

Bill Cole makes a really good point :

> It should not refuse the email *solely* for that reason.

This should weight in the decision; If the hostname doesn't match the PTR,
that the SPF fails, and so on, maybe it would be time to block the incoming
email.

Really interesting! Thank you everyone!

Le ven. 27 oct. 2023 à 16:53, Marco M. via mailop  a
écrit :

> Am 27.10.2023 um 14:00:50 Uhr schrieb ml+mailop--- via mailop:
>
> > On Fri, Oct 27, 2023, Marco M. via mailop wrote:
> > > Because the big companies enforce a correct PTR, almost all servers
> > > sending mail have a working PTR.
> >
> > But not wrt the HELO argument, right?
>
> I haven't checked that, but maybe that will also be checked and
> rejected by certain relays.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] How to handle hostname and PTR mismatch?

[Cyril - ImprovMX via mailop]

Hi!

It's been quite common to refuse a server connecting that doesn't have a
proper PTR, but I was wondering if there was any recommendation (either
official via RFC or standard practice) about a server connecting with a PTR
that is different from the announced hostname at the HELO/EHLO command.

For instance, if my server has a PTR with mail1.example.com, and I connect
by saying "HELO send.example.com". If the receiving server loads all the
IPs for "send.example.com" but doesn't find my server's IP, should it
refuse the email or accept it ?

Thank you for your help here.

Best regards,
Cyril
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF behavior on email forwarding

[Cyril - ImprovMX via mailop]

Thank you everyone for your messages, I appreciate it and it was very
interesting.

I think we'll change our behavior to not only stop at SPF failure, but
include it in the antispam processing and eventually really block when
DMARC is set to reject and fails.

We have implemented ARC as a signing mechanism at ImprovMX, so all our
messages are sent via all the ARC headers, but I will never rely on an
incoming ARC signature to trust if the SPF/DKIM/DMARC was initially correct
and isn't anymore. ARC is a vendor lock-in approach to an open protocol
(but that's a discussion for another topic)

Thanks everyone again. We'll improve our implementation soon!

Le ven. 14 avr. 2023 à 20:07, Slavko via mailop  a
écrit :

> Dňa 14. apríla 2023 17:06:57 UTC používateľ John Levine via mailop <
> mailop@mailop.org> napísal:
>
> >We also didn't anticipate how always-on connections would become fast
> >and cheap, disk space would become free, and everyone would use IMAP
> >so they can handle mail on multiple devices. Once you do that, most of
> >the motivation for forwarding goes away since you can instead deliver
> >locally and set up mail programs to check mail in multiple places.
>
> Heh, years ago i used forwarding as simple antiSPAM solution.
>
> In that time registering at some site (eg. forums) with email
> address soon or latter ended with tons of messages, mostly
> unwanted, without any real chance to stop them. Thus i had
> freemail address registered for that purpose and when count
> of bad messagess cross some threshold i simple removed
> that forwarding and registered new...
>
> As antispam solutions improved i abandon that..
>
> regards
>
>
> --
> Slavko
> https://www.slavino.sk/
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] SPF behavior on email forwarding

[Cyril - ImprovMX via mailop]

Hi!

What is the best approach when you receive an email that doesn't respect
the SPF (with a hard fail)?

I'm asking because we've been running ImprovMX for a few years now and the
decision we took was that if you send us an email with a SPF that is
failing ("-a"), we immediately refuse the email.

For me, the reason was pretty straight forward ; you set your SPF in a way
that you ask for it to fail, so it makes sense that we refuse it if ... it
fails.

But I just discovered that, among others, Google Workspace and Namecheap
breaks the SPF when they *forward* an email!

If you set up a forwarding for your email, say "supp...@domain.com" that
redirects to al...@destination.com and send an email from b...@example.com
to supp...@domain.com, the server @destination.com will see an email coming
from b...@example.com, but with the IPs of Google (or Namecheap).

Since b...@example.com hasn't put the Google (or Namecheap) IPs in their SPF
because they don't use it, their email will break SPF at @destination.com
domain.

So, since Google Workspace and Namecheap are doing this, it means that
others are certainly also doing this.

What would be the best behavior here? Should we rely on both the SPF AND
DKIM to refuse an email (compared to just the SPF), even if no DMARC are
set?
Should we allow all emails, even those who fail SPF?
Should we only block when DMARC is set and fails?

What is the best approach here?

I personally don't want to accept emails that fails SPF with no further
checks, otherwise it will be hell on the amount of emails we'll handle.

Thanks for your help here!
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Unbound configuration for DNSBL ?

[Cyril - ImprovMX via mailop]

I removed the usage of OpenDNS, and let Spamhaus know about this. I've also
enabled qname-minimisation, we'll see if that helps.

Thank you for your help!

Best,
Cyril

Le mer. 29 mars 2023 à 11:13, John Levine  a écrit :

> It appears that Cyril - ImprovMX via mailop  said:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >
> >@John thank you for your input, but I wonder ; If I leave the Unbound
> >default configuration, won't it will use my local resolv.conf file to
> >access the DNS servers? Or does Unbound uses a specific set of DNS servers
> >instead of using the ones recommended by the OS?
>
> Unbound is a DNS cache. It queries the authoritative servers for the
> zones its client ask about to get the answers which it sends along to
> its clients.
>
> resolv.conf is for application programs.  The usual setup is that it
> contains 127.0.0.1 to tell applications to query the cache server on the
> same host, which in this case is unbound.
>
> Unbound has its own configuration file but in most cases the defaults
> are all you need.
>
> R's,
> John
>
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Unbound configuration for DNSBL ?

[Cyril - ImprovMX via mailop]

@John thank you for your input, but I wonder ; If I leave the Unbound
default configuration, won't it will use my local resolv.conf file to
access the DNS servers? Or does Unbound uses a specific set of DNS servers
instead of using the ones recommended by the OS?

Le mar. 28 mars 2023 à 14:30, John Levine via mailop  a
écrit :

> It appears that Renaud Allard via mailop  said:
> >If you are using a DNS key from spamhaustech, there is no technical
> >problem in using OpenDNS. Although you should probably query the servers
> >yourself ...
>
> If you are running your own unbound, just use the default configuration
> so it queries directly.   An extra level of indirection will just slow
> things down.  OpenDNS is no closer on the network than Spamhaus so
> you won't get answers any faster and often, when it's not in their
> cache, slower.
>
> R's,
> John
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Unbound configuration for DNSBL ?

[Cyril - ImprovMX via mailop]

Thank you for the follow ups.

@Michael why the suggestion to use something else? I think it would just
move the issue elsewhere without fixing it.

@Renaud that's exactly what we are currently doing; we are working on a
partnership with Spamhaus to set up a paid account with them in order to
have full access to their data while respecting their fair usage. Our idea
here is to have a good compromise between using the paid versions of
SpamHaus while having a nice cache system in place in order to optimize our
requests, hence my email.

Using OpenDNS in between shouldn't be an issue since we use a key to query
SpamHaus that is specific to us. OpenDNS relay that query so we are
properly identified at Spamhaus and aren't doing anything trickery.
We've seen the configuration with them and they haven't raised any issues
with it.

Le lun. 27 mars 2023 à 16:25, Renaud Allard via mailop 
a écrit :

>
>
> On 3/27/23 11:17, Cyril - ImprovMX via mailop wrote:
> > Hi everyone!
> >
> > We have a few SpamAssassin servers running that test against services
> > such as SpamHaus, URIBL, etc.
> > We often have our queries blocked because we go beyond the free usage.
> >
> > As such, we started a trial with SpamHaus, and the result is that we
> > query around 8M times per day.
> >
> > Our current infrastructure is a set of SA servers that use our (local
> > network) DNS server - Unbound, to optimize the queries (caching and the
> > like).
> >
> > I'm not an expert on Unbound and would love your input on how we can
> > fine-tune it to work better on caching the requests made to SpamHaus and
> > reducing the number of queries we are doing.
> >
> > Right now, here's our Unbound.conf file:
> > https://pastebin.com/PZWUn4My <https://pastebin.com/PZWUn4My>
> >
> > Just in case, here's our current SA file:
> > https://pastebin.com/E2y1Yqm8 <https://pastebin.com/E2y1Yqm8>
> >
> > If any of you have any suggestions on how we can optimize these
> > configurations, I'd love to have your feedback!
> >
> Making DNSBL queries through open DNS servers is forbidden/discouraged
> by most of the DNSBL providers. Obviously, you are not alone doing it,
> so those servers are making a lot of queries and get rate limited/banned.
>
> Setting your cache-min-ttl higher than what is told by the DNS servers
> might improve your caching, but might also cause false positives if the
> IP has been removed from the list. And setting a cache-max-ttl isn't
> going to improve anything, all the contrary.
>
> Please also be aware that many DNSBL providers have subscriptions for
> commercial senders like you, and that's probably the way to go. If you
> cannot afford paying for them, maybe your pricing model is wrong.
>
> There are obvious ways to bypass rate limiting (although it probably
> doesn't scale that well), but I am not going to divulge that as this is
> the best way to get many free lists non free anymore.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Unbound configuration for DNSBL ?

[Cyril - ImprovMX via mailop]

Hi everyone!

We have a few SpamAssassin servers running that test against services such
as SpamHaus, URIBL, etc.
We often have our queries blocked because we go beyond the free usage.

As such, we started a trial with SpamHaus, and the result is that we query
around 8M times per day.

Our current infrastructure is a set of SA servers that use our (local
network) DNS server - Unbound, to optimize the queries (caching and the
like).

I'm not an expert on Unbound and would love your input on how we can
fine-tune it to work better on caching the requests made to SpamHaus and
reducing the number of queries we are doing.

Right now, here's our Unbound.conf file:
https://pastebin.com/PZWUn4My

Just in case, here's our current SA file:
https://pastebin.com/E2y1Yqm8

If any of you have any suggestions on how we can optimize these
configurations, I'd love to have your feedback!

Thank you !
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Valid SPF/DKIM/DMARC *SPAM* coming from my domain ?!

[Cyril - ImprovMX via mailop]

I'm following up on this old thread. I've realized that Mailgun's approach
could be more secure when accepting an email (legit or not).
I tried to reach out to the security team but never had a response, so I
consider this is not considered seriously by them.

If you send an email hosted by Mailgun and that is redirected, Mailgun will
add a DKIM header of the managed domain.
The problem is that if I send an email setting the "From" as the email
managed by Mailgun, the email will then have a valid DKIM signature, so
DMARC won't fail.

This allows me to send an email such as "c...@company.com" to "
emplo...@company.com" with the subject "You are fired.", the email will
look legit and cause serious troubles inside the company.
Starting from this, any social engineering attack can be implemented with
an email that will validate SPF/DKIM/DMARC.

Since then, I moved my domain elsewhere.

Le jeu. 12 janv. 2023 à 15:53, Nick Schafer via mailop 
a écrit :

> Hi all, I just wanted to chime in here. I can confirm that this was a
> message sent to an email address @reflectiv.net which is hosted on
> Mailgun. We provide a routing feature that allows you to match received
> messages and then forward the email to another email address or
> application. We do also provide an inbound spam filter and I see that it
> isn't enabled for this domain. With inbound spam filtering enabled it may
> help prevent messages like this one from being forwarded.
>
> Thanks,
>
> *Nick Schafer* | Sr. Manager of Deliverability & Compliance
> n...@mailgun.com
> This message and all attachments are for the exclusive use of the
> recipients and are confidential. If you receive this message in error,
> please destroy it and notify the sender immediately.
> [image: mailgun] <https://www.mailgun.com/> [image: mailjet]
> <https://www.mailjet.com/> [image: email on acid]
> <https://www.emailonacid.com/>
>
>
> --
> *From:* mailop  on behalf of Michael Peddemors
> via mailop 
> *Sent:* Wednesday, January 11, 2023 7:37 PM
> *To:* mailop@mailop.org 
> *Subject:* Re: [mailop] Valid SPF/DKIM/DMARC *SPAM* coming from my domain
> ?!
>
> host reflectiv.net
> reflectiv.net has address 75.2.60.5
> reflectiv.net mail is handled by 10 mxb.mailgun.org.
> reflectiv.net mail is handled by 10 mxa.mailgun.org.
>
> Ummm
>
> Now, it is pretty obvious that this is sent via MailGun, which of course
> needs to improve it's outbound filters, seeing way too much phishing
> coming from them lately.. (copying SendGrid?)
>
> Received: from reflectiv.net (os3-384-25366.vs.sakura.ne.jp
> [133.167.109.120]) by db739d28cce8 with SMTP id ; Wed, 11 Jan
> 2023 00:26:59 GMT
>
> (Note: It doesn't say it was ESMTP or anything about authenticated user
> in this case, any script can forge the EHLO)
>
> Okay, the only valid thing is probably the source that logged in is
> using a launching point in Japan..
>
> Implement 2FA on your mailgun account..
>
> However, this is why hackers like using those services.. if a domain has
> mailgun/sendgrid in their SPF, it is like a get out of jail free card.
>
> While not everyone can afford a dedicated IP on those services, it can
> make it simpler to protect.
>
>
>
> On 2023-01-11 13:00, Cyril - ImprovMX via mailop wrote:
> > Hi everyone!
> >
> > Today, I received a spam ("I got full access to your computer and
> > installed a trojan" kind of email). In general, I completely ignore
> > these, but today was different:
> >
> > The sender and recipient were my own email! What's odd is that I did
> > configure SPF (granted, with a "~") but also a DMARC reject policy.
> >
> > Looking at the email headers and also the output from GMail, both SPF
> > and DKIM were successful ("pass"), which means the sender, somehow, was
> > able to send an email using my account.
> >
> > I would love your input on the issue, but here are my thoughts so far:
> >
> > 1. My account was compromised, and the password was leaked, allowing
> > that user to send an email with my account. This would make sense, but
> > the sending account was only used to be configured within GMail. As soon
> > as the password was generated, I pasted it on GMail and never saved it
> > elsewhere.
> > 2. Theoretically, if I were to create an account on Mailgun, I would be
> > able to send an email from my account and have a valid SPF for any other
> > services that use Mailgun too (since their SPF would include Mailgun's
> > IPs), but it wouldn't explain the valid DKIM though. For this, Mailgun
> > should only allow my accou

Re: [mailop] Valid SPF/DKIM/DMARC *SPAM* coming from my domain ?!

[Cyril - ImprovMX via mailop]

@Bill I was able to reproduce the original email I received without needing
my credentials. They weren't compromised.

Le mer. 11 janv. 2023, 23:20, Bill Cole via mailop  a
écrit :

> On 2023-01-11 at 16:29:51 UTC-0500 (Wed, 11 Jan 2023 22:29:51 +0100)
> Peter N. M. Hansteen via mailop 
> is rumored to have said:
>
> > Generating a new, strong (long) password likely won't hurt, but it may
> > not
> > have been necessary. It is more likely that the miscreants injected
> > the
> > message somewhere that does not lend much weight to things like SPF,
> > but
>
> Nope. The Google-generated authentication headers confirm that it came
> from Mailgun and had a valid signature from the domain reflectiv.net,
> which matches the domain in the Return Path and both To and From
> headers. Everything above the DKIM-Signature header is (normal)
> Google-generated authentication and trace information.
>
> The OP's SPF record includes Mailgun's SPF. Their Mailgun credentials
> were compromised.
>
>
> --
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Valid SPF/DKIM/DMARC *SPAM* coming from my domain ?!

[Cyril - ImprovMX via mailop]

Thank you everyone for your follow up.

Your suggestion, Jarland, is very interesting. I also find it odd to have
the sakura.ne.jp server appear out of nowhere!
If it were to be a hack of my account, it would be Mailgun->Gmail, that's
all. (well, I hope so)

... and, you put me on the right track!
I found the reason, but I think I need to contact Mailgun first as it seems
to be a very bad security issue...

I'll keep you posted, but I know how they did it.

I'll definitely keep you posted as soon as I have news from Mailgun.


Le mer. 11 janv. 2023 à 22:52, Mark Alley via mailop  a
écrit :

> Looking at it again, I agree with Todd and Jarland's hypothesis;
> Forwarding sounds more plausible than an API submission via compromised
> credentials in this case. I think that hit the nail on the head. This also
> correlates to one of Mailgun's product offerings
> <https://www.mailgun.com/blog/product/intelligent-email-forwarding-with-mailgun/>
> for forwarding which fits the bill.
> On 1/11/2023 3:29 PM, Todd Herr via mailop wrote:
>
> This looks like a message that maybe might've been sent to a reflectiv.net
> address (perhaps the one advertised on your website? contact at
> reflectiv.net?) and then automatically forwarded by Mailgun (which hosts
> inbound mail for reflectiv.net) to a Google account (since Mailgun
> probably doesn't do mailbox hosting).
>
> That's just purely a guess, based on
>
>
>1. X-Mailgun-Incoming: Yes
>
> appearing in the headers, and the MX record for reflectiv.net, and the
> message coming to Google with the following Return-Path:
>
>1. Return-Path: gmail@reflectiv.net>
>
> Does that sound plausible?
>
> On Wed, Jan 11, 2023 at 4:07 PM Cyril - ImprovMX via mailop <
> mailop@mailop.org> wrote:
>
>> Hi everyone!
>>
>> Today, I received a spam ("I got full access to your computer and
>> installed a trojan" kind of email). In general, I completely ignore these,
>> but today was different:
>>
>> The sender and recipient were my own email! What's odd is that I did
>> configure SPF (granted, with a "~") but also a DMARC reject policy.
>>
>> Looking at the email headers and also the output from GMail, both SPF and
>> DKIM were successful ("pass"), which means the sender, somehow, was able to
>> send an email using my account.
>>
>> I would love your input on the issue, but here are my thoughts so far:
>>
>> 1. My account was compromised, and the password was leaked, allowing that
>> user to send an email with my account. This would make sense, but the
>> sending account was only used to be configured within GMail. As soon as the
>> password was generated, I pasted it on GMail and never saved it elsewhere.
>> 2. Theoretically, if I were to create an account on Mailgun, I would be
>> able to send an email from my account and have a valid SPF for any other
>> services that use Mailgun too (since their SPF would include Mailgun's
>> IPs), but it wouldn't explain the valid DKIM though. For this, Mailgun
>> should only allow my account to be able to send using my domain.
>> 3. Did Mailgun have any database leak that I wasn't aware of?
>>
>> Of course, as soon as I saw this email, I generated a new password for my
>> account, but I still wonder how this could have happened. I would
>> appreciate if you had any insights I've missed that would make sense.
>>
>> Here are the headers from the email with my end email redacted:
>> https://pastebin.com/knqbTa8K
>>
>> Thank you!
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://list.mailop.org/listinfo/mailop
>>
>
>
> --
> *Todd Herr * | Technical Director, Standards and Ecosystem
> *e:* todd.h...@valimail.com
> *m:* 703.220.4153
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
>
> ___
> mailop mailing listmailop@mailop.orghttps://list.mailop.org/listinfo/mailop
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Valid SPF/DKIM/DMARC *SPAM* coming from my domain ?!

[Cyril - ImprovMX via mailop]

Hi everyone!

Today, I received a spam ("I got full access to your computer and installed
a trojan" kind of email). In general, I completely ignore these, but today
was different:

The sender and recipient were my own email! What's odd is that I did
configure SPF (granted, with a "~") but also a DMARC reject policy.

Looking at the email headers and also the output from GMail, both SPF and
DKIM were successful ("pass"), which means the sender, somehow, was able to
send an email using my account.

I would love your input on the issue, but here are my thoughts so far:

1. My account was compromised, and the password was leaked, allowing that
user to send an email with my account. This would make sense, but the
sending account was only used to be configured within GMail. As soon as the
password was generated, I pasted it on GMail and never saved it elsewhere.
2. Theoretically, if I were to create an account on Mailgun, I would be
able to send an email from my account and have a valid SPF for any other
services that use Mailgun too (since their SPF would include Mailgun's
IPs), but it wouldn't explain the valid DKIM though. For this, Mailgun
should only allow my account to be able to send using my domain.
3. Did Mailgun have any database leak that I wasn't aware of?

Of course, as soon as I saw this email, I generated a new password for my
account, but I still wonder how this could have happened. I would
appreciate if you had any insights I've missed that would make sense.

Here are the headers from the email with my end email redacted:
https://pastebin.com/knqbTa8K

Thank you!
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] I received a scam letter from Paypal

[Cyril - ImprovMX via mailop]

I think that Paypal is already aware of this, looking at all the
discussions and all the Google results there is.
I'm mostly surprised they aren't dining anything proactively.

Le jeu. 29 déc. 2022 à 02:00, Jarland Donnell via mailop 
a écrit :

> For someone already using billing automation it works that way, but
> think more in terms of a web designer with 5 clients, billing a client
> for a quick job. PayPal has a lot of functions for a lot of different
> use cases that could range from helping freelancers to large businesses.
>
> I'm not sure how much needs to be done after registration to gain the
> feature but I imagine if you have a working login, you have the feature.
>
> On 2022-12-28 12:55, Jaroslaw Rafa via mailop wrote:
> > Dnia 28.12.2022 o godz. 12:33:05 Jarland Donnell via mailop pisze:
> >> It's a perfectly legitimate feature of PayPal that you can create an
> >> invoice and send it to someone. Pretty much every invoice service
> >> that exists allows similar. They just have a problem with malicious
> >> users creating invoices for people that don't owe them any money.
> >
> > I understand they need to already be Paypal customers and be somehow
> > verified and "allowed" by Paypal to create invoices for other users?
> >
> > Is this some additional feature of Paypal? Paypal's basic operation,
> > ie.
> > being a payment processor, does not require such feature at all. In
> > normal
> > payment processing flow in an Internet shop you don't get any invoice
> > until
> > you have paid for the goods you are ordering, and this invoice is sent
> > to
> > you directly by the shop, and not via the payment processing service.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] I received a scam letter from Paypal

[Cyril - ImprovMX via mailop]

Hi everyone!

If I recall correctly, there was already a discussion here on something
similar, but I'd like to share my story here.

Yesterday, I received an email from Paypal with the subject "Reminder - You
have paid an invoice".

The content of the email is the following:

[image: first.png]

There are a few things to note that are surprising :

   - The email is really coming from Paypal (serv...@paypal.com)
   - The SPF/DKIM AND DMARC are valid
   - All the links inside the email point to Paypal.com, even though I
   haven't clicked on the "View ad Pay Invoice"
   - The sending IP (66.211.170.90) is from Paypal: mx4.phx.paypal.com (
   https://check.mx/ptr/66.211.170.90)


And a few inconsistencies :

   - The subject says, "You have paid an invoice", but the body says,
   "Please pay your invoice"
   - The bottom indicates that Paypal "will always contain your full name",
   but the top indicates "Hello, PayPal Customer"
   - I haven't tried the phone number but pretty sure that's where the
   scammers are sitting.

Here's the validation from GMail:

[image: second.png]

What I'm saying here, is what the hell? How a scam can come from Paypal
like this?
This is a serious issue, and they need to fix this because I'm not sure my
parents would catch the scam here, all seems legit!

Stay safe, and happy holidays!

Best,
Cyril
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Re: Contact at Outlook?

[Cyril - ImprovMX via mailop]

Thank you for your help, Atro, and Michael, and sorry I took so long to get
back to you, I had some personal things I had to handle.
I appreciate you jumping on it and helping me figure out a way to reach out
to someone at Microsoft. I understand that, looking at the message from
Michael, the team handling emails is soo big it might be impossible to have
someone to help us on this, but it was worth the try :)

Thank you both, and have a nice weekend!

Best regards,
Cyril

Le jeu. 24 nov. 2022 à 01:19, Michael Wise via mailop  a
écrit :

>
>
> ... From time to time.
>
>
>
> If it can't be handled with the IP delisting form, it's going to be very
> difficult for an external party to get a hold of someone in an org that
> handles billions of emails a day. And I'm not someone who can do anything
> about such issues as a general rule.
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise*
> Microsoft Corporation| Spam Analysis
>
> "Your Spam Specimen Has Been Processed."
>
> Open a ticket for Hotmail 
> ?
>
>
>
> -Original Message-
> From: mailop  On Behalf Of Atro Tossavainen
> via mailop
> Sent: Wednesday, November 23, 2022 2:26 PM
> To: mailop@mailop.org
> Subject: [EXTERNAL] Re: [mailop] Contact at Outlook?
>
>
>
> On Wed, Nov 23, 2022 at 04:01:30PM -0600, Jarland Donnell via mailop wrote:
>
> > Assuming that doesn't pan out, can you file an abuse complaint with
>
> > their DNS provider? Sure can't hurt anything.
>
>
>
> Oddly enough Microsoft's DNS provider is... Microsoft.
>
>
>
> Microsoft has an employee participating on this list.
>
>
>
> --
>
> Atro Tossavainen, Founder, Partner
>
> Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
>
> Tallinn, Estonia
>
> tel. +372-5883-4269,
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.koliloks.eu%2F=05%7C01%7Cmichael.wise%40microsoft.com%7Ce442a6128d304d9ca76608dacda21d77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638048393561432126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=NavAOkbpSq%2Bqcep76wupKJ7Gtuyqd6yy%2FSaXvZ83KLU%3D=0
>
> ___
>
> mailop mailing list
>
> mailop@mailop.org
>
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist.mailop.org%2Flistinfo%2Fmailop=05%7C01%7Cmichael.wise%40microsoft.com%7Ce442a6128d304d9ca76608dacda21d77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638048393561432126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=XfwF75usbYTbV76pWopiM6jXxuPaGiw2KNxp3zm5NNA%3D=0
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Massive bounce report campaign

[Cyril - ImprovMX via mailop]

Thank you, Dan and Hans, for your feedback.

The reason we decided to accept the email silently was to avoid retries
that would pile up on top of the massive flux of new ones incoming. I was
aware this would add overhead to our servers. Still, I configured the code
only to accept the data and drop them, not calling the database or any
resource-intensive systems we generally use.

The situation was hard, but it finally was solved; The user in question had
the great idea to ask all their client to point to a CNAME they manage for
the MX, which was then redirected to our services. So once we were in
contact with them, they moved that CNAME point to something else, resolving
the issue in a matter of a few hours (the time it took for the slowest
services to process the DNS cache propagation).

Clearly, this situation showed us that a badly intentioned person (which
wasn't the case here) could do wreckage on our service with us being unable
to avoid this (again, we were not sending emails, only receiving bounces.
This is definitely in the DDoS area).

Fortunately, we were able to increase the number of servers with AWS EC2,
so our other users weren't severely impacted, but this feels like it's just
a ticking time bomb.

This matter is now resolved, and I'm really glad it is!

Thank you, everyone, for your support!

Best regards,
Cyril

Le mer. 30 nov. 2022 à 08:52, Dan Malm via mailop  a
écrit :

> On 2022-11-23 10:39, Cyril - ImprovMX via mailop wrote:
> > Blocking the recipient had the effect that we don't accept emails for
> > them anymore, so anyone sending an email via ImprovMX to one of their
> > domain will have a 5xx response on the RCPT command.
> > That was our initial strategy, the default when we block an account: we
> > let the sender know the email wasn't accepted.
> >
> > But in this case, I realized one thing: It's possible that the sender
> > could retry, increasing the number of connections at every new bounce.
> > So I've updated the policy on this specific account to accept but
> > silently drop any emails for them.
>
> Silently dropping the mails seems like a bad strategy to me. That would
> mean you accept DATA and waste your bandwidth and processing power on
> those. If there was no reaction on you returning a 5XX then my strategy
> would be to return a 4XX. If the 70K connections per minute actually
> translates to 70K unique emails per minute then a defer queue rising by
> 70K per minute should be at a scale that I expect gets noticed even by
> Microsoft.
>
> --
> BR/Mvh. Dan Malm, Systems Engineer, One.com
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Massive bounce report campaign

[Cyril - ImprovMX via mailop]

I'd love to be able to drop them, but the situation is made in a way that
we can not do anything:
That user configured their bounce domain to pass through us, but we didn't
send their bouncing email in the first place. they use another service for
that.

As long as they point their bounce domain to us, we will receive this
amount of emails back.
The only things possible to stop this is either to block this user from
sending any more emails (we aren't the senders, so we don't have any
leverage here) or to change the MX of their domain to something else (and
we don't own their domain).

That's why we are desperately trying to find a solution. In the meantime,
we are in discussion - with the service that this user is using to send
emails - to see with them how we can mitigate this, hopefully make this
client stop using our MX.

Since it's impossible to just stop that flux of incoming connections, I was
hoping you had some other ideas to avoid this, hence my original email.

Thank you for your message and your help :)

Le mer. 23 nov. 2022 à 13:31, Peter N. M. Hansteen  a
écrit :

>
>
> On 11/23/22 10:39, Cyril - ImprovMX via mailop wrote:
>
> > I forgot to mention this, but indeed, the first thing we did was contact
> > them. We had no response, so we blocked them and later realized that the
> > email contact we had was a black hole on their end, so we reached out
> > using another email we found and got a response. They are looking into
> > it, but I still wonder how we can have what is now 70k connections per
> > minute solely from Outlook.
>
> I think you have just described a textbook example of a customer that
> needs to be dropped, urgently.
>
> Your initial description was vague enough that it was almost possible
> that they were just clueless, but their giving you bad contact info
> rules that out. They are *bad actors*, and should be treated accordingly.
>
> If you can extract compensation for the damage they have done, that
> would be a good thing.
>
> If you keep them on as customers, your own reputation will suffer and
> you will likely lose business over this matter.
>
> Please, do the right thing. LART them to the maximum extent possible if
> you can, but stop providing any kind of service to them.
>
> All the best,
> Peter
>
> --
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Contact at Outlook?

[Cyril - ImprovMX via mailop]

That's a good idea ! I will do that !

Thank you !

Le mer. 23 nov. 2022, 23:10, Jarland Donnell via mailop 
a écrit :

> Assuming that doesn't pan out, can you file an abuse complaint with
> their DNS provider? Sure can't hurt anything.
>
> On 2022-11-23 13:12, Cyril - ImprovMX via mailop wrote:
> > Hi everyone ,
> >
> > I'm hoping that someone will be able to put me in contact with someone
> > working at Outlook.
> >
> > We are still having a really bad issues regarding our previous
> > discussion on having a lot of bounces and I'm hoping to have some help
> > from someone ar Outlook.
> >
> > Thank you !
> >
> > Best,
> > Cyril
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Contact at Outlook?

[Cyril - ImprovMX via mailop]

Hi everyone ,

I'm hoping that someone will be able to put me in contact with someone
working at Outlook.

We are still having a really bad issues regarding our previous discussion
on having a lot of bounces and I'm hoping to have some help from someone ar
Outlook.

Thank you !

Best,
Cyril
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Massive bounce report campaign

[Cyril - ImprovMX via mailop]

Thank you, everyone, for your response. My timezone differs from yours, so
I'm only replying now.

I forgot to mention this, but indeed, the first thing we did was contact
them. We had no response, so we blocked them and later realized that the
email contact we had was a black hole on their end, so we reached out using
another email we found and got a response. They are looking into it, but I
still wonder how we can have what is now 70k connections per minute solely
from Outlook.

Blocking the recipient had the effect that we don't accept emails for them
anymore, so anyone sending an email via ImprovMX to one of their domain
will have a 5xx response on the RCPT command.
That was our initial strategy, the default when we block an account: we let
the sender know the email wasn't accepted.

But in this case, I realized one thing: It's possible that the sender could
retry, increasing the number of connections at every new bounce. So I've
updated the policy on this specific account to accept but silently drop any
emails for them.

I was also able to get a hold of a few emails we received. The bounce
reports don't contain the original body, but the errors I got are mostly
"access denied AS(201806281)" with a few "address not found".

I suspect the original sender, using the mail provider, is sending a
massive campaign using a very bad list of recipients that got the mail
provider flagged and got their email rejected.

I was hoping there was an easy fix we could implement on our end that would
tell Outlook to stop connecting, but I'm pretty sure someone here would
have shared it if that was the case.

We now need to hope that they'll be helpful in resolving the issue.

Thank you all again for your message and help, and if you have any
suggestions we can implement or do better, I'm all ears!

Best regards,
Cyril

Le mar. 22 nov. 2022 à 19:08, Jarland Donnell via mailop 
a écrit :

> I would block the recipient domains at the MTA level and cut out the IP
> rate limiting for a while. An MTA should be able to handle the rejection
> for the domain fine. I do the same with exim when a user tries to give
> me the job of mass forwarding bounces, I just won't do it. In my mind a
> flood of bounces means bad behavior and I justiy the block by refusal to
> participate in whatever it is they're doing.
>
> I don't think you're crazy here at all, if half of your job suddenly
> becomes forwarding bounce emails that's just not a good look.
>
> On 2022-11-22 04:54, Cyril - ImprovMX via mailop wrote:
> > Hi!
> >
> > I would appreciate your help on a bad issue we are having.
> >
> > We are facing a very large amount of connections from Outlook, in the
> > order of 50k connections per minute (whereas the second "most active"
> > server is at 100).
> >
> > Upon investigation, we discovered that one of our users is a
> > mass-sending email service (such as Mailgun; it seems legit in
> > itself), and they created one domain per client to handle bounce
> > reports, such as sp-bounce.{client's domain}.
> >
> > Since the MX of these domains points to our server, any bounce report
> > sent is sent to our server. (Our service is a forwarding email, so
> > once we get the email, we forward it to the above user). (I'll add a
> > comment on this right after)
> >
> > The problem is that I don't see how we can stop Outlook from sending
> > all these bounce reports to us. I thought about updating the SPF to
> > block that sender from including us, but we don't manage their DNS.
> >
> > Right now, what we've done is to stop accepting connections from a
> > sender (in this case, Outlook) after an abnormal amount of connections
> > per a given period, but this doesn't avoid the fact that Outlook still
> > tries to connect to us massively, and also impact our regular users
> > that receive emails from Outlook sender legitimately.
> >
> > What I'm hoping by reaching out to you is to hope someone has already
> > faced something similar and has some suggestions on how to mitigate -
> > or ideally block - this.
> >
> > This could be a pretty well DDoS attack done by mail servers.
> >
> > On the comment above regarding the bounce report being sent: That is
> > my suspicion, by looking at the domain names (sp-bounce), the email it
> > receives, and the sender activity. But maybe there is another logical
> > explanation I'm missing!
> > I mean, to have 50k connections per minute to deliver bounce reports
> > means that the running campaign must be in the order of millions of
> > emails just for Outlook!
> >
> > All help is deeply appreciated!!!
> >
> > Thank you all in advance.
> >
> > Best regards,
> > Cyril
&

[mailop] Massive bounce report campaign

[Cyril - ImprovMX via mailop]

Hi!

I would appreciate your help on a bad issue we are having.

We are facing a very large amount of connections from Outlook, in the order
of 50k connections per minute (whereas the second "most active" server is
at 100).

Upon investigation, we discovered that one of our users is a mass-sending
email service (such as Mailgun; it seems legit in itself), and they created
one domain per client to handle bounce reports, such as sp-bounce.{client's
domain}.

Since the MX of these domains points to our server, any bounce report sent
is sent to our server. (Our service is a forwarding email, so once we get
the email, we forward it to the above user). (I'll add a comment on this
right after)

The problem is that I don't see how we can stop Outlook from sending all
these bounce reports to us. I thought about updating the SPF to block that
sender from including us, but we don't manage their DNS.

Right now, what we've done is to stop accepting connections from a sender
(in this case, Outlook) after an abnormal amount of connections per a given
period, but this doesn't avoid the fact that Outlook still tries to connect
to us massively, and also impact our regular users that receive emails from
Outlook sender legitimately.

What I'm hoping by reaching out to you is to hope someone has already faced
something similar and has some suggestions on how to mitigate - or ideally
block - this.

This could be a pretty well DDoS attack done by mail servers.

On the comment above regarding the bounce report being sent: That is my
suspicion, by looking at the domain names (sp-bounce), the email it
receives, and the sender activity. But maybe there is another logical
explanation I'm missing!
I mean, to have 50k connections per minute to deliver bounce reports means
that the running campaign must be in the order of millions of emails just
for Outlook!

All help is deeply appreciated!!!

Thank you all in advance.

Best regards,
Cyril
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Reject vs spam folders

[Cyril - ImprovMX via mailop]

> Speaking as a spammer, allow me to offer my deepest thanks for your help
> at tuning my techniques to evade your filters.

The other options are :

   - Refusing the email (which is the same to you as you'll know it's
   because it's spam)
   - Accept the email and put it in the Spam folder, blackholing the email


There is clearly no solution to this problem. Either solution brings its
set of problems.
Maybe spam folder is the best solution there is.

Le jeu. 15 sept. 2022 à 23:43, John Levine  a écrit :

> It appears that Cyril - ImprovMX via mailop  said:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >
> >So basically, what would be interesting to have is both : land the email
> in
> >the spam folder but notify the sender about if, maybe via an ARF report ?
>
> Speaking as a spammer, allow me to offer my deepest thanks for your help
> at tuning my techniques to evade your filters.
>
> R's,
> John
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Reject vs spam folders

[Cyril - ImprovMX via mailop]

So basically, what would be interesting to have is both : land the email in
the spam folder but notify the sender about if, maybe via an ARF report ?
That way, the event organizer or the one applying for a job would be able
to notify the recipient about the email being in spam.

Le jeu. 15 sept. 2022 à 22:33, Jaroslaw Rafa via mailop 
a écrit :

> Dnia 15.09.2022 o godz. 11:32:41 Jay Hennigan via mailop pisze:
> >
> > If recipients at least periodically scan the contents of the spam folder
> and
> > mark wanted mail, this avoids the need for the sender to communicate
> > out-of-band to deliver the original (and likely future) messages as
> would be
> > the case with a rejection.
>
> I understand that was the whole assumption behind the concept of spam
> folders. If it actually worked this way, spam folders wouldn't be any
> issue.
> But this assumption failed: the reality is that 99% of users don't check
> their spam folders at all, so directing a message to spam folder
> effectively
> equals blackholing. The sender needs to communicate out-of-band anyway to
> ask the recipient to check their spam folder.
>
> Spam folder can work if the user is setting it up him/herself. That is, the
> provider's antispam system only tags the message as spam (in subject or
> another header) and the user must manually set up a filter to move tagged
> messages into spam folder. Because they set it up themselves, chances are
> they will look into it from time to time. If this is something that is
> preconfigured for them by the provider, they usually don't look anywhere
> else
> except the main inbox.
>
> Of course, training the filter by moving the messages in and out of spam
> folder will be harder to implement by the provider in this setup, but it is
> still possible to do.
> --
> Regards,
>Jaroslaw Rafa
>r...@rafa.eu.org
> --
> "In a million years, when kids go to school, they're gonna know: once there
> was a Hushpuppy, and she lived with her daddy in the Bathtub."
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Reject vs spam folders

[Cyril - ImprovMX via mailop]

>
> I can second this


It's really interesting to (try) to follow all the discussions about spam
folder and in general if the oligopoly have truly won or not.

In this case, I'm bringing my grain of salt regarding the utility of the
spam folders. I believe they have a real purpose.
The issue here is in naming more than anything else. What annoys most the
people here is the term, "spam";

Gmail, by default, offers a few tabs acting has folders: "Primary",
"Social", "Promotions", ...
The spam folder is no more than another folder, except it's placed
elsewhere.

On top of that, the idea of having a spam folder is to remove the noise in
your inbox by providing a "best guess" at what is spam.
But since it is automated and can not be guaranteed to be 100% spam, the
availability of the spam folder let the end user decide if the spam is
indeed spam, or not.

I believe that having a spam folder is useful to avoid having to first
filter all my emails by removing the junk ones first, before reading the
important one.
If I'm missing an email, I can simply check the Spam folder, which will be
faster (and less tedious) than reaching out to the sender for him to send
another copy (hoping it wasn't an automated email, otherwise I'm good to
wait on the support team to respond in a few hours at best ...)

As long as checking emails for spam will be automated, with a possibility
for false positives, the spam folder will remain the best solution from an
end-user point of view.



Le jeu. 15 sept. 2022 à 15:26, Gellner, Oliver via mailop 
a écrit :

> Hello,
>
> > Am 14.09.2022 um 16:55 schrieb Thomas Walter via mailop <
> mailop@mailop.org>:
> > 
> > First of all: I am fed up with telling people to look for missing emails
> in their spamfolders.
> >
> > If I have to check a spamfolder for false positives every day, I can
> just have them delivered to my inbox. The spamfolder does not have an
> advantage then.
> >
> > Your user's opinion on that will change as soon as someone missed a bid
> or contract, because it hid in the spam folder :).
>
> I can second this, at least for personal emails. In my experience
> automatically redirecting all suspected emails to a spam folder comes close
> to the frowned upon blackholing of emails: The email is successfully
> accepted but not delivered to any inbox and not read or even noticed by
> anyone. For the users I work with, the vast majority does not check their
> spam folder, either due to lack of knowledge or because they don’t feel
> like wading through a list with 99% spam content. Therefore if the false
> positive rate of the spam filter is not zero, emails are lost.
>
> On the other hand if emails categorized as spam are rejected, the sender
> gets notified - similar to an out of office notification and at least has
> the chance to act on it. While users do not understand the non delivery
> reports, let alone are able to fix them, most of them realize that
> something did not work as expected when a lenghty error notification shows
> up in their mailbox after pressing the send button.
>
> For transactional emails it is a different story, because most systems
> sending out automated emails seem to live in a phantasy world and do not
> handle the case that emails are undeliverable. If such emails are rejected,
> the sending party often simply ignores the error and nothing ever happens.
>
> —
> BR Oliver
>
> 
>
> dmTECH GmbH
> Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
> Telefon 0721 5592-2500 Telefax 0721 5592-2777
> dmt...@dm.de * www.dmTECH.de
> GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
> Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
> 
> Datenschutzrechtliche Informationen
> Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser
> ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in
> Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder
> sich bei uns bewerben, verarbeiten wir personenbezogene Daten.
> Informationen unter anderem zu den konkreten Datenverarbeitungen,
> Löschfristen, Ihren Rechten sowie die Kontaktdaten unserer
> Datenschutzbeauftragten finden Sie hier<
> https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832
> >.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Odd DNS-cache avoidance queries (Spam Assassin / Unbound / AWS)

[Cyril - ImprovMX via mailop]

Nice! Good catch about the dns-0x20 implementation! I must have copy/pasted
some properties without looking much into it.

Is there a way to avoid unbound to fetch the root tld ? (just "com") ?

Thank you very much for your help!

Le mar. 13 sept. 2022 à 08:36, Bernardo Reino via mailop 
a écrit :

> On 13/09/2022 07:55, Cyril - ImprovMX via mailop wrote:
> > Hi everyone!
> >
>  > [...]
>  >
> > Here's the Unbound configuration: https://pastebin.com/Bn7B3uCv
> (expires in
> > a month).
> >
>  > [...]
>  >
> > 1. The first issue is that it seems that we are querying URIBL using
> random
> > lower/upper case domains. We had queries such as:
> >
> > - SoMeDoMaIn.cOM._custom_id.dF.URIbl.cOM
> > - AnOtHeRDoM.ApP._custom_id.dF.UrIbL.COM
> > - etc
>
> You have set the use-caps-for-id option in unbound:
> "Use 0x20-encoded random bits in the  query  to  foil  spoof  attempts.
> This  perturbs  the  lowercase  and uppercase of query names sent to
> authority servers and checks if  the  reply  still has  the  correct
> casing.  Disabled by default.  This feature is an experimental
> implementation of draft dns-0x20."
>
> > 2. The other issue is even weirder. SA is trying to validate the domains
> by
> > trimming the left part up to the gTLDs :
> >
> >
> > - some.domain.com._custom_id.df.uribl.com
> > - domain.com._custom_id.df.uribl.com
> > - com._custom_id.df.uribl.com <-- wtf?
> >
> > Somehow, something is trying to check up to the top TLD, where it's
> > useless. Again, I can't understand why SA would do that.
>
> This is probably unbound doing what it does, recursive resolving (from
> TLD all the way down).
>
> Hope that helps,
>
> --
> Bernardo Reino
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Odd DNS-cache avoidance queries (Spam Assassin / Unbound / AWS)

[Cyril - ImprovMX via mailop]

Hi everyone!

We are running a mail forwarding service (https://improvmx.com) and I've
recently partnered with URIBL in order to improve our quality of spam
detection. After a few weeks of trial to estimate our usage, the team at
URIBL came back to us with some odd behavior sent from our servers.

We implemented URIBL only on our SpamAssassin servers. These are EC2
instances that solely use SpamAssassin and are auto-scaling to meet the
demand.
In order to improve the DNS queries done, we install SA and Unbound and
update the resolv.conf file to point to localhost.

We almost don't modify SA. Here are the only changes we do:

time_limit 25
bayes_auto_learn 0

ifplugin Mail::SpamAssassin::Plugin::Shortcircuit
shortcircuit BAYES_99 spam
shortcircuit BAYES_00 ham
endif # Mail::SpamAssassin::Plugin::Shortcircuit

bayes_token_ttl 21d
bayes_seen_ttl 8d
bayes_auto_expire 1

dns_server 127.0.0.1

score FREEMAIL_FORGED_REPLYTO 1.5

That and the customized URIBL configuration for SA.

Here's the Unbound configuration: https://pastebin.com/Bn7B3uCv (expires in
a month).

The team at Uribl identified two issues that are really odd and shouldn't
happen from SA/Unbound, and I'm hoping someone on this list might know
something about it and help us figure out what is happening.


1. The first issue is that it seems that we are querying URIBL using random
lower/upper case domains. We had queries such as:

   - SoMeDoMaIn.cOM._custom_id.dF.URIbl.cOM
   - AnOtHeRDoM.ApP._custom_id.dF.UrIbL.COM
   - etc

I'd want to believe that SA would lowercase all the DNS requests before
sending them, but it doesn't seem to be the case.
What's odd is that the uribl.com part isn't from incoming emails, so it's
not something a spammer would send. It is definitely added somewhere
between SA and Unbound. But why?! It doesn't make any sense


2. The other issue is even weirder. SA is trying to validate the domains by
trimming the left part up to the gTLDs :


   - some.domain.com._custom_id.df.uribl.com
   - domain.com._custom_id.df.uribl.com
   - com._custom_id.df.uribl.com <-- wtf?


Somehow, something is trying to check up to the top TLD, where it's
useless. Again, I can't understand why SA would do that.

---

Does anyone have experienced that already? Would it be some specific
behavior from SA or Unbound when checking the DNS entries? Or maybe it is
related to AWS that does some specific modification that I'm not aware of?

I'm hoping someone will have an answer to this.

Thank you for your help, sorry for the long post.

Best,
Cyril
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Cyril - ImprovMX via mailop]

Dave Crocker said:

The challenge to the receiving site, then, is to decide whether to
> believe that evaluating intermediary site (as well as then deciding on
> an evaluation or the originating site.
>

This is exactly the point that I was making earlier and I 100% agree with
that. In order for ARC to be fully operational, the receiving party must
have a way to know if the sender can be trusted or not.
With ARC, this requires either a whitelist/blacklist system or relies on an
external service that provides that list. Relying on an external service is
even worse as they could implement a "pay to be on the list" system where
only the big one could be in.

Setting up a blacklist would cause too much damage for the receiver as they
would initially accept many bad emails before considering a sender bad.

The purpose of the service I run (ImprovMX) is exactly to forward email, so
we had our fair share of thinking on how to make it work properly.
SPF is not an issue at all, since it relies on the Return-Path email to be
verified: You can change it to your own and have a way to match any
response sent back (bounce, arf report, etc) to the original return-path to
reverse the steps.
One thing though you need to be sure of is that the sender either hasn't
implemented DMARC or has a valid DKIM Signature with the domain aligned to
the envelope From. Because DMARC requires domain alignment in **either**
the SPF or the DKIM domain part. Since forwarding breaks the alignment in
the SPF, it must remain valid in the DKIM.

ARC fixes this issue, by saying "It was ok before, but I broke it when
forwarding it", but it remains problematic regarding trust of the sender.

Le dim. 19 juin 2022 à 14:24, Dave Crocker via mailop  a
écrit :

>
> On 6/17/2022 6:17 AM, Paulo Pinto via mailop wrote:
> > tldr; what ARC tries to address is already correctly handled by
> > DKIM/SPF/DMARC if used as designed.
>
> None of those provide an authenticated handling record in the message.
>
> ARC is motivated by the cases where DKIM/SPF/DMARC information about the
> author/originator get broken.
>
> With ARC, besides a authenticated handling sequence, there is
> information about those original authentication tidbits that got broken,
> when the site providing the tidbits says how its own evaluation went.
>
> The challenge to the receiving site, then, is to decide whether to
> believe that evaluating intermediary site (as well as then deciding on
> an evaluation or the originating site.
>
> d/
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Cyril - ImprovMX via mailop]

ARC, from my understanding, can not be accepted as a viable solution for
accepting email that were modified (and had their SPF/DKIM broken).

Correct me if I'm wrong, but from what I understood, using ARC, I can craft
an email that came from joe.bi...@whitehouse.org - of course ignoring all
the SPF/DKIM that @whitehouse.org has implemented, add an ARC signature on
top of that saying that "yes, the email originally came from whitehouse.org
and SPF/DKIM was not broken at the time", sign this with an ARC-Signature
from my h4ck3r domain and all the services that have implemented ARC should
accept my email because, hey ! I signed it, you can trust me!

Obviously, this can't be it. One solution to this would be to set up a
whitelist of services that you can rely on when you receive an ARC-Signed
email, but this creates a two-way Internet and I prefer mine neutral, or at
least optimistic rather than favoring (yet again) the big player in
opposition to the new one coming to town and being honest.

But maybe I missed something on the way ARC works and it does really ensure
that the one signing the received email (and further modifying it, thus
breaking the SPF or DKIM) can be effectively trusted without a prior white
listing?

Le jeu. 16 juin 2022 à 20:11, Al Iverson via mailop  a
écrit :

> Jeff, this is really interesting. Thanks for sharing. This answers a
> lingering question for me as far as what practical applications there can
> be for ARC in a context other than a mailing list.
>
> Am I getting this right -- the way this would work is that another email
> platform would sign/"seal" a current state of the message authentication
> into the ARC header and then Microsoft, if it trusts that ARC signer, reads
> the ARC results to pass messages that would have perhaps otherwise failed
> authentication checks due to forwarding etc. past that point?
>
> Regards,
> Al Iverson
>
> On Thu, Jun 16, 2022 at 10:05 AM Jeff Dellapina via mailop <
> mailop@mailop.org> wrote:
>
>> Folks,
>>
>>
>>
>> As email passes thru our network, we make changes to the message. We may
>> add items to the header/footer or change links into “protected mode”.
>> Doing so breaks Authentication.
>>
>>
>>
>> Authenticated Received Chain (ARC). ARC helps preserve authentication
>> results *across* intermediaries.
>>
>>
>>
>> Learn more about ARC and how we make it work here:
>>
>> Improving “Defense in Depth” with Trusted ARC Sealers for Microsoft
>> Defender for Office 365 - Microsoft Tech Community
>> 
>>
>>
>>
>>
>>
>> We have used ARC for a while, but this is the first time we rolled it out
>> to our 0365 customers.  That said… there are some email filtering vendors
>> that are not using ARC which breaks authentication. In those cases, we are
>> forced to bulk or reject legitimate email sometimes from our own customers
>> who use email filtering services.
>>
>>
>>
>>
>>
>> Thanks,
>>
>>  Jeff Dellapina
>>
>>
>>
>> Sr. Email Delivery Manager
>>
>> SAGE  Team
>>
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://list.mailop.org/listinfo/mailop
>>
>
>
> --
>
> Al Iverson / Deliverability blogging at www.spamresource.com
> Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
> DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Question for Google -- how am I able to be added to google groups without opting in?

[Cyril - ImprovMX via mailop]

That's a really great question and I've also experienced a ton of spam
comming from Google Groups I never opted in.

I followed the recommendation of Brandon Long, and at my great surprise, I
was in 0 groups! (despite receiving spammy emails).

Just yesterday I got one (attached here as EML), saying it came from Google
Group, with a link to Google group that leads to an error, and an
unsubscribe link (and email) that never works!

Maybe they are faking the fact that they come from Google Groups: Looking
at the Received headers seems to indicate it was sent from an IPv6 address
toward Google, that then redirect to Outlook () to finally land in my
own GMail address.

I don't know if this is specific to my situation but it seems closely
related to what this thread is about. Hopefully, sharing an EML will bring
some light on the issue.

Best,
Cyril

Le jeu. 16 juin 2022 à 17:59, Dan Mahoney via mailop  a
écrit :

> All,
>
> I'm getting regular spam from google groups.  (This week, it's in
> Arabic).  Since it's google groups, any abuse reports would just be
> devnulled.
>
> Sender: -2040---_...@googlegroups.com
> List-Archive:  Dkim-Filter :
> OpenDKIM Filter v2.10.3 prime.gushi.org 25GFIHZg049346
> X-Spam-Asn: AS15169 2607:f8b0::/32
> Dmarc-Filter: OpenDMARC Filter v1.4.1 prime.gushi.org 25GFIHZg049346
> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on quark.gushi.org
> Authentication-Results: prime.gushi.org; dmarc=pass (p=none dis=none)
> header.from=gmail.com
> Authentication-Results: prime.gushi.org; spf=pass smtp.mailfrom=-
> 2040---__--+bncbdo7v2elqijrbletvwkqmgqehrat...@googlegroups.com
> Authentication-Results: prime.gushi.org; dkim=pass (2048-bit key;
> unprotected) header.d=googlegroups.com header.i=@googlegroups.com
> header.b=f2HCls9/; dkim=pass (2048-bit key; unprotected) header.d=
> gmail.com header.i=@gmail.com header.b=LDfTQwoh
>
> Can someone please explain to me how/why a google group manager is able to
> just add any email address and send to it?  Considering all the
> authentication they're requiring, this seems like a gaping hole in any kind
> of security.
>
> Can someone also explain to me why a group name like -2040---___-- isn't
> immediately flagged as hella suspicious?
>
> Specifically, the email address they're sending to is: freebsd *at*
> gushi.org, which I only use for mailing lists and bug trackers related to
> that project.  That project does not use google groups.  It's been
> harvested by a few other spammers, and sold a couple times, and at some
> point I'll move it to a year-based alias.
>
> -Dan
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
--- Begin Message ---





























* 4 box Routines offertes pour l'achat d'une box cliquer ici 
 [image: Cliquez sur Afficher les images 
pour voir le contenu correctement]    Pour vous 
desinscrire et ne plus recevoir d'e-mails de facon permanente envoyez un 
message d' ici *

-- 
このメールは Google グループのグループ「roaming」の登録者に送られています。
このグループから退会し、グループからのメールの配信を停止するには roaming+unsubscr...@googlegroups.com 
にメールを送信してください。
このディスカッションをウェブ上で閲覧するには、https://groups.google.com/d/msgid/roaming/2ec4cf39-a324-4a99-9539-9347141642d0n%40googlegroups.com
 にアクセスしてください。
--- End Message ---
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Increase in virus activity this week @ MXroute (perhaps others?)

[Cyril - ImprovMX via mailop]

That's super interesting (sorry for my late response here).

One thing that comes to mind reading the way you process the emails, is the
amount of false-positive you might get by implementing scripts that way.

I've been trying to do the same on our end, trying to automate the search
of abuses and notifying me of any suspicious activity, and there are
unfortunately many false positives that pop up, requiring more work to be
implemented.
I feel like it's a whack-a-mole game, but I definitely share the idea that
the human brain has the capacity of filtering out specific data that a
script can hardly produce by default.
When we have an issue arising, I tend to open the logs and just look at
them, and often, a pattern emerges.

Thank you for sharing your structure and your scripts, I really appreciate
it!

Good luck on fighting abusers.

Best,
Cyril



Le dim. 24 avr. 2022 à 02:36, Byung-Hee HWANG via mailop 
a écrit :

> (... sorry for top-posting ...)
>
> Dear Jarland,
>
> In the whole story, i feel that you are NICE guy!
> NICE(= faithful + technical + reasonable)
>
> Thanks ^^^
>
> Sincerely, Linux fan Byung-Hee
>
> Jarland Donnell via mailop  writes:
>
> > It's a good topic, and one I'm fairly passionate about. Obviously at
> > small scale it's super easy to tell when anything is off from normal,
> > but as you grow it's more difficult to rely on eyes and ears. But that
> > was kind of my dream: I want to be as present as though I'm one admin,
> > logged into one machine, merely watching it function and asking "Why?"
> > when something unusual happens (CPU spike, queue higher than it's been
> > this year to date, a flood of connections from X IP, etc). I want to
> > scale that, I want to scale me.
> >
> > So that's really what I do. I just scale me. If you were sitting in an
> > SSH session tailing a log and just watching for anything that sets off
> > a mental alarm, what would the things be that would trigger that
> > mental alarm? I take the answer to that and have automated checks
> > which then do one of two things:
> >
> > 1. Alert me for human review.
> > 2. Perform the reaction that I would have performed if I were sitting
> > there watching at the time.
> >
> > It can be kind of a mess but right now I'm at over 14,000 clients
> > (exponentially more if counting customers of my customers) and growing
> > rapidly. Thus far I've been able to grow myself by way of coding
> > checks and balances that operate like I think. That's pretty vague so
> > I'll give an example.
> >
> > In rspamd I have this map configured:
> >
> > COMPD_RCPT {
> >   type = "rcpt";
> >   header = "subject";
> >   filter = "email";
> >   map = "${LOCAL_CONFDIR}/local.d/compd_rcpt.map";
> >   symbol = "COMPD_RCPT";
> >   prefilter = true;
> >   action = "reject";
> >   regexp = true;
> > }
> >
> > Then I have this running on cron:
> >
> >
> https://paste.mxrouteapps.com/?6603394e7d823164#4r5qkNXATJTko55DWmwxjrrbTLCvJ9t5ry61cf5zfHE5
> >
> > Every morning I get up and I check /root/ALERT_RCPT.log and then open
> > a ticket with the customer. This is where the next automation will be
> > as the scale continues to grow, automatically targeting the user and
> > opening a ticket with them.
> >
> > Now what that map does, it lists the recipient emails used by specific
> > spammers who send "test" emails to verify SMTP credentials before they
> > start a campaign. Most of them use the same recipient email every
> > time, so all I have to do is look for it and know "That user's
> > password is compromised."
> >
> > For even more fun, I have a basic HTML page hidden behind
> > authentication which lists two columns. On one side, the top 15
> > senders of this hour. On the other side, the top 15 senders of the
> > last hour. Forcing yourself to be familiar with the top users of your
> > platform by observing how much of your infrastructure they are
> > utilizing creates a mental place where you can immediately recognize
> > when something is off. Toss it on a monitor, have the entire abuse
> > team just stare at it every time they glance away from their
> > work. While you might think that would outgrow it's usefulness with
> > scale, I've worked at large enough scale that I simply don't think it
> > to be so. The top resource users on your platform will change over
> > time, but the vast majority will always be too low utilization to be
> > noteworthy.
> >
> > Even still, if it were to be outgrown, a good database system could
> > keep track of senders enough to say "This person who only sent 1 email
> > a day for the last year just sent 600, might be worth checking the
> > logs to see if they're alright."
> >
> > And that's really where it all comes back to: What do I want to know?
> > What would concern me to see? What would I do if I saw it? Then, quite
> > simply, turn that logic into code and make it work for you.
> >
> > Hope that wasn't too vague to be useful!
> >
> > Jarland
>
> --
> ^고맙습니다 _布德天下_ 감사합니다_^))//
> 

Re: [mailop] Increase in virus activity this week @ MXroute (perhaps others?)

[Cyril - ImprovMX via mailop]

Hi Jarland,

that was very interesting, thank you for sharing these details.

I'm curious to know how you caught this in the first place. It would be
interesting to know some technics on how to catch bad behaviors before they
get out of hand and many of us here might be interested in the how-tos and
might also learn a lot from this (me first).

thank you in advance :)

Best,
Cyril

Le ven. 22 avr. 2022 à 00:57, Jarland Donnell via mailop 
a écrit :

> Hey friends,
>
> This week at MXroute we saw an increase in compromised email accounts.
> Apologies if you saw virus spam coming from our network. Typically,
> these events are caught instantly. In cases that use new patterns and
> techniques, under 1 hour. This time, it went on intermittently for about
> half a day on 4/20 (I wish it was for THAT reason), and it happened a
> few times in the days prior. What we found was that every one of these
> outbound emails contained this virus:
>
> https://www.virustotal.com/gui/file/707d507f138a450fb4c7b5c906f280259f23f5aac808b8dfcd23b66d0d679441/detection
>
> It's not difficult to assume that the users received the same virus
> beforehand, whether by email or otherwise. The virus appears to use each
> infected computer as part of a botnet, and each computer is involved in
> authenticating over SMTP and sending out copies of the virus. The only
> thing I never saw was our infected users connecting to our servers to
> send the spam, it was always other residential IPs in various locations.
> The emails themselves are difficult to nail down into patterns. Subjects
> ranged from "Firstname Lastname" (name of recipient perhaps?) to spoofed
> PayPal receipts. The emails mostly contained HTML and often some links,
> couldn't find a case of either being the same twice. The To/From headers
> did use a consistent spoofing trend and although the actual content of
> them rarely if ever repeated, the style is easy to grab on to:
>
> Example:
>  From: "serv...@paypal.com" 
> To: "2...@mail01.netgate.com.uy" <2...@mail01.netgate.com.uy>
>
> Frankly, the "To" header alone may be a consistent way to just shut
> these down until the patterns change. However, ensuring that the virus
> signature is present on inbound and outbound scanners is more likely to
> be effective for a longer period of time, I suspect.
>
> Finally, the last part of the trend which is noteworthy, all of the
> email accounts sent out a "test" email first. Unfortunately, it was
> rarely to the same recipient. Rarely, but not never. Two sample test
> email logs:
>
> 2022-04-20 12:53:58 1nh9qH-0008OE-RW <= winfield@{our customer's
> domain}.com H=host-79-10-109-221.business.telecomitalia.it (localhost)
> [79.10.109.221] P=esmtpsa X=TLS1.2:ECDHE-ECDSA-AES128-GCM-SHA256:128
> CV=no A=login:winfield@{our customer's domain}.com S=735 T="ZYaeD, X "
> from  for
> toewebvastsatw...@gmx.com
>
> 2022-04-20 12:53:40 1nh9q0-00HECV-Al <= register@{our customer's
> domain}.org H=mail.dfclark.co.uk (localhost) [149.255.169.82] P=esmtpsa
> X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=no A=login:register@{our
> customer's domain}.org S=691 T="wFd2, MkRWa2 A" from  customer's domain}.org> for toewebvastsatw...@gmx.com
>
> And for kicks, a few sample email subjects: https://clbin.com/dGT1y
> (sorted by count of repeat subjects from one compromised account)
>
> I sincerely hope that this helps someone else in the never-ending effort
> to keep IPs clean.
>
> Sincerely,
> Jarland Donnell
> MXroute Administrator
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is there anyone working at Invaluement?

[Cyril - ImprovMX via mailop]

Awesome, thank you very much for that! I wasn't aware of your massive
upgrade but can understand the delay on answering requests, no worries here!

I got your email off-list, I'll reply there asap.

Thanks!

Le ven. 22 avr. 2022 à 14:13, Rob McEwen via mailop  a
écrit :

> I will answer this off list today. At invaluement, for the past 2 weeks,
> we've been in the middle of the largest hardware upgrade we've done in over
> 5 years, so we're backed up on requests like this one. We haven't even
> processed new trial requests during this crazy time. I have about 5 others
> requests like this that I've been trying to get to for the past several
> days. (as I understood it, the question was about past listings, not an
> active one)
>
> Sorry for the noise this caused!
>
> Rob McEwen, invaluement
>
> Sent from my Verizon, Samsung Galaxy smartphone
>
>
> Rob McEwen, invaluement
> 478-475-9032
>
> Sent from my Verizon, Samsung Galaxy smartphone
>
>
>  Original message 
> From: Cyril - ImprovMX via mailop 
> Date: 4/22/22 6:21 AM (GMT-05:00)
> To: Cyril - ImprovMX 
> Subject: [mailop] Is there anyone working at Invaluement?
>
> Hi everyone, sorry to bother you with such requests but I'm having a hard
> time reaching out to Invaluement (https://www.invaluement.com/)
>
> Our IPs got listed there and I'm trying to open a line of communication to
> better understand what happened, in order to fix it before requesting for
> delisting.
>
> If someone on this list is working at Invaluement and can reach out to me,
> that would be fantastic.
>
> Thank you and have a nice weekend :)
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Odd delay at Gmail ?

[Cyril - ImprovMX via mailop]

Hi Brandon,

Nice to meet you and thank you for answering my email.
I managed to get the eml from that user if you are interested in checking
the headers and seeing if you notice any odd behavior.

What I remain curious to know is why the Date in the Received header had
its timezone changed, but the hour was not modified accordingly to the
timezone, this is really surprising.

Best regards,
Cyril

Le ven. 22 avr. 2022 à 02:54, Brandon Long  a écrit :

> While every attempt is made to deliver mail as quickly as possible, any
> sufficiently large distributed system will occasionally have issues.
>
> We monitor the delivery latency within our systems, and act when they go
> bad.
>
> At times, there have been deliberate choices made to the design which
> allowed for extended queuing when we had datacenter outages, instead of
> insuring writes hit multiple datacenters... for example.
>
> It's also possible for individual mailboxes to be overloaded, due to the
> store & forward nature of email, it's not always possible to push back at
> smtp time, and so internal queuing occurs.
>
> Historically, it was also possible for individual mailboxes to have issues
> that could require fixing... there's still some issues due to locking of
> the entire mailbox under some scenarios, though it seems unlikely to result
> in an 8h delay.
>
> Every once in a while there's also a message-of-death or other issue,
> where something about an individual message makes our system unhappy or
> causes extensive cpu usage.
>
> And that's without adding in additional complexities that some companies
> have for their email routing, which can add a very large number of hops or
> even administrative quarantine.
>
> All of this would be visible in the Received headers of the message...
> though only the successful attempts, not the failed ones that resulted in
> retries, we considered at one point how we could add that information as
> well, but that never went anywhere.  For workspace customers, there is the
> email log search which allows you to see where a message is and retry
> attempts.  At one point I started a proposal for something simpler for
> individual mailboxes, but it got complicated quickly and didn't make the
> prioritization cutoff.
>
> Folks definitely tend to think of email communications now being as fast
> as instant messaging, and they dislike when there are delays and no
> indication of such... the fact that we'll retry a message internally for up
> to 3-5d is
> completely out of touch with what user expectations are... but bounces are
> also terrible.  Outside of making sure that a high percentile of messages
> are delivered in reasonable times, I'm not sure anyone has come up with
> a better solution.
>
> 8h would be a fairly large statistical outlier, that's for sure.
>
> Brandon
>
> On Wed, Apr 20, 2022 at 3:57 AM Cyril - ImprovMX via mailop <
> mailop@mailop.org> wrote:
>
>> Hi everyone !
>>
>> I'm reaching out in the hope to find someone in the same situation, and
>> that I can receive some input on why this happened.
>>
>> We forward a lot of emails including to Gmail, and a user reached out to
>> us because their email arrived in their inbox with a delay of 8 hours!
>>
>> That user was able to send us the .eml, so I was able to peak at the
>> headers. What I noticed is that the Date present in the email was in UTC
>> all the way up to us, but when it left our server and landed at Gmail, it
>> changed, but ... oddly.
>>
>> The "Date" header was "Thu, 14 Apr 2022 18:29:43 +" and during the
>> processing in the sender, and in our servers, it remained the same with a
>> few seconds changing, but that's all.
>>
>> We forwarded it to "gmail-smtp-in.l.google.com", and the next date
>> present (in the "Received" header) became "Thu, 14 Apr 2022 19:24:28 -0700
>> (PDT)"
>>
>> I don't mind the timezone changing, but the hour only changed for one
>> hour, while the timezone changed by an offset of 7 hours! The two changes
>> resulted in a difference of 8 hours, which is exactly when the user saw his
>> email in his inbox.
>>
>> What happened here ?
>>
>> Our logs clearly show that we forwarded the email in under 2 seconds and
>> we didn't mess with the dates (or anything, for that matter).
>>
>> Does anyone here experience this before? Do you have any explanations
>> about what happened?
>>
>> I'd love to reach out to Gmail to ask them about this, but, well, it's
>> Gmail.
>>
>> Thank you for your help!
>>
>> Best,
>> Cyril
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://list.mailop.org/listinfo/mailop
>>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Is there anyone working at Invaluement?

[Cyril - ImprovMX via mailop]

Hi everyone, sorry to bother you with such requests but I'm having a hard
time reaching out to Invaluement (https://www.invaluement.com/)

Our IPs got listed there and I'm trying to open a line of communication to
better understand what happened, in order to fix it before requesting for
delisting.

If someone on this list is working at Invaluement and can reach out to me,
that would be fantastic.

Thank you and have a nice weekend :)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Odd delay at Gmail ?

[Cyril - ImprovMX via mailop]

That idea also crossed my mind, that it would only be displayed when the
actual time is > than the Date in the email.
Unfortunately, that's something I cannot tell, I don't know and since it is
occurring rarely, it's hard to ask the user to "try again".

Le mer. 20 avr. 2022 à 18:11, Laura Atkins via mailop  a
écrit :

>
>
> On 20 Apr 2022, at 16:44, Cyril - ImprovMX via mailop 
> wrote:
>
> Thank you all.
>
> About Laura's question, I can confirm that on our end, we successfully
> forwarded the message with a 2XX response from Google within a few seconds.
> Our timestamp show that this user should have received the email 8 hours
> before he really received it.
>
>
> How was he accessing the mail? Was he using an IMAP client or one of the
> Google controlled MUAs?
>
> Like, I’m wondering if this was just a display issue (say: Google won’t
> display mail until the actual timestamp) or if Google really held onto the
> mail somewhere in a spool until the timestamp was accurate. It seems weird
> to me that Google would sit on an email for exactly 8 hours and then
> deliver it to him. But it seems not-unreasonable to me that Google would
> have their client set to not display email until after it was delivered
> (and because of the timestamp issue it wasn’t ‘delivered’ for 8 hours.
>
> But an IMAP client that isn’t under the control of Google will display the
> message if it’s in the inbox, no matter if it was delivered yet or not.
>
> laura
>
> --
> The Delivery Experts
>
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com
>
> Email Delivery Blog: http://wordtothewise.com/blog
>
>
>
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Odd delay at Gmail ?

[Cyril - ImprovMX via mailop]

Thank you all.

About Laura's question, I can confirm that on our end, we successfully
forwarded the message with a 2XX response from Google within a few seconds.
Our timestamp show that this user should have received the email 8 hours
before he really received it.

@Alexander: Your suggestion is very interesting! We recently started
implementing MTA-STS so it's highly possible that we messed something up in
that regard. I'll take a close look tomorrow about it. If I find anything,
I'll keep this thread updated.

If any of you have any suggestions, I'm all ears!

Thank you for your help!!

Le mer. 20 avr. 2022 à 15:39, Alexander Huynh via mailop 
a écrit :

> On 2022-04-20 12:51:47 +0200, Cyril - ImprovMX wrote:
> > What happened here ?
>
> Anecdotally, I recently switched MX servers and found that my emails
> from Google were also delayed for about 8 hours. The next day when I
> received my MTA-STS reports, I found 53 failures as reported by Google,
> since my then MTA-STS policy did not include the new MX server. While I
> can't say your issue is due to MTA-STS cache invalidation, I would
> suggest checking the various nuts and bolts both internally, and using
> external validators.
>
> Hope this helps,
> --
> Alex
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Odd delay at Gmail ?

[Cyril - ImprovMX via mailop]

Hi everyone !

I'm reaching out in the hope to find someone in the same situation, and
that I can receive some input on why this happened.

We forward a lot of emails including to Gmail, and a user reached out to us
because their email arrived in their inbox with a delay of 8 hours!

That user was able to send us the .eml, so I was able to peak at the
headers. What I noticed is that the Date present in the email was in UTC
all the way up to us, but when it left our server and landed at Gmail, it
changed, but ... oddly.

The "Date" header was "Thu, 14 Apr 2022 18:29:43 +" and during the
processing in the sender, and in our servers, it remained the same with a
few seconds changing, but that's all.

We forwarded it to "gmail-smtp-in.l.google.com", and the next date present
(in the "Received" header) became "Thu, 14 Apr 2022 19:24:28 -0700 (PDT)"

I don't mind the timezone changing, but the hour only changed for one hour,
while the timezone changed by an offset of 7 hours! The two changes
resulted in a difference of 8 hours, which is exactly when the user saw his
email in his inbox.

What happened here ?

Our logs clearly show that we forwarded the email in under 2 seconds and we
didn't mess with the dates (or anything, for that matter).

Does anyone here experience this before? Do you have any explanations about
what happened?

I'd love to reach out to Gmail to ask them about this, but, well, it's
Gmail.

Thank you for your help!

Best,
Cyril
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Cyril - ImprovMX via mailop]

I can understand the frustration and tension in these emails as Gmail
clearly doesn't provide any helpful way to resolve issues.

We too are in the same scenario. We got our domain lowered to bad about two
months ago, without any apparent reasons (no clear changes on our end), and
we are now struggling to find ways to revert it back to good. We read lots
of blogs talking about this, but they often talk about setting up
SPF/DKIM/DMARC, and having custom content with no or few links, etc, which
already (SPF/DKIM/DMARC) or does not (links/content) apply to us.

I am like Jaroslaw Rafa here: I want to believe. I want to believe that
there is a way to revert these bans back to normal.

I'd love to know why our domain has been pushed to "bad", in order to work
on fixing this issue.
I'd love to know why our IPs have been blocked and to have a way to request
delisting, even if it needs to talk to a team in order to explain what was
done, what has been implemented, and all needed proof that we are not
spammers.

Unfortunately, as far as I know, and as far as everyone seems to understand
from Google on this mailing list, Gmail is a black box. Nothing comes out
of it, and no one is providing clear solutions and explanations about what
to do.
I suspect this is not related to the people working at Google specifically,
but more about a policy set by the organization.

I'd LOVE to be proven wrong.

Please prove me I'm wrong.

Le ven. 15 avr. 2022 à 14:41, Jaroslaw Rafa via mailop 
a écrit :

> Dnia 14.04.2022 o godz. 12:40:52 Al Iverson via mailop pisze:
> > > Yes, it is unfixable. Once Google's AI decides (for no apparent
> reason) that
> > > it will reject e-mails from you, or put them to recipients' spam
> folder,
> > > there's pretty much nothing you can do about it.
> >
> > That is false.
>
> I can believe your claim that "that is false" if you can give me a WORKING
> advice of what can I do to make my e-mails get to the Google's inbox. Other
> than "change your ISP" or "change your domain", as this is NOT A SOLUTION,
> as I already stated.
>
> BTW. It's definitely a domain thing, not an IP reputation thing, since I
> send from the same server e-mails from different domain that I mentioned in
> my previous email, and those get through. However mails from this address
> don't. They are hand-typed, plain text, without any links or attachments.
> Just like this one. But anything coming from this domain is right away
> spam-marked by Google.
>
> I have discussed this even directly with Brandon Long from Google on this
> list. I have submitted the issue via their "sender troubleshooting form"
> multiple times (BTW. they state it clearly in the form that you WON'T GET
> ANY RESPONSE!). No effect.
>
> If you still think this is fixable, then give me a working fix.
>
> Just for comparison, I want to tell you about a completely different
> experience. I mailed someone with the address @mail.ru. Mail.ru didn't
> like
> my IP address and rejected the email - giving me in the rejection message
> an
> URL to the page where I can request unblocking for my IP. I filled in the
> form, next day I got a message that I'm unblocked. Everything smooth and
> without any problems.
>
> That's what I would expect from a company as popular as Google.
> --
> Regards,
>Jaroslaw Rafa
>r...@rafa.eu.org
> --
> "In a million years, when kids go to school, they're gonna know: once there
> was a Hushpuppy, and she lived with her daddy in the Bathtub."
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Our experience on Gmail blacklisting our IPs range

[Cyril - ImprovMX via mailop]

Thank you everyone for your response.

I don't mind the false positives, it's part of the game and shows that it's
not perfect. But not having a way to interact with it and not having a way
to reach out, explain the situation and know more about what is
happening/what will happen is a pita.

We sometimes get our emails listed at Sorbs, and no matter what, they
always respond, and even in time. I believe that email is one of the last
remaining protocols that was built in the beginning to be open and
impartial, and many big players are trying to rig the game in their favor.
Running an MTA today requires a lot of knowledge and ideally a big team
with investment to support all the tricks. It shouldn't be the case.

@Todd, thank you for that link! It seems that it was exactly the issue we
were facing. I'll seek to implement ways to mitigate these in the future
(but already, banning the free domains helped a lot)

Le mer. 6 avr. 2022 à 08:40, Todd Herr via mailop  a
écrit :

>
> On Tue, Apr 5, 2022 at 6:35 AM Cyril - ImprovMX via mailop <
> mailop@mailop.org> wrote:
>
>>
>> After a discussion with OVH about this potential issue, I discovered that
>> the problem was worst than that. By comparing all the emails from
>> Spamcop.net reports, I discovered that they were from a few emails, but
>> then, they had new headers added on top. This included a new "To",
>> "Subject" and "Date" header. An email sent 4 days ago was sent again, with
>> an updated date. The initial "Subject" was basic things like "hello" and
>> the new Subject added at the top was more spammy (the typical horny stuff).
>>
>> Clearly, someone used the reputation of ImprovMX.com to deliver emails by
>> forging them before delivery.
>>
>>
> What you're describing sounds exactly like a DKIM replay attack.
>
> Socketlabs, among others, have some ideas on how to mitigate such things.
> Perhaps you might find those ideas useful -
> https://www.socketlabs.com/blog/dkim-replay-attacks-preventive-measures-to-protect-email-deliverability/
>
> --
>
> *Todd Herr * | Technical Director, Standards and Ecosystem
> *e:* todd.h...@valimail.com
> *m:* 703.220.4153
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Our experience on Gmail blacklisting our IPs range

[Cyril - ImprovMX via mailop]

Hi everyone!

Two weeks ago, we had two ranges of IP blocked by GMail and since they are
a black box, we were in the dark about what would happen with the ban.

We made some progress since then and I wanted to share with you what
happened, what we did, and what resulted from it because it might help
others have their IP unblocked by Gmail.

About two weeks ago, we started receiving abuses reports because somehow
our emails were used as spam. At first, I thought they were occasional and
discarded them (we get a few from time to time), but they kept arriving,
and we had more and more reports every day (up to around 50 abuses reports
per day).

I started retracing the emails back (we add some headers that help us
identify the whole flow) and discovered that many reports were originating
from the same email. The abuse reports included a spamcop.net report with
the entire email (but with the destination recipient removed). My initial
assumption, then, was to believe that OVH (our hosting provider, sending us
the abuse reports) and/or Spamcop.net weren't checking for duplicates, and
someone sending many abuse reports from the same email triggered the
notifications, every time.

After a discussion with OVH about this potential issue, I discovered that
the problem was worst than that. By comparing all the emails from
Spamcop.net reports, I discovered that they were from a few emails, but
then, they had new headers added on top. This included a new "To",
"Subject" and "Date" header. An email sent 4 days ago was sent again, with
an updated date. The initial "Subject" was basic things like "hello" and
the new Subject added at the top was more spammy (the typical horny stuff).

Clearly, someone used the reputation of ImprovMX.com to deliver emails by
forging them before delivery.

It took us a few days to realize this whole situation, which caused our
domain and IP reputation to take a serious hit. As soon as we uncovered it,
we started blocking all the domains that were doing this. We also were able
to retrace other accounts created by the same user and blocked all the
domains. All of these domains were free ones (ending in .ml, .cf, .gq, .ga,
etc) so we also decided to stop accepting these domains.

But the harm was done, for 50% of all our IPs, Gmail stopped accepting them
and was returning "*Our system has detected that this message is likely
suspicious due to the very low reputation of the sending domain. To best
protect our users from spam, the message has been blocked*".

We started to panic.

We know that Gmail is impossible to reach out to, and we had absolutely no
idea if these IPs were blocked forever, or, if not, for how long.

The first thing we did was to stop running these IPs for a while.

We also went to this URL (
https://support.google.com/mail/contact/bulk_send_new) and submitted
everything we could, by being the most verbose possible.

And we waited...

We tried restarting the IP the next day, but they were still being refused
so we disabled them.

After around a week, we restarted the IP and they were accepted by Gmail!
We haven't received any responses from the form we submitted, nor from
anywhere else.

Our domain reputation is still in the "bad" from the Postmaster tool (
https://gmail.com/postmaster/) and we are trying to find ways to reverse it
(still haven't figured that one) but the IPs are now working again.

My key takeaway here in case your IPs are banned by Gmail is:


   - First - and most importantly - find and stop the root cause of the
   problem
   - If you can, stop sending with these IPs (after fixing the issue,
   otherwise you'll get your other IP listed too!)
   - Reach out to Gmail via
   https://support.google.com/mail/contact/bulk_send_new
   - Try restarting your IP from time to time.


Someone working at Google told us that their Spam Ops were easily removing
the flags on the IPs when it was the first time, so if you get your IP
frequently blocked at Google, maybe this won't apply to you.

I hope this will help some of you. Being blocked by Gmail is hard, and
facing a black box makes it even harder. You don't know where to look, you
don't know what to do, you don't know who to reach out to.

My associate sent a message on this mailing list regarding our issue,
trying to have feedback on what to do and if someone else already faced
this, and we had some awesome help and feedback from people (thank you so
much) but the general feeling was clearly that Gmail is not on this world.

May your IPs stay out of DNSBLs.

Best,
Cyril
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop