Re: [mailop] DMARC external destination verification ignored?

[Ángel via mailop]

On 2024-02-06 at 15:55 +, Vitali wrote:
> 
> Are they violating the RFC or is there a new DMARC report exception
> if both domains share the MX root domain?
> 
> Thank you.
> Vitali

It would have been preferable that you shared that domain, but it does
seem to violate the RFC.
The only pecuiar bit I see is that _report._dmarc.emailzustellbarkeit.d
e IS set.

$ dig  _report._dmarc.emailzustellbarkeit.de txt
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52922
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
_report._dmarc.emailzustellbarkeit.de. 7200 IN TXT "v=DMARC1"


but the RFC is clear that the wildcard need to be on *._report._dmarc.e
mailzustellbarkeit.de, a record on
 _report._dmarc.emailzustellbarkeit.de wouldn't match

(and, if strictly conforming, there should also be a semicolon after
"DMARC1")


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Spamhaus SBL listing fonts.googleapis.com

[Ángel via mailop]

On 2024-02-06 at 21:52 +0100, Andreas Schamanek wrote:
> Thanks, that's the aspect my foggy brain missed. It only matters for 
> those who check URIs, especially if found in the body, or more 
> precisely the IPs of the hostnames of these URIs.
> 
> (...)
> 
> So, I still got questions :) like why did these IPs end up on SBL in 
> the first place, and why does Spamhaus check against them?

Since you noticed this, you must be receiving emails containing urls to
fonts.googleapis.com (most probably inside some CSS rule to explicitly
set an specific typeface).

Just like whoever is sending you this, some spammers will be doing the
same. And thus, fonts.googleapis.com ends up listed. 

I see little reason to hotlink a font in an email, but either those
doing that care a lot about the typeface, or they are blindly copying
their website CSS which contains those urls.

Checking of the urls included in the mail was probably intended for
linkable urls (and, maybe, images), but if the email contains more
urls, checking them is one more point that can be used on the war of
discerning ham from spam.

I think there is a spamassassin setting you could use so that
fonts.googleapis.com bypass the filter.

Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Samsung and SIZE

[Ángel via mailop]

On 2024-01-15 at 16:03 -0800, Randolf Richardson, Postmaster wrote:
> > I have seen my share of MUAs that behave in weird ways when
> > encountering things larger than it can handle, so you have
> > to  always cope for them in the mail server. Implementing different
> > types of restrictions, and filtering things out of subjects and
> > certain headers to evade crashing MUAs.
> 
>   998 characters (not including CRLF), as I recall, is the
> maximum 
> limit, which is specified in RFC 5322 (section 2.1.1):
> 
>   RFC 5322 :: Internet Message Format
>   
> https://datatracker.ietf.org/doc/html/rfc5322#section-2.1.1

That's the limit for the *physical* line. The Subject: header could
span multiple lines and thus be larger.

Not that a Subject so large would make sense. I doubt your client would
be able to show it to the user.
Processing the email as if the subject was made of just the first 255
characters seems acceptable to me.

OTOH, I have seen people writing long emails, all in the Subject: line,
with hundreds of bytes.

Yes, some people advocate for subject-only emails, but it didn't seem
done on purpose.
https://www.lifewire.com/what-is-eom-end-of-message-1171156

It didn't make sense. The user somehow confused the field where they
should write...




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] MUA images, avatars and icons

[Ángel via mailop]

On 2024-01-11 at 17:43 +0100, Jaroslaw Rafa wrote:
> And it's clearly visible from the Laurent's mail that if MUAs will display
> the unverified BIMI logos (and what would prohibit them from that?) the
> "authentication" factor can be even weaker than with no avatars at all -
> because user who is convinced that the logo being displayed means that the
> message is genuine, may not even look at the actual sender field.
> 
> Also, if a hypothetical MUA displays BIMI logos, but also displays avatars
> obtained by other means (one of the users in the thread mentioned a MUA he
> develops that uses eg. favicons, or Gravatar service for that purpose), how
> the user is supposed to distinguish which avatars are verified BIMI logos,
> and which ones come from a totally different source?

Every MUA must be able to show whatever it wants. And each one will
have its own some design goals. Hopefully sane and consistent, albeit
they might end up being chaotic at times.

I see how some people may like seeing images along the profiles. I also
see the benefit of (configurable) multiple sources for that.

For example, Microsoft Outlook shows the profile images from Active
Directory. This can be useful for instance for sorting out which guy 
was each one in a meeting, and makes much more sense to prioritize that
over a BIMI logo of your own company, which would be relatively
pointless to shown on pretty much every email.

But if I have set a photo for that Contact (e.g. a Clown face for my
boss), it should be showing *that* (albeit I might face some pushback
from my boss or HR if they figure out).

It can be useful to show X-Face or Gravatar from certain mails, such as
those coming from a (trusted) forum (hint to Louis: it may be useful to
be able to configure the images to show for specific senders), 


But, as Laurent mentioned, this is going to be prone for impersonation,
with a goal of leading uers to phishing, BEC fraud, etc.

A really important point here is that the BIMI logos themselves *must
be validated* by the MUA. I have been looking at the draft [1], and
while there are references to a "BIMI Evidence Document", which is
supposed to validate whether I am allowed to use a trademarked logo (at
an undefined jurisdiction, I was unable to find its specification, it
simply says that "These are defined in a separate document".

Perhaps Seth can bring some light on this. I think that is an integral
part of the BIMI security properties, that it MUST contain both a hash
of the allowed logo (or logos), the jurisdiction(s) where it was
validated (see below) and the linked sender domains (plus whatever
properties that are needed for validate that through PKI).

And the receiver steps miss that they MUST compare the logo with the
Evidence Document, and reject it if it mismatches.

Otherwise, I could register a trademark IOCBYHZ with a random logo, and
switch the contents of the url to a PayPal one. People are already
registering ludicrous names as trademarks to enter the Amazon Brands
program [2]. Registering a trademark and logo, plus acquiring a
certificate, for a targeted attack to a company has an higher bar. But
a successful CEO fraud could easily make it worth. Not to mention if
the goal were to compromise the company, exfiltrate its trade secrets
or launch a supply-chain attack.

Having the certificate specify on which jurisdiction is the trademark
registered would at least palliate “a bit” the known issue of colliding
names/trademarks on separate jurisdictions[3][4] by allowing the
clients to ignore (by policy) those in shady offshore jurisdictions
and, ideally, showing only those pertinent to the user... if the MUA is
somewhat able to figure out what "pertinent" means.

Would that mean that companies may need to register an international
trademark or apply for the same one in different jurisdiction for BIMI
to show to their different users around the globe? (along the
associated registration and certificate costs). I'm afraid that may end
up being the case.

Maybe some MUA will overlap a flag onto the trademark, or allow
choosing which countries / trademarks it will honor.

Although I doubt the users that the feature intends to protect would
notice the small differences due, anyway.

It's a complex issue with no easy solution. I feel we are back at the
all EV Certificates scenario, with all the same unsolved problems. We
just replaced names with logos.



1- 
https://datatracker.ietf.org/doc/html/draft-brand-indicators-for-message-identification
2- 
https://nymag.com/intelligencer/2023/01/why-does-it-feel-like-amazon-is-making-itself-worse.html
3- 
https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/
4- https://scotthelme.co.uk/the-power-to-revoke-lies-with-the-ca/



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott?

[Ángel via mailop]

On 2024-01-10 at 20:38 +, Gellner, Oliver wrote:
> > Its also may be yet another reader-engagement tracker. Why do those
> > things always have to be out of band.
> 
> Well, there’s no automated way to connect a logo to a domain. The
> BIMI group has decided to build upon the work of trademark offices to
> connect logos to companies and then set up a manual verification
> process to connect the company to a domain. There might be other ways
> to do this, but you cannot just use DNS or a message header to link a
> logo to a domain as this would be trivial to exploit.
> 
> Either way, BIMI is not suitable for reader tracking as you cannot
> provide different logo URIs for each recipient.

Sorry, but it would be possible:
> Domain Owners can specify which other selector to use on a per-
> message basis by utilizing the BIMI-Selector Header

You could set a different selector per email message sent. You could
manage that with a wildcard dns entry and check the dns server logs.


However, the draft is specified in such manner that the fetching would
be done by the MTA, so the BIMI check and fetching wouldn't provide
information to the senders.
Only if a MUA tried to perform all checks itself (because its mail
server doesn't support BIMI, for instance).

Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] ECDSA DKIM validation?

[Ángel via mailop]

On 2023-12-21 at 18:13 +0100, John R Levine wrote:
> > With the number of messages already arriving with multiple DKIM 
> > signatures I can't imagine their reputation systems don't already handle 
> > dual signing just fine. Granted this would be two signatures on the same 
> > domain, but that seems that a small change from handling a signature on 
> > the From plus one from the ESP and maybe even one for the 
> > list-unsubscribe domain.
> 
> If there's two signatures for the same domain, one is good and one is
> bad, which do you believe?  I know what the spec says, but we have no
> practical experience.

We can already add a dozen signatures to a single email. All of them
RSA in the range accepted by gmail. It already needs to handle that in
*some* way. Panicking is not an option.
Picking only the signature that passes is not just what the spec wants
you to do. It's the one that makes sense operationally.

Regards



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New hotmail function: 'Put emails from unknown sender as Junk' causing false complaints?

[Ángel via mailop]

On 2023-10-24 at 14:11 +, Gellner, Oliver via mailop wrote:
> As far as I know this feature is not new but exists since a long time
> (years). It treats all messages from senders which are not on your
> safe senders list as spam and looks something like this: 
> https://filestore.community.support.microsoft.com/api/images/4a70ef0e-8c01-4d47-973c-6776c61aca90
> Why Microsoft is sending those messages into the feedback loop is
> another question. In a perfect world there should be filters in place
> which suppress/flag reports from an account if the spam reports reach
> a certain percentage of all received emails of this account.

And even without keeping statistics for filtering them, automatically
moved messages by this option should not be feeding the FBL.



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Authentication Bounces by Gmail

[Ángel via mailop]

On 2023-09-15 at 10:26 +0200, Alessandro Vesely via mailop wrote:
> I get this language, on forwarding:
> 
> Remote-MTA: dns; gmail-smtp-in.l.google.com [74.125.71.27]
> Diagnostic-Code: smtp; 550-5.7.26 Unauthenticated email from 
> intesasanpaolo.com is not accepted due to
>  550-5.7.26 domain's DMARC policy. Please contact the administrator of
>  550-5.7.26 intesasanpaolo.com domain if this was a legitimate mail. 
> Please
>  550-5.7.26 visit
>  550-5.7.26  https://support.google.com/mail/answer/2451690 to learn 
> about the
 0 550 5.7.26 DMARC initiative. 
t16-20020a05600c451000b003fee9453d8csi1042282wmo.59 - gsmtp
> 
> MAIL FROM was rewritten so as to pass SPF.  ARC sealing the message
> provided no benefit except checking, from the bounce, that the body
> hash in AMS matched the one on the original DKIM signature, which had
> passed.  The message was legitimate and none of the signed headers,
> h=date:from:to:cc:message-id:subject:mime-version:content-type was
> altered.  Why should I contact the administrator of the original
> sender?
> 
> Best
> Ale

If this message came directly from intesasanpaolo.com (i.e.
intesasanpaolo.com was sending through tana.it server but not listing
it on their SPF), that's something to the administrator of intesasanpao
lo.com could be interested in.

Th DKIM pass should have been enough, though...






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Legit-looking mail to the wrong address with no unsubscribe

[Ángel via mailop]

On 2023-08-24 at 14:29 -0400, postfix--- via mailop wrote:
> (...)
> Needless to say:  I will avoid restaurants using OpenTable, whether 
> while visiting destinations or at home.  If they cannot choose a
> service provider that is respectful of my choices, they do not
> deserve my business.

Great opportunity lost here to add a tip in the bill, then subtracting
in an itemized way a fee for the text message on roaming, for every
reminder email and for suggesting you're so dumb to need an email
telling you you're seated at the restaurant (maybe that reflects the
average IQ of their patrons?)


Not sure they would take action on clearly viewing the monetary results
of their "awesome system", but it would certainly be a bill that would
do rounds on the internet for years.


Cheers


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] I Need someone from AOL and/or Yahoo to contact me

[Ángel via mailop]

On 2023-07-25 at 17:14 +0200, Sebastian Nielsen via mailop wrote:
> Sadly not all MUAs implement ClientID either.
> Easiest way to implement 2FA on email, is to have a webpage, where
> you login with your 2FA token. When you have done that, the IP to
> visit that webpage is written to the account's authorized IP list.
> For user friendliness, you could save, lets say the 10 latest IPs
> used to access that webpage.

That's the easiest to the developer implementing it, not for the user,
which may need to authorise his new IP every day.

If you want that to be simple for the user, you should probably
implement XOAUTH2 (which hopefully will already be supported by the
client). But that's much more work for the server developer.


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Strange mail delivery from microsoft

[Ángel via mailop]

On 2023-06-19 at 07:01 +0100, Klaus Ethgen wrote:
> Am Mo den 19. Jun 2023 um  6:33 schrieb Hans-Martin Mosner:
> > I'm inclined to repeat what I said before: If your setup breaks
> > mail consistently, it's likely your setup that's to blame. Others
> > seem to be able 
> > to receive Outlook mail just fine. Microsoft didn't ask you to
> > implement an arbitrary connection rate limit,
> 
> Well, they do some kind. They host attacking hosts.


As mentioned before, I don't think they are using for hosting third-
party servers.

They may host mailboxes for malicious customers, though.

I blame them by using a big amount of IPs to deliver mails even for
> the same mail and for giving a host for malicious hosts that try to
> get spam out. I blame them also for doing connections that are
> absolute not needed and a wast of bandwidth.

Microsoft spreading their connection attempts through a large amount of
IP addresses seems precisely suited for someone limiting the number of
connections/mails by IP, as you are doing.


> Moreover, the mail server is a low trafic server so 10/hour should be
> ok for the most delivery systems.

I get 2-4 mails from 40.92.*  **per day**

From spam mailboxes, though. Interestingly, I don't see those in the
msbl

Regards




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Strange mail delivery from microsoft

[Ángel via mailop]

On 2023-06-18 at 17:53 +0100, Klaus Ethgen wrote:
> Hi,
> 
> I have tighten my firewall a bit and seen many attacks from Microsoft
> (40.92.0.0/16). They contact once from a IP and then never again. If I
> greylist them, the will try to deliver from a different address which
> gets greylisted again and so on.

hotmail.com claims it delivers email from the whole 40.92.0.0/15:


> spf.protection.outlook.com. 600   IN  TXT "v=spf1
ip4:40.92.0.0/15...


which seems completely overkill (maybe they want to keep the ability to
serve a customer per ip?), specially since they also use many other
ranges (full list below) but if they used that address space for
anything other than their own email hosts they would be giving a free
spf pass for those, so anything from there must be coming from their
"official" MTAs.

In which case, I don't think it makes much sense to graylist them.


Regards



$ spfwalk hotmail.com | sort -n 
2a01:111:f400::/48
2a01:111:f403::/49
2a01:111:f403:8000::/50
2a01:111:f403:c000::/51
2a01:111:f403:f000::/52
40.107.0.0/16
40.92.0.0/15
52.100.0.0/14
65.54.121.120/29
65.54.190.0/24
65.54.241.0/24
65.54.51.64/26
65.54.61.64/26
65.55.111.0/24
65.55.113.64/26
65.55.116.0/25
65.55.126.0/25
65.55.174.0/25
65.55.178.128/27
65.55.234.192/26
65.55.238.129/26
65.55.238.129/26
65.55.33.64/28
65.55.34.0/24
65.55.52.224/27
65.55.78.128/25
65.55.81.48/28
65.55.90.0/24
65.55.94.0/25
70.37.151.128/25
94.245.112.0/27
94.245.112.10/31
104.47.0.0/17
111.221.112.0/21
111.221.23.128/25
111.221.26.0/27
111.221.66.0/25
111.221.69.128/25
157.55.0.192/26
157.55.11.0/25
157.55.1.128/26
157.55.157.128/25
157.55.2.0/25
157.55.225.0/25
157.55.49.0/25
157.55.61.0/24
157.55.9.128/25
157.56.232.0/21
157.56.240.0/20
157.56.24.0/25
157.56.248.0/21
207.46.116.128/29
207.46.117.0/24
207.46.132.128/27
207.46.198.0/25
207.46.200.0/27
207.46.4.128/25
207.46.50.192/26
207.46.50.224
207.46.58.128/25
207.68.169.173/30
207.68.176.0/26
207.68.176.96/27
213.199.161.128/27
213.199.177.0/26

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Transparency is key... Here is a perfect example.. M3AAWG is coming.. time to take a st

[Ángel via mailop]

On 2023-05-30 at 15:13 -0700, Michael Peddemors wrote:
> At least mailgun.us has transparent whois..
>(oops, careful, they might have forgotten to hide that one)

.us tld does not allow the use of anonymous whois services.

Still, it's possible that their registrar enabled the anonymous option
automatically for them on the other tlds.


On 2023-05-31 at 13:21 +, Mike Hillyer via mailop wrote:
> > I know that whois is a lost cause, and I still believe that methods
> > for identifying the real controlling entities of domains would help
> > quite a bit in reducing unwanted e-mail spam.
> 
> I agree, but the reality of the matter is that even if mailgun.co and
> mailgun.net had matching org information in the whois for
> mailgun.com, that would still not prove a connection, only that
> whomever registered those domains put in the same information that
> was found in the mailgun.com whois record.

A registrant with a @mailgun.com would help, _assuming_ the registrar
verified the email provided by their client. It would be much better if
they pointed to nameservers like ns1.mailgun.com, which would provide a
much clear link.

On 2023-05-31 at 01:18 +0200, Sebastian Nielsen wrote:
> You can still find their details on their official website 
> https://www.mailgun.com/contact/

Do note that for the other domains, we get either a timeout (mailgun.co
& mailgun.us) or a 503 (mailgun.net)

Plus, even when secondary domains works, I find very few sites do the
Right Thing™ and link to a page like e.g. 
https://mailgun.com/our-domains where they link to their secondary
domains from the main one.



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF record?

[Ángel via mailop]

On 2023-05-26 at 13:16 -0500, Scott Mutter via mailop wrote:
> If you ask me - a better solution would be to do away with forwarding
> completely and incorporate POP checks, like Gmail does.  This
> alleviates all of the issues with forwarding mail in relation to SPF
> and DKIM.
> 
> But I know that stance is wildly unpopular since it breaks the "it
> used to work that way" narrative.  But at some point you add so much
> to a system that it becomes so bloated and overloaded that nothing
> can be accomplished.  The more simple a system is the more efficient
> it is going to be.  Outside of external mail server forwarders, a
> properly constructed SPF record can go a long, long way towards
> alleviating the spam problem.  How much is it worth to keep external
> forwarders working at the cost of spam prevention?  If forwarding
> mail is so important, can a better system for handling forwarded mail
> be developed?  I'm just not sure if the answer is to continue to add
> systems and directives to email to solve all of this.

There is a very simple solution, which is to let the user configure in
the receiving system: "I will be forwarding emails to this account from
", or "from " (automatically using the spf and/or
dkim of that domain).
If you are forwarding, the forwarding server is part of your email
infrastructure, it is to be trusted. It makes no sense to check SPF on
the IP of the MTA you have configured should be forwarding to .
Such server would then be in a privileged position to impersonate other
servers, but so could it do already through the forwarded account 
(one might want to require as well a header such as Delivered-to:
showing it went through the forwarded mailbox, to avoid granting extra
rights to other users with a mailbox on the forwarder).

So why isn't this used? Basically, lack of implementation at the
receiver side. If you run your own receiver MTA it's trivial to do, but
if the receiver account is run by a third-party you usually have no
option to configure that, which is exactly what would be needed.


Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Massive botnet going off today?

[Ángel via mailop]

On 2023-05-13 at 14:09 -0500, Jarland Donnell wrote:
> Curious if anyone else is seeing an event similar to this. Here's the
> logs of 1 hour on one of our servers, for what I propose to be a
> botnet: https://clbin.com/4khRA
> I'm leaving the recipient domains in it because they're not actually
> customer domains. Either they used to be, or they've had their MX
> pointed to us maliciously. I can't accurately say at the moment.
> Whatever is happening in these logs, it looks fairly consistent, and
> quite distributed. What I can't figure out yet, and I'm hoping
> responses or lack thereof from others will shed light on, is whether
> or not this is a targeted attack against our infrastructure or simply
> a large scale event that we're all seeing.

I see a few of those ips and, while not exactly new, there's an uptick
today. Messages seem a mixture, though: open server scans, I-have-
hacked-your-mail, Chinese text...

I doubt it is a targeted attack.


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Yahoo: SOA record per subdomain required?!

[Ángel via mailop]

On 2023-05-06 at 18:44 +0200, Christian Seitz via mailop wrote:
> If I am not wrong a DNS zone can only have a single SOA record. Yahoo
> requests 
> an SOA record per subdomain. That does not make any sense to me. We
> would have 
> to create one DNS zone per subdomain, but that's not how DNS is
> designed.
> 
> Am I completely wrong? What did I miss? Is this a mistake somebody
> who doesn't 
> know much about DNS defined as a requirement or is this just another
> "we are 
> big so we can request whatever we want and whatever makes your life
> hard" thing?

You could probably do some hackish delegation to get a SOA per
subdomain, but such requirement makes no sense. First, if they really
wanted to restrict email domains they accept to the ones that are
registered, rather than looking for a SOA they should be using the PSL,
where in-berlin.de has been for years [1]. And second, such policy
would still be broken. While email addresses _generally_ use the
primary domain, email addresses not on a second level domain have been
used for as long as there have been subdomains. RFC 5321 itself
contains an example of that, although references to such usage can be
found many years back (e.g. RFC 974).
It is relatively common to find that pattern of "subdomain emails" in
Universities, with email domains linked to the different departments.
It is also very common to have "alumni emails" that use a subdomain of
the main university domain [2,3,4,5]

None of those would now be able to email yahoo accounts, apparently. I
find it hard to believe that they may have added such restriction on
purpose. It may be that a check inadvertently added a dependency on th
domain part of the email address having a SOA record. Or even that
their statement that they now require a SOA was actually wrong and your
issue slightly different.

There are several Yahoo people on the list. I'm sure they will
investigate what's really going on.


Regards



1- https://github.com/publicsuffix/list/pull/711
2- https://alumni.stanford.edu/perks/email/
3- https://alumniemail.ud.purdue.edu/
4- https://www.alumni.columbia.edu/content/alumni-email
5- 
https://www.thecrimson.com/article/2023/5/5/haa-retains-alumni-emails/


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mailing Lists and domains with DMARC reject

[Ángel via mailop]

On 2023-03-08 at 11:24 +0100, Alessandro Vesely wrote:
> On Tue 07/Mar/2023 20:02:48 +0100 Slavko wrote:
> > 
> > > Why do you sign Content-Type: since you know it is going to be
> > > changed?
> > 
> > Do you mean exactly me, or it was generic question? If you mean me:
> > 
> > Do you want change the text/plain message, eg. to multipart/alternative
> > with text/html appended? Of course, in my case that change will invalidate
> > body signature too (as i sign whole body), but anyway, it constructs core
> > of message, thus (IMO) fulfill RFC.
> 
> Yes, I meant you, since you (are among the ones who) do it.
> 
> The change to multipart can only happen using the deprecated l=.  It allows 
> to 
> completely replace the body appearance.  As you don't use l=, the only added 
> protection is against an improbable collision between the original bh= and 
> the 
> hash of the modified body.

There are more ways to change a Content-type for abuse.

Suppose there is a web form that is expected to send a plain text message 
saying:

"Hello Alessandro

Thanks for registering on example.com, please click the following link to 
validate
your account: https://example.com/register...;

These kind of forms are already abused by using "names" such as "buy our viagra
at great price on http://spamurl.com;
The "I received a scam letter from Paypal" thread a few months ago is also based
on the same concept.

Now, let's suppose that email is DKIM-signed but the Content-type: text/plain 
header
is not. And the form is filled out by «Bobby * { color: white; 
background-color:
white; } .phish * { color: black}Important 
notification from your bank
Your password has expired. Please https://phishing.com;>Renew it 
here»

and attacker changes the Content-type from text/plain to text/html...


Another venue would be changing the charset to utf-7 This was a common
way of bypassing XSS filters on browsers. It is now unsupported by all
browsers, and forbidden by the spec [1]. I don't know if there is any
MUA which allows that (or even used to support it)


Determining which headers to sign (or not to sign) is complex, brittle
and reasons for that unintuitive and not well-known. A reference
document that provided guidance (if not even a direct recipe) would
surely be helpful to the email community.



1- 
https://html.spec.whatwg.org/multipage/parsing.html#character-encodings
older versions were even more explicit that UTF-7 must not be used 
https://github.com/whatwg/html/commit/a73180679a40fce96b8e8fb6dfa5815a9bce30eb#diff-41cf6794ba4200b839c53531555f0f3998df4cbb01a4d5cb0b94e3ca5e23947dL14674


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Ángel via mailop]

On 2023-03-04 at 01:37 +0100, Tobias Fiebig via mailop wrote:
Heho,
> 
> On Fri, 2023-03-03 at 17:02 +0100, Ángel via mailop wrote:
> > Note you could use a  > for
> > a refresh-every-10-seconds functionality. (meta refresh could be
> > blocked as well, though)
> Briefly considered that; However, contrary to JS (which is often
> ignored by screenreaders) the HTML manual put a warning marker on
> that
> in terms of accessibility. So i decided to skip on that.

I suspect it wouldn't really matter, given the only point of that page
is to get periodically reloaded until content appears. I don't really
mind either way, though. It was just a comment


> > I was kinda surprised that whitespace was allowed here in
> > javascript,
> > btw: “window .location.reload();”
> 
> "ups"; Fix is in staging (along with a better description for reverse
> DNS being unsigned, making clear that signing that is more in the
> 'because we can' realm and "some _theoretical_ attacks".

Heh, it turns out that actually works, so not a big deal :-)


Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Does gmail accept unicode character in From domain? I don't think so

[Ángel via mailop]

On 2023-03-03 at 09:37 -0700, Alex Burch via mailop wrote:
> We are an ESP and we have a lot of customers who send with characters
> like ü or á, usually in the local part but occasionally in the
> domain. I think if we converted all from addresses to pure ascii
> punycode, we'd solve our problems rather than trying to keep them
> unicode and rely on SMTPUTF8 working. I see Yahoo does not even offer
> SMTPUTF8
> 
> Thanks,
> Alex

If Yahoo does not support SMTPUTF8, that points to the provided EAI
address being invalid for that domain.



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New member, trying to bring our mail server inline.

[Ángel via mailop]

On 2023-03-03 at 17:55 +, Laura Atkins via mailop wrote:
> The message he sent to mailop had the selector I used and is also
> failing DKIM. 
> 
> laura 

No, sorry.

I am afraid you seem to have mistyped it.

DKIM-Signature: v=1; a=rsa-sha256; d=warwickri.gov; s=1; c=relaxed/relaxed;
 t=1677852725; h=from:subject:to:date:message-id;
 bh=cA/OIM8ysmjT9eAjZb7DPsvTZ2Serh4Gqwja8FC9VCQ=;
 b=DxJYATfR...

The selector is 1, which is on the dns

$ dig 1._domainkey.warwickri.gov -t txt +short
"v=DKIM1; k=rsa; 
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiToJ+OXb2Kabo7KiaprSdazfCFe+iZLli/uHRzWtQA0QUeXttBSkUhbH2vjXnmj2dLy+x2+b8Wwm/tCFYR1ujOSifGPFTMaayFjDifgKol8w+rGYhwErgULuL3FNzaDtubEuGkJH6ciFBIE"
 
"KEw0nV+B6XKZvkjUGnUXmZAcWOWRF/Po1gASwV//TStIjuFwzRoFUVrzXPPlVUhhRGn99sgkK3Z0Tq3fLN8hKP9Dww6A8G/O7j5wfx/V3TXbzkkKf79OrSLQXCoyDFtwqO+8RBVzbayHHiit+GdeEiZi8dIssqPgW1DZVLIPFGJ2hpPGZV1/vsuxBEX6MPGJY2kBpYQIDAQAB"

(it was already several hours ago, I had checked this at the time of my
reply)


you seem to have used as selector 1677852725, which is the value for the 
Signature Timestamp (t=1677852725)


Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Ángel via mailop]

On 2023-02-27 at 12:59 +0100, Tobias Fiebig via mailop wrote:
> Please note that setting up the tests (as we have to configure vhosts
> for some MTA-STS cases etc.) takes some time on our site. The test-
> site should periodically reload and provide the status. As we use JS
> for that part, please reload it manually every few minutes if you
> block JS.

Note you could use a https://list.mailop.org/listinfo/mailop

Re: [mailop] New member, trying to bring our mail server inline.

[Ángel via mailop]

On 2023-03-03 at 14:12 +, Salvatore Jr Walter P via mailop wrote:
> We are in the final stages of migrating our exchange server from 2013
> to 2019.
> I found out we had no SPF, DMARC, DKIM etc setup on our domains.
>  
> Trying to get us setup properly and have SPF and DMARC working, DKIM
> is another story.
> Setup on the server, sent the key to our ISP for the DNS to be added.
> Headers show the signature is being included.
>  
> DKIM-Signature: v=1; a=rsa-sha256; d=redacted.gov; s=1;
> c=relaxed/relaxed;
> t=1677851456; h=from:subject:to:date:message-id;(rest of key)
>  
>  
> Also from the headers:
>  
> Authentication-Results: inbound.redacted.net;
>  spf=pass smtp.mailfrom=redacted@ redacted.gov;
>  dkim=fail header.d= redacted.gov;
>  dmarc=pass (policy=none; pct=100; status=pass);
>  arc=none
>  
> Any suggestion where to go from here? We are having all emails
> blocked by AT, no idea why so trying to get all our ducks in a row
> and make sure we are doing everything the “right” way.

Hello Salvatore

The Authentication-Results header is added by the receiving
server inbound.redacted.net, noting what it found (it considers the
email not passing DKIM).

Is warwickri.gov the domain you are setting up?
Could you share a full, unredacted email with headers? (e.g. a test
email sent to a freemail account you own)

Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [FEEDBACK REQUEST] Allowing Messages with Bcc to travel the internet.

[Ángel via mailop]

On 2023-01-23 at 09:53 +0100, Alessandro Vesely wrote:
> On Sun 22/Jan/2023 23:23:06 +0100 Ángel wrote:
> > I should note that the user-is-in-bcc approach could be helpful wrt
> > dkim-replay attacks, since the attacker-controlled account they
> > used to
> > receive the dkim-signed spam mail would be present in the bcc
> > header
> > (and thus stand out). It would be less conspicuous to include
> > themselves in To: or Cc:
> > 
> > (This would obviously require the DKIM header to include bcc, which
> > for
> > instance gmail is not doing)
> 
> Exactly.  But can we trust intermediate MTAs to not remove Bcc:?

Well, in that case they would be as if not signed.
Which might not matter too much if the entity that "helpfully" removed
it did so after DKIM validation.


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [FEEDBACK REQUEST] Allowing Messages with Bcc to travel the internet.

[Ángel via mailop]

On 2023-01-18 at 16:52 -0800, Brandon Long wrote:
> Note that Gmail implements 
> https://www.rfc-editor.org/rfc/rfc5322#section-3.6.3 option 2, notably:
>In the second
> attac   case, recipients specified in the "To:" and "Cc:" lines each are sent
>a copy of the message with the "Bcc:" line removed as above, but the
>recipients on the "Bcc:" line get a separate copy of the message
>containing a "Bcc:" line.  (When there are multiple recipient
>addresses in the "Bcc:" field, some implementations actually send a
>separate copy of the message to each recipient with a "Bcc:"
>containing only the address of that particular recipient.
> 
> Gmail actually does the part in the parenthesis, each individual bcc 
> recipient will get a message with themselves in the bcc
> (or rather, the single email address that the message was sent to that 
> eventually reached them)

I should note that the user-is-in-bcc approach could be helpful wrt
dkim-replay attacks, since the attacker-controlled account they used to
receive the dkim-signed spam mail would be present in the bcc header
(and thus stand out). It would be less conspicuous to include
themselves in To: or Cc:

(This would obviously require the DKIM header to include bcc, which for
instance gmail is not doing)


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Using cloud hosts for MX (not SMTP)

[Ángel via mailop]

On 2023-01-17 at 20:34 -0600, Alberto Abrao wrote:
> Still, it generates an error message to the sender. I was looking to 
> "split" my server, having the MX (inbound) at a cloud provider (OVH), 
> and keeping outbound SMTP on the IP provided by my ISP.
> 
> I see many posts saying that e-mails from cloud providers such as OVH 
> are blocked outright by many. That had me wondering if it's a good idea 
> to proceed with this plan, as I may not be able to receive messages from 
> senders under these operators.
> 
> That'd assume the block is inbound and outbound, instead of 
> inbound-only. Is that the case?
> 
> One more thing, would a set up like this interfere with my "score", so 
> to speak?

Yes, you can do that. No, I don't expect any problem. (But you could
use someone other than OVH if you prefer)
Still, if you have a server locally continuously up, and you have
already done the change, I don't see why you want to modify the
existing setup. Are you expecting more moves?

You could as well set two MX, one at OVH and another at the "real"
server, up to you which one with higher priority.


Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] new exploit?

[Ángel via mailop]

On 2023-01-14 at 17:33 +0200, Mary wrote:
> Thank you, I'll take a closer look, because Shellshock implies that
> somehow the SMTPD executes a bash script, which I find highly
> unlikely. That is why I thought they are trying to exploit something
> further down the pipeline (Logstash, Prometheus, etc).

The command is a normal shellshock payload. It would seems to target
the case where the mail server or an MDA sets an environment variable
with the MAIL FROM value and then executes a command through bash.
This could be the execution of a milter, a procmail... courier also
extensively uses environment variables between their programs.
The most difficult part is that a bash shell is executed... being an
old version which not patched for this 2014 vulnerability.


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Simple mailing list expander program for aliases files?

[Ángel via mailop]

On 2023-01-10 at 13:59 -0800, Dan Mahoney wrote:
> The way postfix handles these aliases, is that it preserves the
> original envelope sender and recipient (which we don’t want anyway),
> and o365 is rejecting on that envelope sender/recipient (that it’s
> not allowed to deliver to our internal envelope recipient, which is
> not unreasonable, but still surprising we haven’t hit it before.

Postfix is keeping the alias as envelope recipient?? Or just in the To:
header?

I think O365 is simply seeing that the sender is a mail it should be
handling itself but the mail comes from outside and rejects it.

I'm sure it's possible to configure it to allow that. I don't know how
to do that, though. Marking the sender and external and the postfix IP
as trusted, probably.

Regards




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [External] Re: verizon email-to-text gateway mail deferred evening and night

[Ángel via mailop]

On 2023-01-08 at 18:21 +, Andrew C Aitchison via mailop wrote:
> Once upon a time SMS had a reputation for stronger security and
> privacy than email. I don't know how much that reputation was
> or is deserved.


Well, a SMS:
- Is not encrypted at any point
- Could be dropped with no notification (bounce) to the sender
- The sender can be spoofed. And you don't even have source ips to
check its source.


On the other hand, email has drawbacks as well. It might be "more
secure and private" in case some anti-wiretapping law applies to sms
but not emails.
It might end up being more private in that perhaps your email provider
your reads your emails^W^W^W processes your emails for your benefit but
didn't read your SMS.
Being a separate type of network, it will use quite different systems,
for better or worse.

I think the reason many providers use SMS reminders for appointments
(other than inertia) is because that's a lower common denominator. If
you have a mobile phone, even a dumb one, you are able to receive SMS.
Which is quite different than saying that you will actually *read* them
or *able* to. There are many old people with no email but that have a
mobile phone. Often, they don't know how to read their received SMS,
either.




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is there a way to unsubscribe from Nextdoor emails?

[Ángel via mailop]

On 2022-12-19 at 13:49 -0700, Grant Taylor wrote:
> On 12/19/22 8:21 AM, Daniele Nicolodi wrote:
> > it seems that Nextdoor recently went on a mission to expand their
> > user base and are mailing former users with whatever crap.
> 
> I assume that their excuse for why the contact is CAN-SPAM compliant
> is because of the "established business relationship".
> 
> I wonder how long before the "established business relationship"
> should be considered to be expired.  I'm guessing somewhere between
> one and five years.
> 
> If you've not had any interaction in that time, there is no longer
> an established business relationship.


Let's assume their initial emails were compliant due to the
"established business relationship" (even though the account is
deleted, which makes it really dubious, to say the least)

But, (IMHNAL) the non-working unsubscribe link makes it a clear
violation of the act:

> (A) In general.--It is unlawful for any person to 
> initiate the transmission to a protected computer of a 
> commercial electronic mail message that does not contain 
> a functioning return electronic mail address or other 
> Internet-based mechanism, clearly and conspicuously 
> displayed, that--
>   (i) a recipient may use to submit, in a manner 
>   specified in the message, a reply electronic mail 
>   message or other form of Internet-based 
>   communication requesting not to receive future 
>   commercial electronic mail messages from that 
>   sender at the electronic mail address where the 
>   message was received


This is the kind of case that in other countries would result in a
straightforward case with the regulator. I'm not that familiar with the
US, though.


I guess the unsubscribe link is not working because it is trying to
store the preference in the missing account. But had they deleted the
email address along the account, they wouldn't face such problem...




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF (and other email security protocols) Survey

[Ángel via mailop]

On 2022-11-23 at 13:54 +0100, Tobias Fiebig wrote:
> But I am currently stuck at 'getting a /23', which is surprisingly
> difficult without $30k to blow... so if one of you has some spare v4,
> I wouldn't say no. ;-)

IPv4 addresses are scarce now, but universities and NRENs were assigned
large ranges back in the day (with lots of unused IP space).
Given they are the ones that would primarily benefit from your
measurement AS, I would ask them to lend you some ranges.

Kind regardxs


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Partial issues forwarding mails to gmail.com

[Ángel via mailop]

On 2022-11-24 at 17:20 +0100, Martin Flygenring via mailop wrote:
> Is anyone else seeing similar issues when forwarding mails from 
> gmail.com, back to other addresses at gmail.com?

Yes, it seems nitpicky again.
I recently received a report of one of those failing. Which are a pain
to figure out if it's actually an error in the forwarding server, that
might be unexpectedly breaking the DKIM signature... or not at all.

Gmail seems to have periods which are fine, and then some months when
they reject a lot more.
I can't but think that Black Friday is probably related. PErhaps they
are receiving more spam that usual, which makes their filters to be
more aggressive; or perhaps we are even receiving more spam that gets
forwarded to them.

Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Partial issues forwarding mails to gmail.com

[Ángel via mailop]

On 2022-11-24 at 15:28 -0800, Michael Peddemors wrote:
> Every modern email client can check multiple email accounts.
> The day when remote forwarding was a necessity has now passed, and
> now with things like SPF and other email tests, forwarding simply
> breaks..

When trying to get some user in the past to do that, I have been told
that the mail client they want to use is... Gmail.
One which doesn't support fetching mail from an IMAP account.

(Also, with no clear explanation on why only that "client" serves their
workflow [1], so it's not as if we could replace it by adding an extra
feature, even if we had the means to d that)


1- https://xkcd.com/1172/


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Partial issues forwarding mails to gmail.com

[Ángel via mailop]

On 2022-11-25 at 00:10 -0500, Dave Anderson wrote:
> And even when it's possible it's not always desirable. An
> organization 
> I'm involved with has many @ email aliases
> which forward to the person(s) responsible for those functions. This
> is convenient for people who need to communicate with us since they
> don't have to hunt for the responsible person(s) and their email
> address(es), and is convenient for us since we can easily change the
> forwarding when who is responsible for a function changes.
> 
>   Dave

Forwarding is not the problem. The problem is that the forwardee's
server is not aware of the forwarded, and treats it as first-party
email.
I'd say that forwarding such as the one you describe is done internally
every day at lots of organisations. And it doesn't cause any problem,
since the original and final server are "the same" (in the same
organizational domain) and there is a trust relationship.

However, if they are handled by distinct organisations, say 
j...@freebsd.org to j...@example.net, jdoe should get example.net
configured so that freebsd,org MTA is treated as a trusted hop [whenreceiving 
email for j...@example.net].

When people configure forwarding only at the sending side, the setup is
incomplete, and the result may or may not work (or, as it oten happens,
work only sometimes), since from example.net point of view, the freebsd
MTA is "spoofing everything".

Now, one reason it's not done is that the end users don't know they
should do anything at that side, but another is that most of them use
provders which don't offer such option at all (and generally even
freemails for which they don't have any support),

So it's a semi-broken setup.


(Yes, ARC is presented as a solution, and it could avoid it if the
sealer was trusted, but you would still need to have a way to trust it,
which is largely similar to getting it  configured based on source IP,
or a forwarding DKIM selector)


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Really good paypal phishing email this morning

[Ángel via mailop]

On 2022-11-18 at 11:38 -0800, Ken Simpson wrote:
> Hi Michael,
> 
> I've seen the raw email; it did come from PayPal. PayPal needs to get
> better at recognizing brand images so that this kind of impersonation
> is more difficult on their platform. No doubt they are already
> working on that.
> 
> Ken

I don't think this is really a computer vision problem. The brand is
there in plain text: "Walmart".
The problem is the old "Who is allowed to use name X" ? In this case,
to issue invoices. Only "Walmart Inc.", the american corporation? Also
their subsidieries in other countries? What if I create a company named
"Walmart" in Pretoria, Nicosia or Yakutsk?
What about companies trading as Foo where they actually have a
completely different legal name?

Maybe for internationally protected brands, it would be easier to block
them.
Once they filter that I suspect the next would be for « ꓪΑ1ΜΑꓣŦ », but
one step at a time. Detecting homoglyphs does seem more tractable. 

Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Phishing and 2FA auth

[Ángel via mailop]

On 2022-11-20 at 18:58 +, Slavko via mailop wrote:
> Dňa 20. novembra 2022 17:55:18 UTC používateľ Ken Simpson <
> ksimp...@mailchannels.com> napísal:
> > One-time passwords can always be man-in-the-middle'd, since there's
> > no way
> > for the user to determine whether or not there is someone in the
> > middle
> > snooping their OTP and password. The phishing attack only has to
> > deceive
> > the user into entering their password and their OTP, both of which
> > can then
> > be forwarded to the real login page behind the scenes.
> 
> Now we are back on start (my first message), that OTP solves problem
> only partially -- user doesn't need to take action, as passwords will
> expire soon, often sooner, than would be password changed by user.
> 
> And by this, OTP doesn't solves sending SPAM from leaked passwords
> + OTP as while token is valid, they can misuse victim's account and
> send tons of SPAMs in relative short time. And one still have to
> apply some form of rate limiting...

An OTP would be valid for *seconds*. Maybe even *minutes*. That greatly
reduces the risks of password stealing. Of course, a system could
require an OTP for login, but once the attacker authenticates "live",
the session might end up open at the bad guy browser for months...



> 
> > Hopefully, WebAuthn  gains
> > traction, making passwords irrelevant by allowing devices to
> > maintain a secure authentication key for each website within a
> > trusted execution environment such as Apple's so-called "Secure
> > Enclave."
> 
> Hmm, i am not aware of that and i am not sure, if i want to leave
> browser (or device) to decide if i am logged in or not. As soon or
> latter it will be misused and leave users in middle state -- you will
> not be logged in, but site will be able to identify you.

Webauthn uses a "device" which will provide an authentication _for a
given website_. That should remove the risk of leaking your password to
a fake website, as it would be a different url.

> 

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Things to do on a Sunday, when there is an atmospheric river.. Investigate 'code200 UAB'

[Ángel via mailop]

On 2022-10-30 at 15:17 -0700, Michael Peddemors via mailop wrote:
> Can anyone give insight into this company?
> 
> They have an IMMENSE amount of IP space from PSI/Cogent..
> 
> (Someone might like to look into this from Cogent's end)
> 
> Their website (https://www.code200.global/contact) has no real
> company information, and Google shows a Lithunian company by that
> name with 17 employees.

The website also claim they are based in Lithuania.

Interestingly, these "IT experts" with "clients all over the world",
that provide "dedicated hosting and cloud", chose to make and host
their website with... wix.


>   But almost all of that IP space is active, with either
> PTR 
> naming conventions of code200.global ..
> 
> Oct 30 09:02:51 be msd[3651510]: CONN: 38.79.219.120 -> 25 GeoIP =
> [US] 
> PTR = code200.global OS = Linux 2.2.x-3.x
> Oct 30 09:02:51 be msd[3651510]: HELO command received, args:
> code200.global
> Oct 30 09:02:52 be msd[3651510]: MAIL command received, args: 
> FROM:
> 
> Doing list washing..
> 
> ... or..
> 
> 38.128.158.229x1prd-ol-25ad6o.sourcexnet.com
> 38.128.158.231x1prd-ol-6n0jkp.unsignedstatic.com
> 38.128.158.233x1prd-ol-hf8c87.spaceisstupid.com
> 38.128.158.235x1prd-ol-fc0xdw.marketdatax.com
> 
> They advertise that they are selling internet connections for $19.95
> and hosting, but this doesn't appear to be the case..
> 
> Oct 30 11:46:08 be msd[4182031]: CONN: 149.100.189.246 -> 25 GeoIP = 
> [IT] PTR = prd-ol-5sp9th.froyogogo.com OS = Linux 2.2.x-3.x
> Oct 30 11:46:09 be msd[4182031]: HELO command received, args: 
> prd-ol-5SP9TH.froyogogo.com
> Oct 30 11:46:09 be msd[4182031]: MAIL command received, args: 
> FROM:
> 
> You will recall that name from a while back in out reports..
> 
> This seems to be someone trying to prove they have justification for
> IP space, but this is simply huge swaths of IP space used to slow
> roll list washing it appears..
> 
> Any one else have comments on them?

I have a few hits from them. Being really small, that is noticeable by
itself. They seem to be doing the checks by pairs. At almost the same
time, they check the expected mailbox from one ip address, then a
second ip requests a made up mailbox in the same domain with a random
alphanumeric local part of 13 characters (in order to compare with a
non-existing mailbox, apparently).

Interestingly, they use esmtps for the fake address but smtp (HELO with
no STARTTLS) for the real one.

In one case, the email used was tied to a company, and code200 check
was followed 3 weeks later by a mail from them using salesforce ip
space (they had not sent anything for months). I can only conclude that
they contracted code200 for listwashing.

In addition to PTRs of code200.global, the rdns (performed today) of
the ip addresses they used show:

- prd-ol-XX.maillistclean.com
- prd-ol-XX.froyogogo.com
- prd-ol-XX.megamx.net

where XX are (random?) alphanumeric codes.
(both the HELO name and MAIL FROM domain were code200.global, not the 
prd-ol one)
whois show these ranges to still belong to "Code 200, UAB" on different
US cities.


Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Ángel via mailop]

On 2022-10-19 at 11:37 -0700, Michael Peddemors wrote:
> > I hear your message, but I can't believe the only way out is to dox
> > myself.
> 
> I don't think it is 'doxing' unless you are trying to hide ;)
> 
> I am not going to go into whether operating a service on the internet
> is a 'right' or a 'privelege', but coming into my home sure is..

Well, precisely. Providing an address should be no issue for a company,
but requesting the home address from an individual (and by extension
from their family!) is a whole different matter.

There is a difference between letting the world know where you and your
family live and getting some nasty visitor out of it, but avoiding the
former is generally a great way for the later.

Maybe they are stating to only accept email from commercial servers as
a (light) attempt to avoid GDPR issues arising from individuals.

I would be tempted to "paywall" such details from that "Impressum"
behind an eIDAS login, that *their* data will be logged and they will
be considered liable for any misuse or illegal activity that happens
linked to the address they are requesting.

Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Ángel via mailop]

On 2022-10-19 at 21:28 +0200, Bernardo Reino via mailop wrote:
> Yup. I have another server for which I have to request whitelisting..
> but it's a bit more difficult because the front page of the domain is
> the webmail (roundcube), so I have to figure out how to inject the
> Impressum there.

Assuming you are using the defualt skin (larry), edit
skins/larry/templates/login.html and add your html link above 
  


Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft 365 send spam via high-risk delivery pool (instead of block it)

[Ángel via mailop]

On 2022-09-29 at 08:19 +0200, Alessio Cecchi wrote:
> if you can identify a message as unwanted why do you have to send it
> anyway? It does not seem to me a positive contribution to the cause
> of a better internet, but only a discharge of responsibility on the
> receiving server.

The tricky question is: How are you sure it's unwanted?

Suppose the body of the email contains a well-known text of a Nigerian
prince scam. Surely that email would be unwanted, right? Except...

What if the email was beng sent to an abuse team to complain that
*they* sent such email?
What if this is someone asking a trusted one whether the deal is real?
...or their reply that it is not?
What if it's a blog / mailing list post when someone sent that?
Or a mail forwarded from a spamtrap?
Or a newsletter alerting from certain scams on the rise?
Not to mention a mailing list such as this one, discussing spam topics.



> In any case, some one know what are the IP address in the "high-risk
> delivery pool" of Microsft 365?


This is a good question. Microsoft throughly documents its use of an
High Risk Delivery Pool... but not which ranges it uses for that.

According to 
https://o365info.com/high-risk-delivery-pool-and-exchange-online-part-9-17/
it would be using 157.56.0.0/15


Regards

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Reject vs spam folders

[Ángel via mailop]

On 2022-09-16 at 20:47 +, Gellner, Oliver wrote:
> I can’t provide real research and I believe as well that 99% is
> exaggerated, but in my experience it’s more likely that a given
> random person is NOT regularly checking his spam folder than he is
> checking it. That‘s why I only vaguely wrote „vast majority“.
> 
> Some years ago an important email was sent to several hundred
> employees. The email was classified as spam and routed into the
> respective spam folders. One day later, about 10% of the recipients
> had moved the email out of their spam folder. Of course the others
> could have read it in the spam folder (and left it there), but it
> seems unlikely that a large amount of users checked their spam
> folder, found the legitimate email, read it, but let it sit in the
> spam folder.  Based on the feedback of the sender a lot of recipients
> weren’t aware about the contents of this email.
> 
> I can’t say whether 10%, 20% or 30% are regularly checking their spam
> folder, but based on my experience it’s the minority.

I think there are multiple types of users. Assuming a "spam folder
style" of tagging spam:
- Some users will check it at least once a day.
- Some will check it regularly but far in between, maybe once a month 
- Some will only look there when really expecting a message not 
- Some will never look there, at all

I would expect different proportions between personal and business
mailboxes. And in the later case if you knew the positions, that
(should) be a factor as well: sales (or, as mentioned, a recruiter)
_should_ check for misclassified mails pretty often, whereas some other
roles  don't even need email access from outside the company.

The type of client used is probably also correlated to the frequency of
checking the spam folder: POP3 users will tend to be in the bottom
places, webmail and other MUA will probably vary, in how they present
the spam folder (assuming it's subscribed!), if there a count is being
included, if the user has custom folders which require scrolling to
view the spam folder…


Maybe some of the big players on the list could share some stats about
the percentage of people of each "kind" they see. I'm sure [some of
them] will be tracking this.


Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] The oligopoly has won.

[Ángel via mailop]

On 2022-09-13 at 11:48 -0700, Luke wrote:
> There's some serious irony throughout this thread. Out of one side of
> our mouths we despise "oligopolies" and service providers who get too
> big to block or, conversely, too big to care about their own spam
> footprint. And out of the other side of our mouths we are begging for
> security and privacy regulations that essentially make it impossible
> for anyone other than a massive oligopoly to thrive. The cost of
> adhering to the latest regulation-of-the-day is prohibitive to the
> small operator's (sender or receiver) success. This is, of course, by
> design. But it's really interesting to observe how confusing the
> debate is when both sides lack anything resembling first principles.
> Everything we do prevents the marketplace of ideas from actually
> functioning and finding a solution. Then we feign outrage and harm
> and confusion about why we don't have a viable solution to these
> relatively innocuous problems. We have a large group of well-intended 
> people who think they are spending 100% of their focus-time solving
> this problem. When, in fact, we have a large group of people spending
> half their time fixing the problem and half their time
> unintentionally (and unknowingly) making it worse.
> 
> Luke

Excuse my ignorance Luke, but what is it that makes so prohibitive? I
am not aware of complex security and privacy regulations. In fact most
of them should be common sense. Of course, you would still need a
lawyer to ensure all checkboxes are ticked, but I don't think there are
things complex to implement, really.
Am I missing something?

Kind regards

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] gmail rejecting for invalid SPF/DKIM when there isn't any?

[Ángel via mailop]

On 2022-08-27 at 17:09 -0500, Darrell Budic wrote:
> Anyone else seeing this? Customer of mine just got some bounces from
> gmail for invalid SPF/DKIM. He doesn’t have either, so I’m not sure
> what this is about?
> 
> Mind you, I did send him to setup a valid SPF entry, and
> authentication is good, but this seems like a misleading error
> message...

When querying the SPF record, I only get it about 50% of times:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 637
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1460
;; QUESTION SECTION:
;musichael.com. IN  TXT

;; ANSWER SECTION:
musichael.com.  3600IN  TXT "v=spf1 ip4:204.130.133.0/26 
-all"

vs

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3637
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;musichael.com. IN  TXT

;; AUTHORITY SECTION:
musichael.com.  600 IN  SOA ns1.yourhostingaccount.com. 
admin.yourhostingaccount.com. 2012080973 10800 3600 604800 3600


I'm not sure what's going on, since I get the record both from
ns1.mydomain.com and ns2.mydomain.com when pointing directly to them, It could 
be some dns caching somewhere.

But there are definitely some shenanigans going on with your SPF
record, it's not Google.



Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] EC certs in MTA - MTA TLS

[Ángel via mailop]

On 2022-08-21 at 15:18 -0500, Chris Adams wrote:
> Also, I believe you can offer both RSA and EC certs, so shouldn't be
> a negative to getting an EC cert (you just need to have RSA too).

How would you do that?

You could use different certificates on different interfaces, based on
the hostname the client is connecting to (assuming they support SNI),
or even the client IP address.

But I don't think you could easily vary the type of certificate you
present to the client.
Technically, the ClientHello message shal be sent before the
ServerHello, so I guess you could predict, based on the ciphersuites
presented, if the client is likely to support an EC cert and present an
EC or RSA certificate based on that, but I don't know of a SSL library
which allows you to do that.

.
Best regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] I understand less and less why I accept any mail at all from Sendgrid

[Ángel via mailop]

On 2022-08-13 at 18:46 -0400, John Levine wrote:
> Subject: IP address blacklisted(Child Pornography Act 1996 violated)
> 
> Hello,
> 
> We have found instances of child pornography accessed from your IP
> address. This is a punishable offence under The Child Pornography
> Prevention Act of 1996 . For now we are blacklisting your IP address
> and if there is any further action from Microsoft you will be
> informed via email.
> 
> If this was not you and you suspect potential hack or id theft
> contact Microsoft Support Team at +1-808-460-7701
> 
> Microsoft Support
> +1-808-460-7701
> 
> support

This is probably "just" a tech support scam. I have seen others on a
similar theme, but claiming to be sent from the national police and
asking you to provide your allegations to an email address. Presumably
in order to get replies of those gullible enough to believe it and pay
a "fine" and, one would guess, hunting in case someone admitted
something worth being extorted about.

Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail Dynamic Email / Impact on Email Ecosystem

[Ángel via mailop]

On 2022-08-13 at 03:17 +0200, Tobias Fiebig wrote:
> Heho,
> 
> > Brandon Long via mailop
> > https://developers.google.com/gmail/ampemail is the Google developer 
> > information about dynamic email, that link was about controlling the 
> > content with Google Workspace.
> Thanks for sharing, this has some rather interesting examples. Do I
> need to be specially vetted to send AMP email, or could I--as long as
> it is compliant to the standard--send one myself, i.e., without being
> a registered newsletter sender? The AMP page is somewhat unclear
> there.

You need to be registered with Google to send AMP email to other users
of Google service.[1] But you can configure the receiving account to
enable amp email from a certain sender.[2] In fact,you are expected to
use that for testing.

Regards


1- https://developers.google.com/gmail/ampemail/register
2- https://developers.google.com/gmail/ampemail/testing-dynamic-email



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail Dynamic Email / Impact on Email Ecosystem

[Ángel via mailop]

On 2022-08-11 at 10:55 +, Gellner, Oliver wrote:
> In other MUAs they display like normal emails, Id expect that Googles
> dynamic emails behave the same way.

They seem to be a text/x-amp-html, and require a text/html or
text/plain fallback, so other clients would simply use the fallback.
At least the design seems robust, enforcing that this new standard is s
trictly followed.

Like Tobias, I also found about them really recently. I am not really
convinced about them so far. Not the way Google implemented them, but
the underlying concept.
I understand why an email that is kept up-to-date can be thought to
make sense in some cases, but a "dynamic email" breaks the concept of
an email that we have been using for the last fifty years.

An email archive used to be similar to an archived physical letter in
that it is immutable. You could go back and read the same content you
viewed a few days ago. With this, you could find it now contains
something different. Even two people receiving the same email could get
shown different content.

This was already possible to some extent by using external images, but
only as a subproduct.

This attempt is a big change on the basics of email, and only time will
tell us if it changes things radically, or ends up discarded.


Regards



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

[Ángel via mailop]

On 2022-07-22 at 16:20 -0400, Luis E. Muñoz wrote:
> Going back to the example of an ESP, does the hash of the email
> address equate the email address as per GDPR?

IANAL, but...

GDPR is all about being able to identify someone, even if that would
require help from someone else.

So, the email 
  Ursula.vonderLeyen@ec.europa.eｕ 
would probably be considering as identifying a person

whereas press@ec.europa.eｕ would not.

And collecting ec-president@ec.europa.eｕ in 2022, despite being a role
account, would still be identifiable.

Looking up the single person being president of the European Commission
in 2022 is available to anyone, but employee1...@example.com, requiring
a subpoena to Example.com HR to find who the employee 1234 is, would
still be 'personal data'.


Now, if we instead have the hash bbbaa1af939a01d0e22286c63827d936
If you can hash multiple emails until finding who that refers to, then
it's equivalent to the email. But if it is also the hash of other email
addresses jsmith@hotmail.example and janedoe@gmail.example then itwould be 
considered to be anonymized.

Thus the point would be if the hash you used has enough collisions that
the result does not allow identifying a natural person.


Do note that even if it turns out to be considered personal data, you
may still be allowed to process it. For example maintaining a list of 
do-not-sign-up list of spammers could be construed on the legitimate interest 
of ensuring network and information security. Or user consent to be included 
into a suppression list.


In my opinion the case of MSBL's EBL is much simpler than all the above
considerations, since IMHO the dropboxes used in fraud spam do not
identify a natural person, and so they are should not be a concern.

Best regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Ángel via mailop]

On 2022-06-19 at 12:22 -0700, Dave Crocker wrote:
> On 6/18/2022 3:40 PM, Noel Butler via mailop wrote:
> 
> > I was a very early (even in testing) user of SPF,  It's rather commical 
> > reading these FUD sayers about SPF and mailing lists, it has never been 
> > a problem with mailing lists, not using mailman nor its more common 
> > predecessor majordomo, and I've never noticed anything wrong with qmail 
> > users ezmlm.
> 
> This establishes the context of SPF and mailing lists.  Hence my
> question.
> 
> Also, the above text makes the incorrect assertion that this isn't a 
> problem when a message passes through a mailing list.  However, SPF 
> breaks even with basic MTA relaying, nevermind mailing lists -- unless 
> the MTA is registered in the SPF record.  The delivery/re-post behavior 
> of mailing lists not only breaks SPF but almost always also breaks DKIM. 
>   (This latter point is what motivated ARC.)

Mailing lists must use their own envelope from when injecting list
messages to the subscribers.
They could be a general one, per list, per subscriber or even per
recipient and email, but they must do so in order to process bounces
and disable delivery / unsubscribe users. I don't think you should
consider a mailing list a system without this feature.

Additionally, if it was to use the original envelope when sending to
each subscriber, the author of the message would receive all delivery
errors (no such account, mailbox full…) encountered by every
subscriber, which they are not the ones to solve (unless they are the
mailing list admins as well). Plus, they would learn about other
subscribers (those with delivery errors) in what could be considered a
small information leak (depending on the list).


Thus, mailing lists already did fine with SPF and I don't think they
required any change.


Do note that SPF only cares about the envelope, it doesn't require the
RFC821 envelope to be aligned with the RFC822 headers inside DATA.
Passing DMARC is a different problem.


Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Ángel via mailop]

On 2022-06-17 at 09:12 +0200, Cyril - ImprovMX wrote:
> 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?

That's the crux of ARC, and IMHO the reason it still hasn't taken off
after all these years. It requires the sealer to be trusted, and
there's not a good solution of deciding which entities to trust as
signers.

The theory is that if someone is a liar, other people (hosts) wouldn't
believe them. Surely, ML could learn that certain seals are a bad sign,
but it still doesn't help that much on who to trust automatically to
override a failing DMARC check.


The bit you are missing from Microsoft rollout is that the tenant must:
> Add the intermediary’s domain to the ARC trusted sealers list
> (Microsoft 365 Defender portal > ARC trusted sealers).

So, if the O365 admins said "Yes, we are using h4ck3r-domain.example
and blindly trust their DMARC checks", their ARC seal would override
the check performed downstream by O365 platform. Otherwise, they would
be ignored.

Best regards

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best practice for mailing list servers

[Ángel via mailop]

On 2022-06-15 at 23:53 +0200, Axel Rau wrote:
> 
> 
> > Am 15.06.2022 um 20:42 schrieb Ken O'Driscoll:
> > 
> > This is incorrect. The return-path is the address used by receiving
> > the MTA to send bounce messages to when the recipient's 5322.From
> > is unreachable for whatever reason.
> 
> Yes. But the point was "do I need a MX to receive these bounce
> messages?“
> My listservers return-path address is reachable all the time w/o MX
> and occasionally gets one.
> 
> Axel

There is a fallback of connecting to the A record on port 25 if there
is no MX. However, I would recommend to include a proper MX record and
not rely on the "implicit MX rule" unless you have no other option.
An email address whose domain doesn't have a MX record is suspicious at
least. And obviously, add a SPF record to that domain as well.

Regards



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Email System Testing Methodologies?

[Ángel via mailop]

On 2022-06-13 at 18:18 +0200, Slavko wrote:
> There is better tool from Vienna
> University, which reports SPF, DKIM (both rsa & ed), DMARC and ARC
> results in similar simple txt response:
> 
> e...@univie.ac.at
> 
> regards

On this line, there is the MECSA tool
https://mecsa.jrc.ec.europa.eu/

Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Verizon vtext service, not including a Content-Disposition header on images?

[Ángel via mailop]

On 2022-05-05 at 13:09 -0700, Michael Peddemors wrote:
> Now, curious as to people's perspective on the requirement to use that 
> header.. some email clients will render it even though that header is 
> missing, and other ones absolutely will not render it, or see it as a 
> valid attachment.
> 
> Comments?

Going to the source of truth, 
https://datatracker.ietf.org/doc/html/rfc2183#section-2 says:

>Content-Disposition is an optional header field. In its absence, the
>MUA may use whatever presentation method it deems suitable.



As Verizon probably wants their emailed MMS to be shown in a certain
way, it makes sense they consider a bug if their gateway failed to
include that header, you generally want a consistent rendering on all
devices. Not the end of the world IMHO, though. (Still, good they moved
to fix their issues)

Cheers



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Ángel via mailop]

On 2022-04-29 at 10:28 -0700, Brandon Long wrote:
> There have been other reports on this list of Gmail requiring
> authenticated email.
> 
> We don't require authenticated email... but we vastly prefer it, and
> that preference has only increased over time.  And the dkim replay
> attacks have meant increasing the scrutiny of messages which are dkim
> authn but not spf authn, which of course can hurt forwarding. 
> Forwarding is getting the short end of the stick in that
> toss up.
> 
> The above rejection isn't for the dkim replay case, of course, it's
> for no authn at all.

Yep. I completely understand it's not authenticated. The problem is,
it's out of our reach to authenticate that third party email. It's the
recipient who wants to receive it.


> SRS style rewriting allows the forwarder to get feedback if the
> forwarding destination address goes away, > and do bounce handling...
> and prevent bounces from going back to the original sender, exposing
> the destination address. There are good reasons to do the rewrite,
> but not as likely for the average procmail user, and having a good
> spam filter that doesn't forward is very important.

We do some hoops here, in that we provide the original envelope to the
forwarded mail server, but it if refuses to accept it, we send the
bounce to the forwarding account, not to the original sender. :)

This not only avoids leaking the information about forwarded accounts,
but also confusing the senders.


>> Gmail guidelines explicitly ask not to rewrite the envelope
sender
> 
> Yes... and gmail forwarding does ;).  Mailing lists do as well.  

Should we then do as-it-does rather than as-it-says? :)
If gmail has changed its stance, messages could be forwarded with a
different envelope sender, but I suspect it wouldn't be happy either,
as it would then show an envelope suspiciously unrelated to the
content.


> > > There's no great solution to this problem. (...) ARC is the
> > > theoretical solution to this, where it can forward auth
> > > information, but how to handle the forwarded auth information is
> > > still a work in progress.
> > 
> > There is a really simple solution for these Gmail customers getting
> > their forwarded mail rejected. But it lies on Gmail side.
> > 
> > Gmail already knows that the account of bl...@gmail.com is linked to
> > the mailbox bl...@example.com, since bl...@gmail.com is configured to
> > allow sending as bl...@example.com. It should thus detect that the
> > email received from mta.example.com with a "To: bl...@example.com" is a 
> > forward requested by the user, and not reject it at the gateway when it 
> > fails SPF.
> 
> Heuristics like this have been used in the past, but spammers often
> figured them out.

I was initially going to suggest that it was received by any server
passing SPF for the configured external account, then noticed that
perhaps that didn't work so well with those large SPF records, and
mentioned just that To: (just an example, it could e.g. be detected
through headers as well) but it really should have mentioned "from the
right server".


> > Or, in order to have a stronger command from the user and avoid
> > forward-guessing, at the cost of a new configuration setting, let the
> > user configure a list of IP addresses from which they are forwarding
> > mail to their account.
> > Then Gmail could clearly recognise what is actually happening: that the
> > connecting IP adddress belongs to a border MTA of this user, and then
> > walk Received: headers to fetch the actual IP address that delivered it
> > to bl...@example.com, which is the one that should be taken into account
> > for a proper evaluation.
> 
> Yes, this is how workspace handles this, you would just set the list of IPs 
> as 
> the inbound gateway.  Even then, there are cases like outlook.com/O365, where
> the list of possible IPs is very high... or forwarding gmail to gmail, for 
> that matter..

Allowing users to set this as well would allow users to fix this issue
where gmail would otherwise reject the mail they want forwarded. At
least for those coming from a small set of ip addresses (although large
ones probably use a forwarding pool).


> An even better one would be ARC, it would be pretty easy to specify
> one or more ARC ADMDs as trusted forwarders on a per-user basis (or
> for workspace admins).
> 
> This suffered from a chicken/egg problem on top of the general 
> "hard for most users to understand", and the general small usage of
> regular forwarding...
> the better option was to generalize the benefits of ARC to all users
> automatically... but that work is still in progress.

ARC would indeed be a more complete solution. However, I suspect this
may be one of those cases where perfect is the enemy of the good.
Specially since this doesn't solve the issue of which ADMDs to trust.

I agree about the general problem of "hard for most users to
understand" how to fill out ip addresses or ADMD identifiers, but given
the issue that 

Re: [mailop] DMARC/TLSRPT to non-existing accounts/reflection and sender reputation

[Ángel via mailop]

That's an interesting attack.

I initially thought you were going to describe placing a victim as your
destination target which is something which is prevented by requiring
the receiver to authorize them:
https://www.rfc-editor.org/rfc/rfc7489.html#section-7.1

But this is getting a spamtrap to accept emails and treating them as
intruding attempts. The onus should be on them to detect that they are
the MX of the target domain, and thus the sender may be playing by the
rules. Quite easy to notice if you start seeing in DMARC reports in
your spamtrap, actually.
But this doesn't mean that all spamtrap operators do that, or wouldn't
be vulnerable to that.

Note that you could perform a similar attack by subscribing a user to a
number of mailing lists, promotions, etc. then changing your MX to a
spamtrap, which would then blame the sender IP.


Regards

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] forwarding to gmail - problem

[Ángel via mailop]

On 2022-04-28 at 12:45 -0600, Geoff Mulligan via mailop wrote:
> I have a user on one of my servers that uses procmail to forward
> messages to their gmail account.
> 
> Every once in a while messages sent to them are "bounced" to the
> sender with the error fro gmail:
> 
> 550-5.7.26 This message does not have authentication information or
> fails to 550-5.7.26 pass
> authentication checks. To best protect our users from spam, the
> 550-5.7.26
> message has been blocked.
> 
> How can I diagnose this???

Seeing it here as well. Something has recently changed in gmail again,
just like last December.
I'm quite sure Robert L Mathews discovery of the line-wrapping issue
was caused by this as well.

(And yes, this is happening to legit messages, hand-typed for them, and
that when reviewed manually show no trace of spamminess at all)

If your senders use DKIM, those will generally pass. However, 

a) some senders do not implement DKIM, so their mails cannot benefit
from it when forwarded
b) some mails will have invalid DKIM signatures
(in which case you will have a hard time figuring out if that was
broken to begin with or if some uncommon feature on this mail moved
your MTA to "fix" it breaking the signature)


On 2022-04-28 at 12:02 -0700, Brandon Long noted:
> Are they using the suggestions on 
> https://support.google.com/mail/answer/175365 for procmail
> forwarding?
> 
> There's a double edge sword with SPF auth for forwarding.. if you re-
> write the envelope sender to the forwarding address and forward spam,
> the forwarding domain can accumulate poor reputation.  If you don't
> rewrite the envelope sender, then the messages will no longer be SPF
> authed, and that may cause spam detection issues.

Gmail guidelines explicitly ask not to rewrite the envelope sender


> There's no great solution to this problem. (...) ARC is the
> theoretical solution to this, where it can forward auth
> information, but how to handle the forwarded auth information is
> still a work in progress.

There is a really simple solution for these Gmail customers getting
their forwarded mail rejected. But it lies on Gmail side.

Gmail already knows that the account of bl...@gmail.com is linked to
the mailbox bl...@example.com, since bl...@gmail.com is configured to
allow sending as bl...@example.com. It should thus detect that the
email received from mta.example.com with a "To: bl...@example.com" is a
forward requested by the user, and not reject it at the gateway when it
fails SPF.

Or, in order to have a stronger command from the user and avoid
forward-guessing, at the cost of a new configuration setting, let the
user configure a list of IP addresses from which they are forwarding
mail to their account.
Then Gmail could clearly recognise what is actually happening: that the
connecting IP adddress belongs to a border MTA of this user, and then
walk Received: headers to fetch the actual IP address that delivered it to 
bl...@example.com, which is the one that should be taken into account
for a proper evaluation.


This is something that should be implemented by everyone. If you are
forwarding messages to somewhere else (and expecting to receive them!),
you should configure the *receiving* side to recognise it as such.
Sadly, no end-user provider seem to include this setting, so it ends up
being only an option for those running their own systems. ☹

Even on corporate systems, where they have a filtering mail server at
the border, and their postmasters should know better, it's not that
uncommon to find out it is misconfigured and the internal MTA is
treating every mail as failing SPF.

Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Ángel via mailop]

On 2022-04-18 at 19:32 +1000, Simon Wilson wrote:
> *Completely* and objectively not true.
> 
> I've run Android phones for many years with a Google account based on  
> my own personal non-Gmail email. I have never activated or used Gmail,  
> and at no stage has an Android phone ever tried to force me to use  
> Gmail.
> 
> When using Android without Gmail, at no stage in the "defaults" or  
> "preinstalled apps" is this anything other than "enter your Google  
> account email address and login"-difficult to achieve.
> 
> > > or for a number of other reasons related to other services.
> 
> Without knowing what "other services" you refer to, it's hard to be  
> specific, but I use a lot of Google services without having a Gmail  
> account without any difficulties. Which services (specifically) do you  
> have in mind that are forced to use Gmail?

The systems may not *strictly* require a Gmail account, only a Google
account, but that doesn't mean it is not perceived as such.

I still remember how, many moons ago (i.e. 20 years back), I was
introduced to MSN Messenger¹ and when asking what it required, told
that in order to use it I needed a hotmail account.

Was it accurate? No. What it actually required was a Microsoft Passport
account (later renamed Windows Live ID), which could be added onto an
email address by a different provider (something I only learned time
later).

However, even if it isn't actually a hard requirement, if it is
perceived as a requisite to use the software, there is still such
effect.


Best regards


¹ https://en.wikipedia.org/wiki/MSN_Messenger


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG. Domain age?

[Ángel via mailop]

On 2022-04-16 at 14:26 +0200, Jaroslaw Rafa via mailop wrote:
> Dnia 15.04.2022 o godz. 20:18:54 John Levine via mailop pisze:
> > > You quoted that. Eu.org is a *domain registrar*. Only. They don't
> > > offer any
> > > email service and never did. So how can they "police users for
> > > email"?
> > 
> > They can turn off people when they get credible spam reports.
> 
> Maybe they do. Honestly, I don't know as I'm not a spammer. What I know is
> that they explicitly state in their policy that you cannot use the domain to
> spam. This doesn't have to translate to any actual action against spammers,
> but it can.
> 
> Is there anybody here who knows for sure?
> 
> Also, as I have mentioned in another mail, it takes some effort and quite a
> lot of time to get an .eu.org domain up and running. Free doesn't mean it's
> a few clicks and you're set. Having to wait 10 days or so until your domain
> is manually accepted doesn't make it an attractive option for spammers. It's
> an "old school" service and their registration process is clearly oriented
> towards people interested in using the domain for long time.

It's a long shot, but I wonder if this may be related to their whois
not showing the creation date.

The age of a domain has long been an important feature when measuring
the worthiness of domain. Typically a domain registered last month
would be seen more suspiciously than one registered 15 years ago.

So I am certain this feature is taken into account by Google. However,
a whois of you domain does not show a creation date (there are old
changed: lines, but a system should not need to look at them as a
fallback). I don't know how Google actually measures domain age (whois
queries don't seem a likely way, but e.g. eu.org is unlikely to be in
the CZDS, either), but if it doesn't provide a registration date (which
for a niche pseudo-TLD like this doesn't seem much likely to be
noticed), old domains like yours would be grouped the same as
completely new ones.


Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Ángel via mailop]

On 2022-04-24 at 00:44 +0200, Jaroslaw Rafa via mailop wrote:
> Dnia 23.04.2022 o godz. 14:48:05 Dan Mahoney via mailop pisze:
> > I would LOVE there to be legal structure to say “Gee, Equifax, you failed
> > to demonstrate the basic opsec of paying some junior admin to type `yum
> > upgrade apache-struts`, so you don’t get to keep my PII anymore.” I would
> > love if there was an option to simply put a flag on my SSN that says
> > “gather/sell no data” to any of the dozens of agencies that harvest this
> > (radaris et al) and package it up neatly.
> 
> Isn't European GDPR something that is supposed to achieve exactly
> this?
> 
> Yes, it doesn't work perfectly, and there are multiple companies that try to
> go around it in multiple ways, but it's a step in good direction IMHO.
> 
> At least at the moment when GDPR came into effect I observed a BIG drop in
> amount of spam coming to my server. And still, after several years, it
> didn't return to pre-GDPR quantities yet...
> 
> Of course YMMV, especially outside Europe...

Yes, I don't think GDPR would allow Equifax to process this data.* But
AFAIK they mostly work with USA data.

What made this incident completely embarrassing was that the apache-
structs vulnerability had been known for a very long time (6-9 months?)
and widely publicised. One might understand a small company not
"getting the memo", but such a big company? Didn't they have any
security people?
(it would probably have been harder than a yum upgrade, but using it on
production should have rang all alarms months before)

That said, I am kind expecting a similar case of "big company that
should have known better getting compromised by obvious security fail"
with the log4j vulnerability that was discovered last December.


Best regards


* There are probably a number of loopholes though, such as your
companies (banks, insurance, utilities...) looking you up and reporting
certain data to this kind of services. But in general, things should be
much better under EU legisation than in the US.


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Interesting passage from the new EU Digital Services Act

[Ángel via mailop]

On 2022-04-24 at 00:55 +0200, Jean-François Bachelet wrote:
> Hello ^^)
> 
> Haven't read the full EU stuff yet, but question :
> 
> How can we be possibly become aware of such possible threats without 
> SPYING -read it all- the email passing by our mail servers ???

Well, it only applies *when* you become aware of that.

The clear example I can think of would be a Facebook post saying "I
will install a number of bombs next week". That is published
automatically by the user (Facebook is not aware of it). Then the post
is flagged by a user and reviewed by a moderator. *At that point*
Facebook would "become aware" of such information, and need to report
it to the Law Enforcement.

On the other hand, if you are a site which accepts guest posts, with a
policy of reviewing everything before publishing, you would be expected
to have been become aware of that.


Of course, if you are instead the NSA, you would probably want a
trigger on every mention of the word "bomb", you know, for the Greater
Good of National Security, even if that means getting a lot of False
Positives... such as this thread.


> only a jackass wana be terrst will put dangerous/alarm trigger
> stuff in the Subject of his emails.

I don't think the Subject line of emails would be any different than
the body wrt to not spying your users.
(Nevertheless, I am sure many crooks have used incriminating Subject
lines on their emails)


> so do the EU wants us to play as NSA for free ? and pursue us if we
> don't...

As mentioned above, I don't think so. 

Moreover, the proposal itself reminds 
> the prohibition of general monitoring obligations, as interpreted EN
> 4 EN by the Court of Justice of the European Union⁸.
> ⁸ For instance, Judgment of 3 October 2019, Glawischnig-Piesczek (C-
> 18/18).


Also of interest, this proposal doesn't seem to have been approved yet

https://eur-lex.europa.eu/procedure/EN/2020_361


Best regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] MTA-STS Policy File Syntax Question

[Ángel via mailop]

On 2022-04-22 at 17:30 -0500, Faisal Misle via mailop wrote:
> Note the trailing dot on the second policy. Is that a valid MX for the 
> policies of the file? I could not find anything about it on RFC 8461 and 
> most validators were flagging it as an invalid MX.
> 
> Looking forward to hearing your thoughts!
> 
> -Faisal

That trailing . (the root zone) appears on dns and in the ouput of e.g.
host(1), but I don't think it is valid in the context of a STS policy
file (even though I often leave that triling . when writing local STS
overrides)

RFC 8461 don't mention trailing dots in the text, nor they appear on
the samples. This is a good indication it isn't expected.

And for the formal rules, rfc8461 defers to rfc6125, which basically
say "the text must be the same case-insensitive"

> If the DNS domain name portion of a reference identifier is a
>"traditional domain name", then matching of the reference identifier
>against the presented identifier is performed by comparing the set of
>domain name labels using a case-insensitive ASCII comparison, as
>clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased
>to "www.example.com" for comparison purposes).  Each label MUST match
>in order for the names to be considered to match

(*) skipping over the mentions of wildcards for clarity


Thus my conclusion is that the mx entries MUST NOT have such trailing
dots.
Furthermore, the fact that validators reject them is a sign that
implementations are likely to reject them as well, which would lead to
email not being delivered (since no mx would match)

Nonetheless, per Postel's Law, a client MAY wish to ignore such
trailing   dots and I think it would be fine.


Best regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DKIM by the third party

[Ángel via mailop]

On 2022-04-21 at 10:04 +0800, Henrik S via mailop wrote:
> Hello
> 
> My mail is sent by the third party smtp server, and the dkim
> signature 
> is made for the third party domain (for this case, it's pobox.com).
> 
> does this DKIM have helps to the authorization of my outgoing
> messages?
> 
> Thanks

I believe the answer for what you are actually trying to ask is NO.

In the usual context of email communication, if I receive an email
 From: Henrik S 

what I would want to know if whether it really comes from 
tomatoservers.com. As such, a signature by pobox.com would have no
value for that.

That is the stance by DMARC, which expects that email with a From: of 
tomatoservers.com to be signed by a DKIM signature of tomatoservers.com
 or to have a SPF for that (which you have set).


Technically, DKIM (RFC 6376) doesn't preclude for signing email not
from unrelated parties, and those would typically be ignored by other
systems.
Or used for unrelated reasons to actual mail delivery, such as giving
access to GPT, as Laura mentions.

However, *some* systems do give more weight when signed by third-party
keys that are "good".
If -historically- most email signed by pobox.com is not spam, your 
tomatoservers.com signed by pobox.com is probalby leaning as well to
not being spam. This may be taken into account when weighting it.
Whereas if mail signed by pobox.com has a 50% chance of being spam,
that signature wouldn't help.

In summary, having a signature from pobox.com in your tomatoservers.com
 won't "authorize" your outgoing mail as really coming from 
tomatoservers.com.

However, with some server that pobox.com signature might have some
value (positive or negative) and so not being completely zero.


Years ago, dkim-reputation.org provided a database of good/bad
senders[1]. I don't know if there are other similar reputation services
now (big players obviously have their own data for that).

I would be interested on what are other (smaller) parties doing (if
any) to measure the "goodness" of valid DKIM signatures.
Also, the signature could simply treat the DKIM signature as a link
with the signer domain (in this case pobox.com). Or it could also take
into account the specific signature chosen (either the selector or the
key), so that different email flows could bear different signatures and
receive different weight.
However, the later case would obstruct key rotation, discouraging the
rotation of a DKIM key perceived to have an high value.


Regards


1- https://web.archive.org/web/20170712210708/http://www.dkim-reputation.org/

PS: Interestingly, I was precisely a similar discussion about DKIM
reputation just a few days ago.


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best mailbox provider for personal domain?

[Ángel via mailop]

On 2022-04-10 at 18:35 +0100, Andrew C Aitchison via mailop wrote:
> On Sun, 10 Apr 2022, Byron Lunz via mailop wrote:
> 
> > I don't recall seeing any discussion in this thread about how to
> > migrate
> > old email messages from a Google Workspace account to a different
> > host.
> > Anyone have advice or suggestions on how to do that?
> 
> I haven't needed to do it myself but I believe there are good 
> IMAP-based tools for transferring emails from one server to another.
> 
> For the moment Gmail still suppports IMAP, though you may have to go 
> through hoops (such as "less secure apps" or XOAUTH2) to enable it for a 
> particular app/client.

The Swiss Army Knife of moving mailboxes with IMAP is imapsync(1)

As Tara has its own domain, I think XOAUTH2 would work. In any case,
there's always the less-secure-apps path (why is 2FA required for using
app passwords?). The main hurdle would probably be gmail throttle
limits. See https://imapsync.lamiral.info/FAQ.d/FAQ.Gmail.txt

Best regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] suggested max received headers/hop limit

[Ángel via mailop]

On 2022-03-10 at 15:28 -0500, John Levine via mailop wrote:
> If you really want to stop mail loops, use a Delivered-To header like
> qmail, Postfix, and Courier do:
> 
> https://datatracker.ietf.org/doc/draft-duklev-deliveredto/

You still need to stop at *some* hop-count. This approach stops
delivery loops, but not all loops involve a delivery.

It's not a common occurrence, sure but perhaps 1-2 times a year I do
see one such loop from using email addresses that should have been
working.
E.g. your email arrives to the on-premises MTA, which not finding a
local user passes it to Office 365 who doesn't have that either so it
is sent again to on-pre

Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best email server for home use...

[Ángel via mailop]

On 2022-02-23 at 17:49 +0100, Jaroslaw Rafa via mailop wrote:
> Why are you looking for a webmail close to Gmail? Gmail's webmail
> interface is one of the worst possible. It is very inefficient to
> operate,
> counter-intuitive, hides many important information from the user
> etc., not mentioning that it is simply ugly. There are many much
> nicer and more user-friendly webmails, like for example already
> mentioned Roundcube.

Probably because that's the client they are currently using. IMHO this
was the most interesting part of the query. Choosing the right MTA is
interesting for the sysadmin, but an implementation detail. There are
many good options, and I'm sure John would do fine with pretty much any
of them (add / remove some amount of initial sweating).
However, the UI… the interface is a completely different matter. You
could completely change the backend and your users won't even notice.
But change slightly the position of a button and Aunt Tillie will start
complaining how you broke everything and she is now unable to work with
the 'new system'

And here we are talking about a major migration to a completely
different interface. It won't be a problem if the users are reasonable
and a bit savvy, but the "for the family" bit makes me think that he
may have some users of that breed.
I would be interested in how it turns out.

Personally, I don't think Gmail it's *that* ugly. It has its
shortcomings, particularly it doesn't have full threading, and I have
found it doesn't let me insert/attach files with the "Modern"
interface.

I would happily provide a Gmail-like webmail look to my users. Some
users really like having their in gmail, and I have not received a
clear answer showing that it is objectively better than the webmail
they have at their disposal.

There is a commercial roundcube skin which claims to make it look like
Gmail, but I haven't tested it. I suspect it might change some parts to
look more like gmail, but only partially, which could be worse than
actually making it look like a separate products.

John, I would explore as well the option of them installing a local
client, such as Thunderbid, instead of using a webmail. If they always
use the same client machine)s), that setup should work fine, and a
local client will be more potent.

Maybe I will test some of the clients on that list.

A portion of them simply connect to the IMAP server, so you could
switch webmails (or even provide different ones at the same time) with
no consequences.
But I think some do require that you use *their* MTA.


Finally, another point you may want to take into account when
evaluating the software are the security fixes. If the programs you
install are packaged by your distribution, you may update them with a
simple upgrade of the systems. However, with separate apps will be more
complicated. And nowadays some servers/webmails aren't really supported
in upstream.


Best regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] 2 questions about BCC and mailing lists

[Ángel via mailop]

On 2022-01-31 at 10:43 -0700, Geoff Mulligan wrote:
> 1. If a recipient on an email message is both in the To: or Cc: and
> on the mailing list, should the listserver send the message to the
> recipient:
>   a) By default
>   b) Not by default (but configurable)
>   c) Never

Yes, it should be sent to that recipient. It's also simpler to explain
and understand. It may be annoying for some people, in which case you
might wish to make that configurable, but the default shall be to
deliver.

(The direct copy can annoying as well, since it won't have the list
headers which would easily let replying to list)

However, the more pushing issue is the security aspect. If the list
skips you when it finds you in CC I can influence the mailing list
server to send an email to everyone but you by simply including a Cc
header saying I am copying you (but not actually adding a RCPT TO: with
your address)

Or, more innocently, should the direct copy fail for some reason (we
have plenty of examples here), that person won't receive the direct
email *nor* the indirect one through the mailing list.

In such case, there should be a NDR, granted (perhaps received a week
later), but even assuming the NDR is seen and understood by the sender,
he will probably shrug and assume it will have been received through
the mailing list.


The most exotic case I remember right now happened when replying
privately to a subscriber of this list, where their tagged email
address refused receiving my email, since I wasn't mailop. The funny
thing is I was providing the contact email address they had asked for.
I had to do some twisting to get their MTA to accept the message, and
it was probably dropped anyway, since I received no response.
If I replied both directly and to the list, such configuration would
have been a problem.


> 2. If a mailing list is in the BCC: should a message be delivered to
> the 
> list:
>   a) Yes - always
>   b) No - never
>   c) Configurable
>   d) Convert it to a CC:

I'm with John here. I would reject mails not explicitly showing the
list as a recipient. You can do so when incoming, in order to avoid
backscatter.

The only legitimate case I can think of that are chained list, such as
when -users mailing list is itself a subscriber of -announce. But since
both lists would be in your platform, taking that into account
shouldn't be a problem.


Best regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Musings on Mail Service Operators

[Ángel via mailop]

On 2022-02-02 at 21:31 -0600, Scott Mutter wrote:
> Email - as we know it - should have been dead years ago.  But instead
> we keep adding band-aid after band-aid after band-aid to the system.

Maybe what you call a band-aid was actually preferable?


> Why is it impossible to take a look at what Instant Messaging
> protocols, SMTP, SMS do that make them successful and then blend
> those together into a new "email-like" system?

https://xkcd.com/927/

> 
> I'm not going to pretend to know what the ultimate solution might
> be.  One of the major issues with email is the address spoofing that
> goes on.  Maybe a spoofed address doesn't authenticate with SPF or
> DKIM... but that only works if EVERYONE else uses SPF and DKIM...
> that's the bandaid.  Instant messaging and SMS can't as easily be
> spoofed, they may be fake but senders have to register on the
> platform in some way (be it a Facebook account, Twitter account,
> phone number, etc).  Would more need to be done to lock this down? 
> Absolutely.  But it's at least A obstacle that potential abusers have
> to overcome.  Email doesn't have that.

We have seen *a lot* of SMS spoofing (Poland, UK, you're not alone!).
Say you receive a SMS with a spoofed sender of "MailopBank" containint
a phishing link. Your phone will fill this with all the other
(legitimate) SMS you received with a sender of "MailopBank". It's not
really the phone fault. It has no other information to tell
one "MailopBank" from the other (one might perhaps blame being able to
use text as SMS senders). It has no sending IP, no SPF, no DMARC…

The reason SMS is still in use is because it provides the lowest level
technology, for sending a code to a phone user, be that a flip phone or
the latest smartphone release.



> Email was first invented in 1971 - that's over 50 years ago.  We've
> learned a lot about how people tend to use email and how people tend
> to abuse email within the past 50 years.  Instead of adding new
> constructs to email. Why not invent a new, more modern email
> alternative?  Something that takes a lot of what we've learned from
> email usage over the years, what we've seen in instant messaging,
> SMS, and other computer communication protocols and builds on that
> from the ground up?  Wouldn't that be better than constantly adding
> band-aids to email/SMTP to fix problems that pop up?

At which point does a system become "a more modern alternative"? We
could build an email system that used protobufs rather than SMTP, for
the sake of making something new, but if it doesn't provide an
improvement over SMTP, it's better to use the extensibility mechanism
of SMTP. Compatibility is very important. If your new system can be
gradually rolled out, and is able to receive messages from the existing
systems, that will be preferable.


> I'm not a huge fan of mailing lists or distributed mailings (forums
> accomplish the same thing with less of the hassle of email
> deliverability concerns).

So you are advocating for a better email which is able to do less
things than mail?
Plus, a mailing list is just the ability of sending to multiple users.
You could easily have a WhatsApp mailing list bot replacing groups.


> Not a huge fan of automatic email forwarders/redirects, which tend to
> break SPF and DKIM.  Maybe things like these don't need to be
> allowed?

But the users *really* want to have all their messages on the same
mailbox, even if they could easily access the other mailbox. Otherwise
we wouldn't need email forwarding.



> Yet those platforms don't seem to have an issue in getting people to
> use them.  Why couldn't a properly reimagined email replacement do
> the same thing?


And email don't have an issue in getting people using it.* The issues
lie on a lower level, like not receiving /certain/ messages, or in the
management by some clients, which is interface (you will however face
some problems in getting a mail client for your new protocol that is as
good as every existing one for "traditional" mail).


* Many people don't actually know how to *properly* use email, but
that's a slightly different issue. They manage to "use" it.



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail does not validate DKIM for forwarded messages?

[Ángel via mailop]

On 2022-01-30 at 14:09 +0200, Edgaras | SENDER wrote:
> Hello,
> 
> We noticed in Google Postmaster Tools a lot of bad reputation IPs
> which do not belong to us, and are actually forbidden from sending
> emails on our  behalf via SPF -all, yet Gmail thinks the messages
> from these IPs were fully authenticated.
> 
> After investigating some reports, it looks like a DKIM replay attack,
> where Gmail does not validate the original DKIM signature (which
> includes Message-ID:Reply-To:To: fields), and even ignores SPF
> permerror, if the message contains ARC headers.
> 
> Full headers below, any insights or suggestions would be appreciated:


Hello Edgar(as)?

I have been looking at your email, but I am confused at how it was
produced, and so which are the weird bits.

It purports to be a mail from bounces-test770...@sendersrv.com to 
ysoul8...@gmail.com, which then was "forwarded" (!) by 212.83.129.110
to incident-repor...@gmail.com with a MAIL FROM:<
921108683ccq405...@universidadebrasil.edu.br> and a EHLO of
lingojam.com


It makes sense that DKIM could be skipped if there is ARC, but then ARC
should be checked!

Some interesting bits:
- Two Date: headers
- Two different Subject: headers
- Original Return-Path:  appears twice

- A couple of headers have two consecutive dots where there should be
one: "212.83.129..110", "mx.google..com", 

> Received-SPF: permerror (google.com: permanent error in processing
> during lookup of 921108683ccq405...@universidadebrasil.edu.br:
> host.universidadebrasil.email not found) client-ip=212.83.129..110;
> Authentication-Results: mx.google..com;

Note: the first Subject header wasn't encoding those utf-8 characters?



Best regards


PS: yes universidadebrasil.edu.br has a bad SPF record:
"v=spf1 include:spf.protection.outlook.com
include:universidadebrasil.edu.br ip4:192.99.207.72
include:host.universidadebrasil.email ip4:45.33.9.144
include:mailgrid.com.br -all" but no txt on
host.universidadebrasil.email



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft/O365 SPF failures

[Ángel via mailop]

On 2022-01-20 at 20:33 +0100, Klaus Ethgen via mailop wrote:.
> > Scroll down to the relay pool subheader and read up more about it.
> 
> That means, Microsoft ist intentional breaking mail.
> 
> > Hope this helps.
> 
> Well, as I am not the sender than the recipient, no, it does not.
> 
> When it is not part of SPF pool and they have '-all' in SPF record,
> then the mail could not be delivered.
> 
> Only Microsoft is blamable for breaking it and only they can fix it.
> 
> Regards
>Klaus

Someone forwarding mail from one account to a different mail server
should configure the receiving account to know that it is being
forwarded mail from $OriginalAccount, so that it can take that into
account and trust the forwarding mta.
Otherwise, it just looks as if the forwarder is spoofing all the mail
that is forwarded.
DKIM-signatures would (should) survive, but forwarding will generally
break SPF (forwarding can either keep the original MAIL FROM or rewrite
it, I don't know which version O365 chooses), and that is expected. You
should place an exception on the receiving account to cater for that.

Microsoft adds another layer attempting to make it easier for you to
filter invalid mails since they forward from the relay IP addresses
when the mail didn't validate to begin with*

It is good that you are running your own mail server and can thus
tinker with it, since I know of no mail provider which offers such
preference to their users in their interface (although perhaps they
would support that as a custom request, though).



Best regards



* 
https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/high-risk-delivery-pool-for-outbound-messages?view=o365-worldwide
mentions

«The forwarded/relayed message should meet one of the following
criteria to avoid using the relay pool:

* The outbound sender is in an accepted domain.
* SPF passes when the message comes to Microsoft 365.
* DKIM on the sender domain passes when the message comes to Microsoft
365.»

but I suspect it might not be accurate. It would make more sense that
the criteria would be having the outbound sender is in an accepted
domain and either SPF or DKIM passes when it arrived O365. Or mayb 









___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] .eml Attachments and the 1000-character SMTP Limit

[Ángel via mailop]

On 2021-10-16 at 02:52 +, John Levine wrote:
> According to John :
> > Which contemporary languages and infrastructures have a problem
> > with long lines? Old school used small buffers to handle
> > consecutive portions, the method
> > is not much different to line based handling. Today, buffers tend
> > to be larger than content.
> 
> The Oracle one, widely used in corporate environments does.  I asked
> the guy who maintains it who told me that it is
> heavily threaded and the locks needed to do dynamic allocation for
> arbitrary line lengths is a performance issue.

Except, there is no need to allocate arbitrary line lengths.
It can be useful to set a limit on the protocol lines themselves, so
that you don't need to process a 2 MB MAIL FROM:<> line, but once
you're inside DATA (and moreover inside the email body), you can pass
on to the storage / next pipeline pretty much everything, and only need
to watch for "\r\n." and "\r\n.\r\n", which needs quite little
buffering.

That said, it turns out I do have such an arbitrary, well-over-1000-
characters, line length line limit in my own mail server... 




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP AUTH harassment

[Ángel via mailop]

On 2021-07-19 at 23:27 +0200, Slavko wrote:
> Hi,
> 
> Dňa Sun, 18 Jul 2021 13:56:18 -0400 Bill Cole:
> 
> > > The only usable way seems to be GoiIP blocking countries, but i
> > > afraid that it is wrong way.  
> > 
> > Why?
> 
> Hard to describe it in English for me, but i will try.
> 
> I consider blocking access by country as discriminating all honest
> people in particular country. (...)

You opened the thread describing it as a "personal mail server". I
interpret that as being a mta serving just you, or a few select family
members/friends.
As such you can (should?) be highly selective. If you only use ISP A,
why should you allow from any other source? It's not as if you won't
notice when you change providers. If John uses only provider B, why
would you let a login from ISP C?

This is not about limiting people. It would be wrong not to let someone
access a public place¹ based on their race or nationality.² We are
talking about your own server, such as your home. It would be perfectly
fine not to let any Elbonians to the door of your house if you don't
have any Elbonian friend (or you know they will tell you before paying
you a visit) or, conversely, to ask the doorman to filter out any
visitors not wearing hats. Of course, they would still need a key to
open the door to your house, but there's no reason to to a quick
filtering before letting them try their lock-picking skills.


Regards




¹ In a broad meaning, including privately-owned ones, such as a
shopping center.
² Ok, you may argue that an embassy might be considered a "public
place" and yet to have a legitimate reason for being highly selective
on your nationalitiy.


PS: 
> One can be surprised, but my long term country stat shows, that worst
countries are USA and Germany, and no, China is even not in top 10.
(...)


For July, the top number of fake auth attempts come from US, RU, BG,
CN, BR and NL. If counting just distinct IP addresses, it's BR, CN, IN,
PL, N/A, IR, US, AR, RU, KR


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP AUTH harassment

[Ángel via mailop]

On 2021-07-18 at 22:29 -0400, John Levine via mailop wrote:
> 
> I do wish it were easier to report and kill the drop boxes, though.
> 
> It would be nice if regasignsd...@yahoo.com went away.

I was only visited by that on July 9th.
Others like mx-server.org are much more persistent here.

Here are some of the most common drops I have seen this month (some
using AUTH, others just trying to get by with a return-path):
   4247   → Just from a couple of Russian IP addresses
   3745 
   3233  → 2k IPs, 35 countries
   2899 
   2433 
   1292 
   1193  → Uses tor exit nodes
   1134 
642  → 1k IPs, 26 countries
269  → From a single source: 89.42.211.197
152  → Apparently a new mail of 
yurespav...@libero.it
 64 


Cheers


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Outlook for Mac email autofill

[Ángel via mailop]

On 2021-05-21 at 11:48 -0400, John Lightfoot via mailop wrote:
> That option doesn’t seem to exist in Outlook for Mac.  I can go to
> Preferences/AutoCorrect/Text Completion and turn off Show
> AutoComplete tip for AutoText and dates, but that doesn’t seem to
> affect autocomplete for email addresses.
> Someone asked earlier if I was auto-replying to spam, and no, I am
> not.
> Thanks,
> John

Maybe you have those entries in your address book, auto-added from
receiving a spam mail from them?

Best regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Exim patches / vulnerabilities

[Ángel via mailop]

On 2021-05-04 at 18:05 +0200, Raymond Dijkxhoorn wrote:
> Have fun patching!
> 
> Bye, Raymond

Thanks Raymond

See as well 
https://blog.qualys.com/vulnerabilities-research/2021/05/04/21nails-multiple-vulnerabilities-in-exim-mail-server

This has been a coordinated disclosure, hopefully those running Exim in
production will have upstream packages ready to install and little
trouble in the process.

An interesting point is that all of us will probably start receiving
Exim exploits in a few days/weeks, when attackers begin to figure out
the exploits.

I have yet to study the full Qualys technical writeup, but it would be
interesting if it turns out to be possible to detect when a client
attempts to exploit them.

Best

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: Info - DMARC at WEB.DE, GMX, mail.com coming soon

[Ángel via mailop]

On 2021-04-01 at 07:36 -0700, Marcel Becker wrote:
> On Thu, Apr 1, 2021 at 12:43 AM Hans-Martin Mosner wrote:
> > One option that you should consider to mitigate the effects for
> > recipients is to allow per-recipient DMARC exceptions, because the
> > recipient is the one who ultimately decides whether mail is wanted
> > or unwanted.
> 
> Recipients are the ones least able to make a decision whether a mail
> claiming to be from brand.com was really sent from brand.com. They
> don't even know that a mail from lookslikebrand.com is not legit,
> move it out of the spam folder and then proceed to interact with
> it...

I have mixed feelings on this.
Users manually overriding DMARC indeed weaken the ecosystem. They
should never need to e.g. override that for their bank, or a normal
page. That site is misconfigured.
If they get used you end up in the situation where hard errors are no
longer "hard", since users will bypass the certificate error anyway.

On the other hand, by dumbing down the users with binary spam filters,
that leads to poor accountability. If you filter the legitimate bank
mail into spam, even if it was because the bank dns records are utterly
broken, then it's suddenly "your fault", Clearly showing to the user
the assertion by Bank on which you relied would allow to be relayed
back to the entity originating the non-compliant mail.

You might have a power user wanting to override a bad entry for a
system with an unresponsive postmaster, but that would be a really
advanced feature.

I would suggest to just let the user switch between a strict (reject
what the sender asked to be rejected) or soft behavior (only quarantine
if the user wants to be extra sure to receive mail from broken systems,
albeit showing they should have been rejected).

That covers the use case of a user adding exceptions for directly
received mails.


However, if the user set up mail forwarding, there user *should* be
able to state they are forwarding from _host_.

The user requisite in laymen terms will be something like "I want mail
sent to mr...@example.com on my account j...@gmail.com"

Such option would be an obscure one, but it's a one-time thing that
would need to be documented, anyway. User would need to follow some
instructions stating how to forward its mail on example.com *and* how
to configure gmail.com to know it will be forwarding from X ip address
(or, better yet, a given ARC signature).

That's simple for everyone involved, the sending side only needs to
setup forwarding, and the receiving one to augment the user perimeter
to trust that server [signature, Authorization-Results, etc.].

It's simpler for receiver's anti-spam system, that won't need to care
about that "spoofed" legitimate mail it is receiving, and will allow it
to avoid that noise and produce better results. It's simpler as well
for the forwarder, no need of tricks like forwarding some of the mails
and providing others through a POP3 pull (and what if they consider it
legacy and didn't want to provide POP3?). And even for the user, which
should get more consistent results with a similar effort.


Best regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Info - DMARC at WEB.DE, GMX, mail.com coming soon

[Ángel via mailop]

Am 27.03.21 um 15:29 schrieb Hans-Martin Mosner:
> Forwarding is most often used by recipients to achieve their
> preferred way of handling mail, so rejecting mails that they want to
> receive would mean you ignore their wishes as recipients in
> favor of the wishes of the senders who often don't take these
> machanisms into account.

The recipient should be in control of the rules. If a recipient wants
to bypass any spam controls for mail coming from an IP from which they
forward, they should be able to. Or to let ab...@example.com receive
known-malicious mail. It's all fair game.

The problem is that mail providers (that I know of) don't allow that
granularity to the customers and instead end up second-guessing if the
customer would want to override it or not, which weakens the ecosystem.


On 2021-03-27 at 15:43 +0100, Hans-Martin Mosner via mailop wrote:
> I just noticed that the mails in this mailing list are such an
> example. Apparently the mailing list system does not
> perform DMARC mitigation on mails, so the original sender's DKIM
> signatures become invalid. If you had a DMARC policy of
> "reject" and our mail system would strictly adhere to the policy,
> your mail would be rejected. Is that your (the
> sender's) will?
> 
> Cheers,
> Hans-Martin

What's your plan for handling mailing lists? Even if you leave them in
a spam folder, that will surely upset some of your customers.
Also, are you going to expose the reason to the user?



Thinking how to design a system like this, I would probably add a
banner when viewing those spamboxed mails:

> Marked as spam because it falsely claims to come from example.com,
> and example.com explicitly requested all such mail to be
> [quarantined|discarded] 


And, if the mail has mailing list headers, add a second link:
> Skip this check for mail from «For mail operators »


Obviously,  would lead to a page explaining in more detail
(but still in layman terms) that a sender requests that using DMARC and
the mail wasn't signed by example.com nor came from any of the servers
stated are the only ones sending legitimate mail on behalf of them.

And 'Skip this check' would add it to a per-recipient list of mailing
lists he is subscribed to, which provides a direct pass to the inbox
(assuming alignment for the mailing list itself). If the list went
rogue or the user wanted to unsubscribe, he could remove that exception
from his account preferences.


Best regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Technical details on MS Exchange vulnerabilities?

[Ángel via mailop]

On 2021-03-10 at 08:36 +, Hans-Martin Mosner via mailop wrote:
> 
> Hello,
> 
> does anyone have a pointer to technical details about the recently
> surfaced Exchange vulnerabilities? I would specifically be interested
> whether the exploit(s) depends on the server being exposed to the
> internet directly and would thus not be too critical if there's a
> Postfix internet mail gateway in front of it.
> 
> Of course, applying the available fixes should not be delayed, but
> the priority of activities could be better evaluated if it were known
> that the risk of a compromise is low due to such a configuration.
> 
> Cheers,
> Hans-Martin

Hello Hans-Martin

Many things that have been written about it. Some people reversed the
patches, other the exploits. The vulnerability itself had been
discovered by Devcore and in process of being fixed by Microsoft when
Volexity found it as being exploited in the wild, so it seems an
instance of parallel discovery.
See for instance 
https://www.praetorian.com/blog/reproducing-proxylogon-exploit/

As for your actual question, no. The vulnerabilities used were in the
HTTP interface used for OWA, EWS, etc. A server that exposed SMTP and
IMAP but not HTTP/HTTPS shouldn't have been exposed.

On the other hand, those who *had* an Exchange server published on the
internet should probably consider it compromised by now. There are
multiple groups exploiting it (in addition to whitehat scans), dropping
webshells, etc.

Note that:
* The bug is in a proxy layer, so there are multiple filenames (even
non-existing) that can be used for the attack
* Some webshells are dropped with predictable names
* ...others have random names
* Even if you don't find any webshell on manual inspection, it doesn't
mean none was added. Updating Exchange from an old version may
inadvertently remove, as it removes entire folders before recreating
them. You may want to make a copy before for inspection.
* On a default install Exchange is able to create golden tickets, thus
a compromised Exchange may lead to a compromised Active Directory


It may be a good time for everyone to review your contingency plans and
see the effort that would be needed if you had been compromised by this
and needed rebuild the whole Exchange and restore from backups.


Best regards


PS: Don't forget about the vulnerability on Microsoft DNS server
either. There are many dcs published on the internet as well.



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Hotmail and block on OVH: possible solutions alternatives?

[Ángel via mailop]

On 2021-02-25 at 20:10 +0100, Jaroslaw Rafa wrote:
> I'm not a lawyer, and of course law may differ in different countries, but I
> guess that at least in my country it can have something to do whether you are
> selling something that can be classified as "consumer goods" or not. 
> Selling groceries is definitely consumer oriented ;) while eg. selling
> aircrafts is definitely not. While selling consumer goods to anonymous
> customers is normal, I guess that if you sell an aircraft to an anonymous
> customer the authorities might have a lot of doubts about it. For selling an
> aircraft probably a contract clearly signed by both parties is required.

I suspect that may have more to do with the amount of money.
If the credit card charge was reversed and the customer got away with a
bag full of groceries, that may be acceptable, in exchange for the
convenience for all other customers, that you aren't interrogating for
hours before deciding if it's safe to sell them groceries or not.
On the other hand, if the customer disappeared with an aircraft without
even paying for it...



> I guess the same applies to such things as servers.
> Taking a common sense approach, (...)

Perhaps, although since there are so many inconsistent laws... :-/


> the ISP that provides your home Internet
> connection usually won't provide any service without having signed a contract
> where you clearly state who you are (the same applies for things like
> electricity, water etc.).

I wouldn't be so sure. Around here, I don't think it's needed. Not in
the sense you mean at least.

Technically, they know who you are (you tell them), and there *is* a
contract (nowadays generally published on their web page, or you may be
sent a copy). Whether the data provided to them is accurate or not is
another issue (surely it is, our contract says it must be!), I suspect
you could easily sign up under a pen name without them noticing, as
long as the payment succeeds.¹ Albeit I admit that may be low in their
priority list, since if they have any issue, they should have
relatively few problems for locating their users.


¹ And, crazy enough, you can sign up to pay the bills of someone else!


Cheers


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] RFCs on quoted pairs in From:?

[Ángel via mailop]

On 2021-01-29 at 14:36 -0800, Dave Crocker via mailop wrote:
> Although I showed some restraint in my earlier note, I will now point
> to 
> two specifications I put together, seeking a less hacky way of
> dealing 
> with this DMARC-generated issue:
> 
> Author Header Field
> https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/
> 
> https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/
> DMARC Use of the RFC5322.Sender Header Field

Nice. Was it intentional to publish it the day after it expired?
I love having a way to keep the actual value that should have been in
the From: header, even though it's a kludge having to add another
header because dmarc considered to bend on broken MUA, thus requiring 
everything else to rewrite the From: header and end with the "thing" we
have now.
However, despite not liking From rewriting, I find the security section
of the draft inadequate as well, Whereas dmarc authors erred by being
overly cautious not accepting mail that came through a mediator host,
adding a new header with no clear guidance would -if adopted by mail
clients- only reintroduce the same problem dmarc attempted to tackle so
zealously. People do fall for obvious email impersonations (and not-so-
obvious when using *certain* MUA which "helpfully" hide the original
email address *cough*). Attempting to add a new way to identify the
sender without definign a the threat model, acknowledging the
associated risks and providing a way to mitigate them would be wrong
and lead to a mix where each vendor would have to attempt dealing with
it on its own.

Best regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: Sendgrid again...

[Ángel via mailop]

On 2021-01-24 at 12:52 -0500, John Levine via mailop wrote:
> In article <6b96f527-0f53-494f-bb65-3e450a386...@wordtothewise.com>
> you write:
> > > Note: Some people will vehemently oppose to not placing filters,
> > > though. Some threads at RIPE anti-abuse-wg show that.
> > 
> > There are extremely valid reasons to filter mail coming into the
> > abuse mailbox and I would also argue against
> > any blanket ’this mailbox must not be filtered’ claim.
> 
> Right. There's filters and there's filters. In my experience you can
> make a pretty good first pass by looking through the message for an
> IP address or domain that you control and could do something about.
> Lacking that, it's unlikely that there's anything useful in the
> message. On the other hand, I have little sympathy for abuse desks
> that write back to my ARF reports and say opening attachments is too
> scary so send us something without them.

Note I didn't say "Thou shall not use any filtering at all". Some
moderately filtering can be acceptable. But generally abuse desk
official addresses shall have less filtering than e.g. marketing. And
particularly, they should not be filtering receiving what they sent
themselves.

I remember interacting with an abuse desk that had a pretty good
automation to automatically extract the IP address being reported in
order to pass it to the relevant customer. Too bad they didn't
recognise as theirs an IP address they owned according to the RIR (and
so automatically rejected attempts to bring that to their attention as
"not our IP")...



> > > If any, you would want to define some kind of rejection message
> > > that provided the equivalent of a "HTTP 301" so that the MTA
> > > itself could redirect it to the right mailbox.
> > 
> > That type of redirect is in the SMTP spec already. 
> 
> Yup, that's the 251 and 551 reply codes. Since they've been in the
> SMTP spec for close to 40 years and I have never seen anyone actually
> implement them (at least not in this century), I think it's safe to
> say they're not going to happen.

Yes, shame on me. I didn't immediately realize about that uncommon
reply code. Although I did notice by myself shortly thereafter.


> Laura wrote:
> > I think the right way to address this would be to include an Abuse-
> > Contact field on security.txt, which would override the default of 
> > ab...@example.com
> > Or one might define a separate abuse.txt, specially if there is a
> > need
> > for other additional abuse fields, but otherwise I think abuse
> > handling
> > is similar enough that can be included under the securitytxt
> > umbrella.
> Security is often a completely different functionality than handling
> spam complaints. 

Fair enough. It could be provided as a different txt.

Best regards



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: Sendgrid again...

[Ángel via mailop]

On 2021-01-23 at 23:56 +0100, Ángel wrote:
> If any, you would want to define some kind of rejection message that
> provided the equivalent of a "HTTP 301" so that the MTA itself could
> redirect it to the right mailbox.

And just minutes after sending this, I notice that reply code 551 is
precisely for that. Still, the rest of security considerations apply.


Nonetheless, I'm sure SendGrid could have the initial proofpoint MTA
forward ab...@sendgrid.com to a separate domain, thus avoiding Google
filters and the need of having the MTA a custom code.


Best regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] subscription bombing prevention best practices

[Ángel via mailop]

On 2021-01-21 at 12:47 +0200, Mary via mailop wrote:
> The victim of a subscription bombing attack can't do much, they
> should be careful to shift through the garbage and find the real
> threat (password changes, bank transfers, etc).
> 
> Email admins can only do manual work, because I haven't seen anything
> automated that can help in these situations.
> 
> My limited understanding, is that all forms must be protected. The
> biggest threat: headless browsers that by-pass protections like
> hidden input fields and javascript code. A realistic solution is a
> captcha, my personal preference is to avoid google's reCaptcha and
> use either a custom solution or cloudflare's hCaptcha.

The victims should create a filter rule (server-side, preferably) which
moves to a "junk subscription requests" folder (or directly deletes,
even) the subscription they receive. They are not that hard to tell
apart (generally).

rfc2369 doesn't provide a way to say "This is a subscription request
for list foo", though. This is something in which Mailing list software
could help by using a common way to signal that.

Mail systems could then react to a mailbox receiving a large number of
them in a sort time by processing them differently. Or, directly,
always move them out of the main interface and e.g. put them on a
"Mailing list subscription requests" folder, or a separate interface
about "1585 pending mailing list subscriptions".
It would also let them register which lists the user subscribed to
(with a proper interface) and based on that skip DMARC checks for
emails coming from that list.

Best regards

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: Sendgrid again...

[Ángel via mailop]

On 2021-01-22 at 18:24 +, Laura Atkins via mailop wrote:
> I think it’s a great idea. We’ve even discussed putting a RFC
> together listing this as best practice but have not found the time to
> do it. Updating / superseding  2142 or whatever RFC that is would be
> a Good Thing. 
> 
> laura

I think it should be a separate RFC about how to an abuse mailbox, or
similar, not a new version of 2142. RFC 2142 is about defining standard
role mailbox names. I would love to see a RFC saying the obviousness
that you must not block receiving at your abuse desk the mails *you*
sent. That would also be useful as argument to vendors which don't
provide any way to have an abuse mailbox skip normal rules and receive
"really bad emails".

Note: Some people will vehemently oppose to not placing filters,
though. Some threads at RIPE anti-abuse-wg show that.

That said, I'm not convinced about simply replacing "ab...@example.com"
to "ab...@abuse.example.com". That would by itself be complex for other
organizations, and nobody tells you that such system will have a
different configuration or be better managed.


And Grant proposal of an auto-reponder seems a terrible one:
> 2)  Configuring @example.net with an auto-responder (very early
> in the stack) stating to use #1.

If any, you would want to define some kind of rejection message that
provided the equivalent of a "HTTP 301" so that the MTA itself could
redirect it to the right mailbox.

Beware that the target mailbox MUST be on a subdomain (or the same
domain) as the original one. Otherwise, that allows mail bombing. This
means an organization couldn't redirect ab...@company.com to 
s...@externalvendor.com They would have to redirect to something like 
ab...@abuse.company.com with externalvendor.com providing the MX for
that subdomain.

Or, alternatively, define a mechanism by which externalvendor.com could
opt-in to receive emails redirected from company.com


All of that resulting in a too complex architecture.


I think the right way to address this would be to include an Abuse-
Contact field on security.txt, which would override the default of 
ab...@example.com
Or one might define a separate abuse.txt, specially if there is a need
for other additional abuse fields, but otherwise I think abuse handling
is similar enough that can be included under the securitytxt umbrella.

The relevant draft is at 
https://tools.ietf.org/html/draft-foudil-securitytxt-10

Best regards

Ángel

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Automatic abuse reports from Simply.com

[Ángel via mailop]

On 2021-01-16 at 19:05 +0100, Jaroslaw Rafa via mailop wrote:
> Dnia 16.01.2021 o godz. 11:48:56 Tom Sommer via mailop pisze:
> > The user IS informed that "The message has been reported
> > as Junk" as they click the button.
> 
> If they have no idea what "Junk" means, they won't understand this
> message as well.

I completely agree. "The message has been reported as Junk" could
simply mean "We have sent it to our antispam for training"

I would prefer something like:
"We have asked them to unsubscribe you and sent a complaint to the
sender for sending such message. Additionally, we will automatically
classify as spam any further email your receive from this sender"


And they better include a log in their account of adding such rules,
since, just as they "never subscribed to the email", they would
probably claim that they "never marked one of them as junk".

Think what will happen when they mark one of email from their bank as
junk meaning "I will read them later", and next time they miss a
notification that they will be increasing the commission for their
services.

If taking such stance, I would also want to make it very clear to the
customers on the spam folder:
> We marked this email as spam since you asked us to treat as spam all
> emails from "yourb...@example.com" on 2020.01.16.

and still, 8 notifications for a "dumb" end-user marking one mail as
junk seem too much (if this was a spamtrap, the assurance would be much
higher, though).

In your case, I might end up phoning the user "to ask about the 8
complaints received from Simply on their behalf, since according to our
logs, they registered on 5 August 2017 from IP 1.2.3.4", indirectly
teaching them about what they are doing each time they hit the junk
button (plus, encourage them to their support "if they have any
concerns about how their system works").


Best regards

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] openssl on Ubuntu 20.04 - implications for email

[Ángel via mailop]

SMTP uses _opportunistic_ encryption. It fails open.*
This has the unfortunate consequence that strengthening the encryption
often means to actually use no encryption at all. ☹
The client mta attempts to negotiate TLS1.2, is unable to and ends up
sending the email in plaintext, when it could have been sent using
TLS1.0 with a weaker algorithm, vulnerable to some advanced
cryptographic attacks, or in some cases with an active MITM (which it
wouldn't detect anyway, since client's don't bother verify the
certificate*).

It would have been preferable to let that go through even with a weaker
encryption. Of course, it could still be marked to the user as not
(properly) encrypted, a broken lock or whatever way you may convey that
to your users. If you do that, most providers don't report that in any
way, and users stay in their blissful ignorance (in which they are
probably happier, too).


Happy and safe 2021 to everyone


* I'm ignoring the population forcing encryption or implementing MTA-
STS.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Why 5xx? (was: GMail 550 5.1.1)

[Ángel via mailop]

For the record, here is the summary published by Google:
http://www.google.com/appsstatus/ir/4et50yp2ckm8otv.pdf

Probably already seen by most people on this list. The relevant piece
is:
> A configuration change during this migration shifted the formatting
> behavior of a service option so that it incorrectly provided an
> invalid domain name, instead of the intended "gmail.com" domain name,
> to the Google SMTP inbound service. As a result, the service
> incorrectly transformed lookups of certain email addresses ending in
> "@gmail.com" into non-existent email addresses. When the Gmail user
> accounts service checked each of these non-existent email addresses,
> the service could not detect a valid user, resulting in SMTP error
> code 550.


Merry Christmas to everyone!

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What's the point of secondary MX servers?

[Ángel via mailop]

On 2020-12-18 at 15:58 +0100, Jaroslaw Rafa via mailop wrote:
> > SendGrid. They have a webpage that says "We continue to retry
> > messages for up to 72 hours," but they (sometimes?) don't.
> 
> They do for most customers, but for some they don't.
> 
> I remember this issue with password change confirmations on Spotify,
> they were using Sendgrid at that time (don't know if still are?)

Is it a "please input this code to confirm you are the one changing
your password"? That actually makes sense. If the content of the
message is no longer needed before it gets delivered, you could skip it
(why would you queue for a week an OTP which was valid just for 5
minutes?). There is a RFC with a smtp extension for that, even. I guess
Sendgrid api may have as well a parameter to set the maximum time to
attempt delivery.

So there are a few messages which are low-value themselves and where it
is not needed to queue for a long time. For the most part, they SHOULD
be retried, though. It's not even hard to do. If you have a “dumb”
client which is not able to queue and retry itself, simply point it to
an internal MTA (assumed to be always up) and let that one take care of
communicating with the world.
Quoting rfc 5321: “the give-up time generally needs to be at least 4-5
days”

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] scam prevention

[Ángel via mailop]

On 2020-12-08 at 12:13 +, Tim Bray wrote:
> If I stripped the name, they would have seen mablecri...@gmail.com
> and hopefully noticed sooner.
> 
> Thoughts or ideas?

You would still have most of them falling when, next time, they email
you from darrensm...@bossmail.com though. :-/

I would recommend directly filtering display names matching the names
from C-level management that don't come from inside the organization.
If they wanted to use their personal well, they shouldn't. And their
employees shouldn't trust commands coming from an email outside the
org, either.


That said, I am firmly in the camp of "MUA showing only the friendly
from considered harmful".


By the way, how did the "buy amazon and google vouchers" work? That is
a new one for me. I am used to CEO fraud wanting to transfer a big
amount from the company account, not having the employees buying (with
their own money?) amazon vouchers.


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Maximum message size

[Ángel via mailop]

On 2020-10-24 at 14:38 +0100, Andrew C Aitchison via mailop wrote:
> How reliable is the SIZE value in the EHLO response ?

I would say it's reliable on how much they are able to receive.
Although it doesn't mean they are willing to send messages that big.

I was in the same boat as Adam a few months ago, and I reviewed the
sizes of common providers so I could reach an adequate size. I found
that big providers like Gmail offered big email sizes (150MB) but
actually automatically converted attachments larger than ~30MB into
Google Drive links when using the webmail interface. So the large size
stated on SIZE was a bit misleading.

Regards

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] The 'DNS only requires UDP' misconception vs SPF et al -- historical reasons?

[Ángel via mailop]

On 2020-09-30 at 11:08 +0200, Peter N. M. Hansteen via mailop wrote:
> Back in the day I suppose you could get a sort of working setup with
> UDP-only DNS, but this has me wondering, is there a quasi-rational
> historical reason for blocking 53/TCP? 

I'd say that pretty much nothing broke back in the day when blocking
udp.

> As in, was there at some point in time a 'ping of death'-like
> incident which I have either missed
> entirely or forgotten about? If there is, I look forward to some
> campfire time.

Funny that you ask this precisely the day before a dns flag day
https://dnsflagday.net/2020/#action-dns-resolver-operators

Cheers

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] United Internet X-UI-*Filterresults headers?

[Ángel via mailop]

On 2020-09-17 at 11:27 +0200, Thomas Walter wrote:
> According to the UI headers, GMX thinks these are Schroedingers Spam
> -
> they are not, but they are?
> 
> [...]
> X-Spam-Flag: NO
> X-UI-Filterresults:
> notjunk:1;V03:K0:Vf6iW93DjHQ=:AGDIE9XztBOZ9NwiPnKi2ALoF0
> [...]
> X-Spam-Flag: YES
> X-UI-Out-Filterresults:
> junk:10;V03:K0:v3J1PWV5W7c=:sJZq98Urm/hQlOiYxtZTdsBj
> [...]
> 
> Does anyone know the difference between the X-UI-Filterresults and
> the X-UI-Out-Filterresults?

Well, it seems it is only spam when sent by GMX :-)


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] STARTTLS - Constant Contact and yahoo.co.jp

[Ángel via mailop]

On 2020-08-27 at 12:25 +1200, Mark Foster via mailop wrote:
> I think the option of forcing TLS within a closed community is fine.
> I think the option of forcing TLS on the wide-wide-internet is a
> minefield for anyone who needs to communicate outside of a relatively
> closed network...

while on this topic, it would be nice if mailop mailing list started
using starttls when delivering the list emails.

Other offenders include nanog, ca/browser forum, moderncrypto.org,
several gpg mailing lists... ☹


And STARTTLS *sending* is much easier than receiving, where you at
least need a dumb certificate. Let's not start discussion on requiring
CA-signed certificates, TLS ≥ 1.2 or MTA-STS.


Interestingly, some of those servers, while not using starttls
themselves, do support it for receiving (apparently being handled by
the same host). So just a matter of (mis)configuration (?)


Maybe it's time to add a milter which automatically prepends to every
message not sent with starttls: «WARNING: This message was
NOT transmitted securely given the lack of support of example.com mail
server. It may have been seen, copied and modified in-transit in an
undetectable way.»


Cheers


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Ángel via mailop]

On 2020-08-27 at 12:22 +0200, Jaroslaw Rafa via mailop wrote:
> This is so absurd that it's even hard to find words to describe it.
> 
> And it should be - in my opinion - a reason for everyone to block all
> e-mails FROM t-online.de in return.
> Maybe such an Internet-wide block will force them to change their
> absurd policy.

Just block them with the message: "Wrong address or misconfigured
system. Your sender address is unable to receive mail."


 From your point of view, it's exactly what's happening. And for the
poor t-online client, it doesn't make sense that he's not able to send
an email to someone just because t-online doesn't know the company
address of their recipient (not that it should be their business,
either).

Regards

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] ANNOUNCEMENT: The NEW invaluement "Service Provider DNSBLs" - 1st one for Sendgrid-spams!

[Ángel via mailop]

On 2020-08-22 at 12:46 -0400, Chris via mailop wrote:
(...)
> This is, I think, the inject-to-google point:
> 
> > - IP address in X-Received header is different (first message:
> > 2002:a0c:f9cd:: ; second message: 2002:a2e:b4e1::)
> > - X-Google-DKIM-Signature, X-Gm-Message-State and X-Google-Smtp-Source
> > headers are different
> > 
> > Looks like Google duplicated this message somehow
> Right at the injection point.  Which is odd if Google has only one copy 
> in the sent box.

Not really. Do remember that gmail heavily deduplicates mail. Even if
you received an email twice (such as received directly + through a
mailing list), it will only show one in the mailbox.
In this case we are probably seeing the same thing, although in the Sent
folder.

So if Al sent the email through SMTP (as may be the case by the presence
of X-Google-Smtp-Source), and it timed out and was resent, but it was
actually accepted by gmail, it would be a classical email duplication.

On the other hand, if he was using gmail webmail UI (the @mail.gmail.com
at the Message-ID does not look like a local client), this might have
happened between two gmail servers, making it much more interesting.


Best regards


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Mailman confirmation email denial of service

[Ángel via mailop]

On 2020-08-21 at 09:23 +0200, Norbert Bollow via mailop wrote:
> On Fri, 21 Aug 2020 10:03:48 +0300 Lena wrote:
> 
> > > I have searched a few emails, but fail to see why they would be a
> > > target. Maybe only a few of them are the real targets, with other
> > > addresses being added in order to conceal those?  
> > 
> > I suspect that the bot is spamming random web-forms
> > like various bots try to spam my guestbook with ads with links.
> > If a bot sees an "email" field then it fills it with a random email
> > address.

Nope. This is not a dumb bot filling guestbooks that found mailman
subscribe forms. It is actually filling it correctly (password,
confirmation...) and, as shown below, without even fetching the page
containing the form first.


> I'm seeing the same phenomenon.
> 
> The email addresses don't seem to be entirely random though, they look
> to me as if they come from a somewhat dated list of real email addresses
> of real people (some of those email address by now being invalid).

It seems a real list of email addresses.


> For this reason I suspect that this may be done by someone whose
> “business” is email spamming.
> 
> Maybe the idea behind that bot is that filling in the "email" field
> with a real-looking email address might lead to being granted read
> access to mailing list archives which could then be scraped for email
> addresses to increase the target list for the spammer's main spam runs?

That's a good theory, but doesn't seem to hold.

In such case, I would expect the attacker to use a single (or a few)
email address, that is actually verified so it subscribes and can then
access the subscriber list.
Or at least for them to try logging in with the pending requests.

What I see is that there were a few of axios requests of the
mailman/listinfo on the morning of Aug 18 from 193.110.203.153 (DMIT
Cloud Services) and 3.23.96.118 (Amazon). And after that the requests
started. Just direct POSTs to the subscribe forms, no attempt to log in
or anything else.


On 2020-08-21 at 08:30 -0400, Chris wrote:
> I'm more wondering whether someone (allegedly) whitehat is trying to 
> populate spamtraps.

That would make no sense, imho.
First, a whitehat wouldn't be using a thousand different ip addresses to
subscribe. If they wanted to populate spamtraps, it wouldn't repeat the
email addresses. And it wouldn't be wise to subscribe a spamtrap to a
mailing list...

Regards


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Mailman confirmation email denial of service

[Ángel via mailop]

On 2020-08-19 at 19:49 +0800, Philip Paeps via mailop wrote:
> On 2020-08-19 17:51:51 (+0800), Andy Smith via mailop wrote:
> > Since yesterday I've been seeing a large number of attempted 
> > subscriptions to all the public lists on one of my Mailman servers.  
> > There's so far been 160 attempted subscriptions for 69 unique email 
> > addresses.
> 
> I see some of this on FreeBSD.org as well.  Roughly the same magnitude 
> you're seeing.
> 
> > Therefore I think it is an attack on these addresses.
> 
> This has happened before...  We have a hack in our webserver from June 
> 2018 when one specific address was being subscribed over and over and 
> over again to every single Mailman list on the internet.
> 
> > All of the subscription requests are coming in with a UserAgent of 
> > "axios/0.19.2". I have for now blocked this in my web server:
> 
> Since we're only seeing a couple of hundred of these so far, I'll hold 
> off adding yet another hack to our configuration.
> 
> Thanks for the heads-up though.  It's worth keeping an eye on these 
> things.  We run an awful lot of mailing lists and it's not very 
> difficult for a script-kiddie to cause a flood of subscription 
> confirmations.
> 
> Philip

I was going to enable the 2018 mitigations... and it turns out it they
were already active.

Quite similar as reported, around here.

It started subscribing lywlo...@gmail.com and lywlo...@gmail.com, then
mmc49...@eoopy.com on multiple lists... a total of 221 emails so far,
from 595 ip addresses... out of 601 attempts. Unlike in 2018, here each
IP is doing a single subscription, the 6 cases with two subscriptions
may have been errors... or the botnet is just so big that it is hard to
be hit twice by the same IP.

All of them with User-Agent axios/0.19.2, and password 123456789.

$   while read email; do printf "%s" "$email" | md5sum; done < 
bademails.txt | cut -d\  -f 1 | sort
002e30ac2ab27d71e1537732bf5ec06a
01869f4f35ce0169312f3773497a29a4
02d759ac00b28334a5a27c7d4966fa0c
02edcda251d2bef9ff972d37e1b1a470
05ece2f3adfc85a71b784026e3ba5ef6
05f6395601d880499c8d074cb905e488
06ed53c37ed98e38c0e876e86eade551
0936c0d3b570f0845537de1eb9789a37
0fdfc7478c5ac8e6635b6eac845c86ec
10e07e9a1678d5d6a0cea12734bc2823
10ed518cc851aef9196a566d916961b6
1183d56764138d6dc62cc74eec9a571c
1339e82134c0da41a0d4e47e09ccfa11
150a67ba3a5e7a6a12ef70c45a24d189
166fcf0be322450a6431697b8824051e
1c9b9e0119c5ef975b69e9d13a63f6c9
1cfd2b74651e1c46b3d13cb38f11de30
1e37bafb524d678656f593b59240d9a4
2011f3d0d441fa7534126c5e6edd8e14
21345e3154d27a2b642410c6b85289ad
2286806547c7582aac75e037d564227e
23dccee843269d1dac84efe85d62e214
258ac25d939fc72cf35634b2773ff411
25ced9c6e47f90a2bd2d9ae4181f533f
2612d28cc89294aae069f3bdf4ae0bc7
2715a83b40bcf10d387c1add8bdb619f
27365a99b33910fed10d4304699b71aa
273b30472e9e7b0b59efb2573d9fb727
2751f0387dc5a6d75eacf544a075bfcb
285b450cc4d8eb088076eebb187ef915
28c418777878725215d280932f41ed47
2d57169596ea4ea49cbffb8dc8c91223
2dbafdfd2ea79d3ac3697daebda904b8
2e7d2f439f0d1ec2f1d9cc3ced65cf93
2f2017437f26632e41e0925a9b706b26
3030407a3a897cb79e2ed350866cc4f0
32568053ec7363187f4ec2dce9b2eecb
33e8f72c55972a3abd99ed6bbb275908
345cdc708b26d9c8f249e74384da
34b96e820067c0cfa56844279da3346b
34f2db2fbae6c6382102dd73444b4be6
3620b93fdf92223edaf36ee0d3dd7f79
373e1389bade3ef9bde30af1a2e4cd9e
3883f3370a534d9f51a4ad31c1b2fdf6
3adf1219508b9a69ef105624fb4a5d55
3afc3fa87ed45ced11359875d973ec30
3b8ff7c3f576f70adeedc38bb6570647
3c0cdcd022b28fae5a28f2c4ad799809
3c66cbd60de11f908732c7f095ee1b2a
3cb5d22552452b0148e87a3cb7c431f3
3daf65621edfa550913ba9f303bea6fc
3f329e034df78e15f13584e15255bb7a
3fbd6905b994a8b1908b2962afcd6a30
3ff6cc239738381c27a6f9cea546e779
40fdb2046825752098c490b0eecdf555
41470b171265f99895c6685b11047293
42cdb74a12513003d21e4f3411353f32
4412e075e9c3fd688456d4434418cadf
446364bc5884447e8b8aea233f7ae0bc
46939f2aaa3180a3c4d542d79f1ff828
47989c863bd591b7a8194eded00b0640
483030240284df5f3738a5375476182c
4a83ba5393ed329c6f3488cf8d872e61
4b1706c92ff7efb75fddbbccc1f20072
4c9778d8aa5bb9aaddcd6460d659a33a
4d0824627a77acfcf40cecbf90c66b2f
4d7fae798d142bef3b4d2ebb8df9e9b5
4f52792917af2ba8067344b275187ae3
4f88b267e125087b131a974de25eb39e
4fd4978b6fe1532e15c6065639f250f9
50629cf1e4bc58633f4f3448628819eb
510c89c867efa31d55354e7b4027c27f
5154726cd05db33ada39c0abbeec0103
51a4191cb35015b438325f64bd4b1d24
52c6674d6210a7fcb358a3369adb95f1
5402c9a8bcc42efa2667d3a43bd67078
54d12876511dcf424a55ba881b69cfa2
565afdcca629c972dbdb8a9e2198f4d6
56874f5e5aeb1b2c30987e0673cc4b28
56e4686325fd036bee6b088269d2ab8a
589e059fb25db3ecda9bfe76e08b3957
5aab3f1589ed4de4378c0d1782896f89
5ab5cec75772fb57216430e7af21f7f7
5d5689280c01513535af513a91414e57
5d8bb463bb35d5128c745f2a0c6be1ea
607cd521764bba22f60490c70a3e7d86
60ea5da2b15b5a6aa841daa02748c707
61ad1a9fa444ef82f3b69176a3ab
621ddceaf6597852c759972182c4f2b0
624d5a603eb66d76983c5a142141d13e
63315dede090d0a8b5d81f00fd706a2b
636e733b271e235f93ce7d6ccb884c5d
63fa3f8f27ea3071ece02172ba18ccf3

Re: [mailop] Just how does SendGrid fail this badly?

[Ángel via mailop]

On 2020-08-20 at 09:35 +0200, Hans-Martin Mosner via mailop wrote:
> Am 20.08.20 um 09:10 schrieb Benoit Panizzon via mailop:
> >
> > Return-Path: 
> >
> > Does the c581 part also belong to the account id?
> No, it's a short hash to verify that bounces were indeed caused by
> mails actually sent from sendgrid. For example,
>  and  +6019856-0d96-@sg.e.doodle.com> are doodle notifications
> sent to two different mail addresses. I don't know whether the time
> also takes part in the hash computation (as in SRS).

I see the same later part when the destination is the same recipient,
hours and even months later, so the time isn't computed there.
I thought that it might be an index of the "subscriber" into the
customer list.

The same account, spammed by different sendgrid accounts, has different
suffixes, but that's not surprising.

I don't get much sendgrid spam when compared with other people, but
today it was quite prolific:

17045745 - "you have been gifted $5 MILLION USD From Mr. Bill Gates" +
"CONGRATULATION TO YOU" (20 Italian billionaries donating money)
9364509 - "To prevent your email from closing, please verify your account 
details below"
13001617 - This is a plain-spam account. Today it was for
recharge-mobile.co spam, which mixes with a shop of earrings, bracelets, etc. 


Best regards


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] New SendGrid IP(s) detected sending phishing last 24 hours..

[Ángel via mailop]

On 2020-08-12 at 14:38 -0700, Michael Peddemors via mailop wrote:
> the phishing, don't even want to see that there, 
> because end users will STILL click on phish bait, even in the spam 
> folders sometimes ;)
> 
> Doesn't matter HOW big the sender is.. When you are a billion dollar 
> company, you should be held responsible for what leaves your network..
> IMHO

It would be interesting to watch if one of those ended up in a suit
against Sendgrid. I would generally not consider an ESP liable for
everything that is sent by their customers (specially when there are
also account compromises into the mix), but in this case they might have
a hard time showing that they were unaware of these issues or that they
were doing proper diligence (particularly since the original sender will
probably not be found to be charged).



> by the time they do though at this rate, their legit 
> customers will have spoken with their pocket book..

You mean... they might not like a banner above their emails saying that
recently there have been malicious emails received from that sender?
What a surprise!


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Delisting request from sendgrid customer about ip used in recent phishing campaign.

[Ángel via mailop]

On 2020-08-13 at 18:27 +0200, Hans-Martin Mosner via mailop wrote:
> The first thing you need to do is to know your customers. Don't send
> out mails on behalf of someone you don't really know, period.
> 
> 
> Apparently some customers themselves are victims of hacks now, so that
> alone would not help. Additional technical steps to be taken are
> limiting the names and domains that may appear in the From: header
> lines to fixed lists (maybe restrictive regular expression patterns)
> per customer, and limit the IP ranges from where each customer may
> inject mails. Some customers seem to employ auto-mailing from web
> forms. Sorry, that was a nice idea a decade ago, it's not anymore. Web
> subscriptions and inquiries should be checked and followed up by a
> human or at least some pretty well trained AI engine.
> 

I don't think it's rocket science.
As an ESP, you have a series of customers.
For each customer, you should have a table of their validated domains
(you do have a process for validating domains, right?).

Each customer must place and shall only place in their From: header
emails in one of their validated domains.

Prior to sending a campaign, the SPF and DKIM records must be checked.

- The domain spf when sent by the ESP MUST pass  to send it (that could
be via a generic include, by specifically including an ip address that
was pre-assigned for this campaign...)
- The ESP SHOULD be able to place a DKIM signature for the given domain.

It's included in the prior steps, but worth mentioning explictely
anyway. If the domain does not exist, or the SPF would now fail, it MUST
NOT be sent. Even if the domain was previously authorized (e.g. the
company could have validated that domain years before, but now they
might have changed their mind - the domain may even be owned by a
completely different entity, now!), the failing spf record is an
explicit signal not allowing them to perform such sending.

This is not only in the benefit of the ESP and to avoid phishings, but
to the customer as well. A campaign failing such validations is very
likely to have a poor inbox rate. The ESP must block that, and get that
customer (a marketing guy with zero idea about mail delivery, probably)
to get their IT people to add the needed records. Through whatever
internal procedures are needed.


Just this would already prevent the most egregious cases suffered last
months. And as you see, it's really simple.

As Hans mentions, you may want to add the same limitation that href in
the email body must be linked to the accounts, although you may want
some more leeway there, such as allowing anyone certain neutral sites,
like common newspapers (did you see the last piece of news about our
company?).


Compromised accounts are a problem, sure. However, I wonder *how* are
they such a big problem.
Did Sendgrid somehow lose a full list of customer users & passwords? Do
their api allow easily bruteforcing them?

If a customer loses his user and password, yes, they could send a
mailing. As their own company. (Hopefully) damaging their own image. Not
hurting other customers, or third parties that never allowed you to send
emails impersonating them.


You will obviously want to do much more on the validation step. Like, if
someone registered paypal-mails.com, different than PayPal Holdings,
Inc., and tried to set up a campaign, imho it should be rejected.


Also, an ESP must be able to properly handle abuse. When abuse is
reported, it shall be properly handled and acknowledged. If there is
information missing, ask about it. If the customer has been found to be
in violations of the Terms (such as sending the obvious phishings), they
should be able to one-click block the customer.
If the account was compromised, that can be handled later. It's best to
let before it makes more harm.
Then, after taking proper action, reply to the report. It can be a
simple one-liner: "Customer blocked", "We already disabled that account
a few hours ago", "We could not verify this to be abusive"...


These things should be a good starting point to get started and gain
back some of the community trust.


Best regards


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Extreme multiple posting (was Re: OVH Bulk Mailer? Anyone know this one?)

[Ángel via mailop]

On 2020-08-07 at 20:24 +0200, Renaud Allard via mailop wrote:
> 
> On 05/08/2020 20:16, Large Hadron Collider via mailop wrote:
> > you know, Mr Allard, it appears that you sent this message to the list at 
> > least 5 times...
> > 
> 
> Actually, I only sent it once. From my logs, it was delivered on the 5th 
> once. It might be some processing problem at mailop because I only 
> received it today (once) like multiple other mails from mailop.

It's fun that we got multiple copies on *different* messages. In my case,
it was on the ones from Umut Alemdar 
(am6pr08mb5158c5d0677d418f254e7a16db...@am6pr08mb5158.eurprd08.prod.outlook.com),
Lily Crowley 
(cabpqdsmwn_r9q9mmzkuizfgfmnh0fcbdvtigtc8codcm6lz...@mail.gmail.com),
Stephen Frost (20200805132959.gd12...@tamriel.snowman.net), Hans-Martin
Mosner (173bec91138.2771.03b21a1406dc7ce0e2b3b53a52883...@heeg.de) and
Otto J. Makela mails (b05c8075-fbf9-1c87-3322-2b5eb7a94...@iki.fi). I
received 38 copies of each (except Stephen's which were 39).


Message 173bec91138.2771.03b21a1406dc7ce0e2b3b53a52883...@heeg.de,
 Received: from chilli.nosignal.org (213.138.100.131:):
 Thu, 6 Aug 2020 18:35:12 +
 Thu, 6 Aug 2020 19:08:58 +
 Thu, 6 Aug 2020 19:34:40 +
 Thu, 6 Aug 2020 20:04:28 +
 Thu, 6 Aug 2020 20:37:50 +
 Thu, 6 Aug 2020 21:03:58 +
 Thu, 6 Aug 2020 21:34:46 +
 Thu, 6 Aug 2020 22:15:53 +
 Thu, 6 Aug 2020 22:34:33 +
 Thu, 6 Aug 2020 23:04:19 +
 Thu, 6 Aug 2020 23:33:57 +
 Fri, 7 Aug 2020 00:04:16 +
 Fri, 7 Aug 2020 00:34:07 +
 Fri, 7 Aug 2020 01:07:51 +
 Fri, 7 Aug 2020 01:34:41 +
 Fri, 7 Aug 2020 02:04:34 +
 Fri, 7 Aug 2020 02:38:08 +
 Fri, 7 Aug 2020 03:04:14 +
 Fri, 7 Aug 2020 03:38:15 +
 Fri, 7 Aug 2020 04:04:13 +
 Fri, 7 Aug 2020 04:34:34 +
 Fri, 7 Aug 2020 05:05:17 +
 Fri, 7 Aug 2020 05:36:07 +
 Fri, 7 Aug 2020 06:09:18 +
 Fri, 7 Aug 2020 06:34:16 +
 Fri, 7 Aug 2020 07:20:24 +
 Fri, 7 Aug 2020 07:34:53 +
 Fri, 7 Aug 2020 08:05:06 +
 Fri, 7 Aug 2020 08:34:19 +
 Fri, 7 Aug 2020 09:04:00 +
 Fri, 7 Aug 2020 09:34:34 +
 Fri, 7 Aug 2020 10:04:14 +
 Fri, 7 Aug 2020 10:34:29 +
 Fri, 7 Aug 2020 11:04:39 +
 Fri, 7 Aug 2020 11:34:43 +
 Fri, 7 Aug 2020 12:04:08 +
 Fri, 7 Aug 2020 12:27:33 +
 Fri, 7 Aug 2020 12:30:27 +

Message b05c8075-fbf9-1c87-3322-2b5eb7a94...@iki.fi,
 Received: from chilli.nosignal.org (213.138.100.131:):

 Thu, 6 Aug 2020 18:35:56 +
 Thu, 6 Aug 2020 19:08:52 +
 Thu, 6 Aug 2020 19:39:06 +
 Thu, 6 Aug 2020 20:08:37 +
 Thu, 6 Aug 2020 20:38:33 +
 Thu, 6 Aug 2020 21:04:51 +
 Thu, 6 Aug 2020 21:33:51 +
 Thu, 6 Aug 2020 22:16:05 +
 Thu, 6 Aug 2020 22:34:15 +
 Thu, 6 Aug 2020 23:05:00 +
 Thu, 6 Aug 2020 23:35:02 +
 Fri, 7 Aug 2020 00:07:58 +
 Fri, 7 Aug 2020 00:35:03 +
 Fri, 7 Aug 2020 01:07:45 +
 Fri, 7 Aug 2020 01:34:55 +
 Fri, 7 Aug 2020 02:04:19 +
 Fri, 7 Aug 2020 02:34:56 +
 Fri, 7 Aug 2020 03:03:46 +
 Fri, 7 Aug 2020 03:35:16 +
 Fri, 7 Aug 2020 04:08:22 +
 Fri, 7 Aug 2020 04:34:10 +
 Fri, 7 Aug 2020 05:14:52 +
 Fri, 7 Aug 2020 05:36:53 +
 Fri, 7 Aug 2020 06:04:48 +
 Fri, 7 Aug 2020 06:44:16 +
 Fri, 7 Aug 2020 07:18:22 +
 Fri, 7 Aug 2020 07:34:21 +
 Fri, 7 Aug 2020 08:10:19 +
 Fri, 7 Aug 2020 08:35:30 +
 Fri, 7 Aug 2020 09:05:18 +
 Fri, 7 Aug 2020 09:34:49 +
 Fri, 7 Aug 2020 10:05:10 +
 Fri, 7 Aug 2020 10:33:46 +
 Fri, 7 Aug 2020 11:05:09 +
 Fri, 7 Aug 2020 11:34:52 +
 Fri, 7 Aug 2020 12:05:07 +
 Fri, 7 Aug 2020 12:28:25 +
 Fri, 7 Aug 2020 12:30:46 +



Best regards



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Rolling DKIM Key Disclosure

[Ángel via mailop]

On 2020-07-11 at 15:27 -0400, Matt Corallo via mailop wrote:
> "Sorry, I think what you're looking for isnt useful, you're misinformed" 
> isn't exactly a useful response when someone,
> especially a customer, asks for something, sadly.


Your customer should detail their threat model, so that they can be
given a solution suited to their needs. You don't implement the same
solution to "protect your files" if your threat is the cat walking over
the keyboard or spies from a foreign country.


I would suggest DKIM-signing the headers but not the email body (i.e.
use l=0), perhaps not even including the Subject.

This, way your customer could send an email saying:
> We have agreed that it's dangerous to the Don and our Family to let
> Sollozzo live. Will you help us to kill him?

and then argue that the email really said:
> We are very worried about a possible confrontation and only want the
> peace between all parties.


the origin and recipients of the email will appear on many email logs,
so it'd probably be pointless to hide them. You could go as far as to
only sign the Message-Id if you wanted, though.


Anyway, it's likely than 5 minutes after that, the other party replied
saying "We won't interfere with that" and quoting your full email.
DKIM-signed by Office 365.


Regards



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop