Re: [mailop] Large Volume of Emails in Violation of Acceptable Use Policies

[Richard Clayton via mailop]

In message , Ferris,
Rhys (SCC) via mailop  writes

>In the last 24 hours we have received 693,937 emails 
>from select freemail domains with top senders having sent between 500 and 800 
>emails in a single day. This has been ongoing and in the last 30 days we have 
>received 23,196,000+ emails from selected freemail domains.

Raising this issue here is not the way forward, in my personal view

If a complaint is to be made about too many repetitive emails from a
particular sender then the recipient needs to make that complaint to an
appropriate abuse team who will then assess whether to take action.

Postmasters (who inhabit this list) are not usually in a position to see
the content of emails passing through their systems and so although they
can tell that many emails are being sent they cannot tell whether they
are all the same or, perhaps part of an ongoing conversation. Hence they
will find it difficult to know (rather than guess) what is going on.

Note that sending many emails from an automated system is not
necessarily abusive -- otherwise security cameras and cron jobs would
not be allowed to function as they do -- but if someone is sending, say,
100 emails a day (to make essentially the same argument every time) to
many different senators then that does not seem reasonable activity to
me. If any of the senators wish to complain (rather than filter or
reject the traffic) then I expect that many if not all abuse teams would
take some appropriate action.

Should you have lots of recipients in the same position then you could
make a complaint on behalf of a group of them, but note how you need to
be able to discuss the content of the emails to make your case.

Finally, you may be seeing X emails per time period from Y people. If X
is large then making an abuse complaint is straightforward -- even if Y
is large. A competent abuse team ought to be able to cope with one
complaint giving the details of all Y senders.

If X is small and Y is large and you suspect that the sending accounts
are under the control of a single person then that you can make an abuse
report about that as well. However, you will appreciate that is harder
for recipients to identify that this is what is occurring, albeit the
abuse team should have appropriate tooling to identify "mass reg" and
that will almost certainly lead to accounts being shut down.

-- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] How to respond to a subscription attack

[Richard Clayton via mailop]

In message <484dfe5a-71e7-4851-8de0-fe35342cff97@spamtrap.tnetconsulting
.net>, Grant Taylor via mailop  writes

>Is there any value in contacting postmaster@ / abuse@ for senders that 
>participated in a mass subscription bomb attack?

this is "list bombing" and is done to simply annoy, or more often to
hide some other message (about an unusual login, or money (or domain!)
transfer) ... some simple advice to a victim is to check their Amazon
(etc) order status...

>I've got a user that received almost 1k subscription / welcome / 
>confirmation messages over a period of about 30 minutes before I 
>disabled the account (hopefully temporarily).

that could mean they don't see the message which the attacker hoped to
hide in the general mess -- viz: it's not the best approach IMO

>As such, I've got a corpus of ~1k messages that appear to be 
>semi-legitimate at a quick glance.

you could complain to the senders .. people who still have sign-up
webpages and similar which don't have CAPTCHAs (or other tricks) to
avoid robotic usage need to have the issue drawn to their attention

depends how public spirited you feel !

-- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Debugging fwd issue meta.com to zoho.com (Help from user under meta.com needed)

[Richard Clayton via mailop]

In message ,
Tobias Fiebig via mailop  writes

>My point here is, that 'deliverability' is often more of a priority for

>ESPs than 'following all documents to the letter'. Granted, for the

>bigger ones, usually more like 'outbound deliverability' than 'inbound

>deliverability', though.

>
>Hence, I am not completely sure if the stance is outright unreasonable,

>even if it disagrees with the documents.

If you send an encoded DKIM header field then it is rather unlikely that
large mailbox providers will parse it correctly (I don't think they run
rpamd) or indeed at all.

Failure to get a "DKIM pass" may well mean that "no auth no entry"
(recall that 1 Feb was a while back) will kick in and your
deliverability will be zero.

The likelihood of getting an error message that illuminates the (rather
obscure) cause of the deliverability failure is zero.

Recall that the first thing Postel said was "be conservative in what you
send".

BTW: RFC2047 encoding the bit in the angle brackets in the RFC5322 From
(which a non-zero number of senders were doing, last I looked at
$DAYJOB$ data) will also mean no deliverability (albeit some of the
error messages you get for that may lead you to your formatting problem
relatively quickly).

-- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mailbox Filling w. Opt-In/Sign-Up mails

[Richard Clayton via mailop]

In message <6104b9876b594050d36ca90ca6a169cda7a8e684.ca...@fiebig.nl>,
Tobias Fiebig via mailop  writes

>A bit of digging found several end-user reports of the following MO:
>
>- Get phished
>- Something expensive is bought
>- Mailbox is overflown right when the notification of the transaction
>comes, likely in a bid to hide the illicit purchase
>
>Naturally, there now have been some 'adjustments' to the service to
>make sure it no longer contributes to that... and maybe finds some
>insight into what is happening there... *loglog*
>
>However, I'd be interested in hearing whether I had just missed some
>very common spam reason here; So:
>
>- Did somebody else stumble over this in the past and/or did i simply
>miss this being a thing?

you have not been paying attention ... it's called list-bombing (Google
will find you many references)

it dates from 2017 or so ... here's an early high-viz example



>- How is this handled for, e.g., all the other tools that allow
>generating "a lot" of mail only needing a request

If you have forms ... add CAPTCHAs or randomize the form field entry
names (every time they are displayed)

-- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DKIM validity period (anti-forgery vs. anti-spying)

[Richard Clayton via mailop]

In message <65860e95.20895.448c...@postmaster.inter-corporate.com>,
Randolf Richardson, Postmaster via mailop  writes

>   Would you mind sending me a linjk to your thesis?  That's an 
>interesting topic, and based on what you've written I get the 
>impression that you have a lot more experience than I do.

I'm just old :)

https://letmegooglethat.com/?q=richard+clayton+phd+thesis+traceability

-- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DKIM validity period (anti-forgery vs. anti-spying)

[Richard Clayton via mailop]

In message <6585e535.11582.3a72...@postmaster.inter-corporate.com>,
Randolf Richardson, Postmaster via mailop  writes

>> The most commonly seen method of tracking is probably inclusion of
>> specifically crafted links in the message, that refer to a tracking server
>> run by the sender, so the sender knows if the recipient clicked on a link in
>> the message.
>
>   You're entirely correct -- thanks for adding this as I wasn't even 
>thinking of it.

ask most any ESP .. this works poorly these days, robots click on the
links to make sure they are safe and mailbox provides pre-fetch images
for reasons of performance, safety and (tada !) to make tracking harder 

>> >Some of our clients are investigators, lawyers, etc., who 
>> > occasionally need high quality (read "reliable") evidence for the 
>> > cases they're working on.  DKIM, when available, makes it easier to 
>> > authenticate eMail evidence in a way that can satisfy these needs.

people who speculate about lawyers need are generally not lawyers. I've
been an expert witness on email related cases often enough to know that
they are often perfectly satisfied to have a description of a well-
formed set of Received header fields...

... usual quote : if you think cryptography solves your problem then you
don't understand cryptography and you don't understand your problem

Investigators are even less interested in proof, they're reading all the
headers, checking DNS records and jumping to (usually plausible)
conclusions !

>   Some of the investigators I've dealt with neededd to deal with this 
>specific scnario where someone denied sending an eMail.  Although 
>DKIM can help, if the server logs haven't cycled out yet then an 
>affirmed affidavit that the mail server log entries are authentic has 
>almost always been sufficient for motivating the denying party to 
>suddenly remember that they did send the message.

exactly ... (remember civil cases work on the balance of
probabilities).. and also remember that there is account takeover,
people in your household who know your passwords better than you do and
that's before you get into all the BGP, NTP etc exotica  (if that
interests you then I once wrote a PhD thesis on all the assumptions we
make about "traceability" and the circumstances in which they go wrong)

-- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Convincing clients of the importance of eMail recipient consent for mailing list subscriptions

[Richard Clayton via mailop]

In message , Byron Lunz via mailop  writes

>We've required confirmed-opt-in for years. But a few months ago, I noticed
>that our servers were sending out hundreds of 'confirmation required'
>messages every day. They were going to obviously-bogus addresses, likely
>submitted to our submission forms by bots. Without opt-in, all those bogus
>addresses would be on our lists, inflating subscriber count, increasing
>bounces, lowering server reputation, etc. As it was, even just the hundreds
>of confirmation messages were beginning to impact server reputation, to the
>point that I added simple 'captcha' tests which require a human response,
>just to eliminate the bogus confirmation messages.

you should be doing that anyway to prevent "list bombing" attacks (where
you, and many others, send emails to a victim (who has been impersonated
by a robot) to swamp their mailbox so as to hide transactional email
that would reveal an active fraud)

the likely reason for sign-ups from clearly mass-registered addresses is
that the bots wish to have valid email coming in to their inboxes to
persuade machine-learning models that the account is valid and not mass-
registered for nefarious purposes

> Even after THAT, I find
>that maybe 25-50% of the folks who ask to subscribe never respond to the
>confirmation email.

the ML models may have got their first and removed the account

-- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Success MiTM attack

[Richard Clayton via mailop]

In message , Matt
Corallo via mailop  writes
>
>
>On 10/23/23 3:26 AM, Jaroslaw Rafa via mailop wrote:

>> However, all this discussion is hardly related to email, as - as many have
>> noted - there's hardly any certificate checking at all between MTAs.
>
>Indeed, MTAs mostly use DNSSEC/DANE which would have prevented this issue 
>entirely! MUAs much less 
>so, however.

I see nearly 100 MTA-STS reports (including most large mailbox
providers) every day ... that's about doubled over a year


-- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Success MiTM attack

[Richard Clayton via mailop]

In message <07d58480-7dde-4d15-a5ca-5bb6c8e10...@mtasv.net>, Matt Palmer
via mailop  writes

>The relative "noisiness" of the attack, in fact, is a fairly strong signal
>that it *isn't* lawful intercept; western law enforcement agencies are
>typically very hesitant to do anything that could "tip off" the target of
>their investigation.

In my, perhaps jaundiced, view the revelation of the attack (an expired
cert) suggests that it was indeed LI ... it's the sort of thing that
goes wrong with ad hoc arrangements.

You might recall (to bring this back to email) that in his book 'The Big
Breach' Richard Tomlinson revealed that he had discovered that his email
was being intercepted because the Italians had rigged a server to send a
copy of emails sent to him to their mailbox ... and one weekend that
mailbox filled and everyone got a "bounce" as the extra copy failed to
be delivered ...

-- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Richard Clayton via mailop]

In message <56b83491-6441-4d1e-a3ef-008da3311...@slavino.sk>, Slavko via
mailop  writes

>When spammers are able to create proper DNS records directly used
>in email authentification, what problem will be the SOA record for them?

In order to have a domain with an SOA record they have to purchase a
domain (and provide a DNS service for it) ... and when that domain falls
in reputation they have to buy another one ... (and yes there are free
domains out there but they start off with a poor reputation!)

If an SOA is not required (and other mailbox providers have other ways
of testing that domains actually exist) then n-character-random-
string.respectable-tld can be used as a domain and every spam email will
have a domain with a neutral reputation

-- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Richard Clayton via mailop]

In message <601b01c7-1475-32e0-5aba-e595272e9...@tnetconsulting.net>,
Grant Taylor via mailop  writes

>My concern is that Yahoo / AOL isn't creating an arbitrary "every domain 
>must have an SOA record" and completely loosing sight of the fact that 
>SOAs belong to the /zone/ apex and are not associated with /domain/s.

One more time ... I can see two people have already explained this
clearly, but perhaps three's a charm ?

The check is whether there is an SOA record for the domain used in the
RFC5321 MAIL FROM. If there is not, then a check is made for an SOA for
the administrative domain (using the DMARC approach to determining the
administrative domain which involves consulting the Public Suffix List).

So if you use a.b.c.tld then the check will be for an SOA for a.b.c.tld
(which in many cases would not exist) and then for an SOA on c.tld

What is turning out to be problematic for some people is that "tld" is
any entry on the PSL -- so, to take the recent example when the MAIL
FROM is a.b.c.or.us then because or.us is on the PSL then checks will be
made for an SOA at a.b.c.or.us and then for c.or.us

If it is problematic then as Marcel pointed out, the postmaster team at
Yahoo are pleased to help.

It does seem to me (viz: this is a personal opinion and not that of
$DAYJOB) that some entries have been put onto the PSL by people who do
not fully understand that they are declaring "treat this as a TLD"
without thinking through all of the implications for cookies, for DMARC
and for anyone who is trying to understand whether a domain exists or
has merely been invented by a spammer -- so that every email they send
can evade domain-based reputation systems.

-- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Richard Clayton via mailop]

In message <20230709223922.dd59afd9f...@ary.qy>, John Levine via mailop
 writes

>A friend of mine wants to set up a mail server on a VPS and asked me what
>he needs to do beyond the obvious setting up postfix and dovecot.  Is there
>a good summary somewhere?

not that I know of -- arguably there should be one, but perhaps it will
just encourage unwise activity. I am reminded of Usenet advice of not
posting for the first six months and if you ask why that is good advice
then add another six months...

I recently reviewed an IETF draft on (de)centralisation which observed
that running your own mail system, rather than using a centralised
provider was far too hard. In discussions with Eliot Lear we ended up
with a list of things you had to do:

* configure and manage the MTA

* arrange for a backup MTA

* manage DNS MX, DKIM, DMARC and SPF records

* manage reverse lookup records, including managing the uncertain chain
   of authority between the instance and the nearest SOA

* manage certificates associated with TLS for SMTP and IMAP

* manage DKIM certificate

* manage one's upstream to address PBL issues

* keep the MTA secure and free from DOS attack

>I'm thinking of things like:
>
>- choose a provider that has decent mail behavior, e.g., not Digital Ocean
>
>- make sure the MTA's forward and reverse DNS match
>
>- set up an SPF record, probably "v=spf1 mx ~all"
>
>- set up DKIM signing for each domain you host, make the
>DKIM domain match the From: domain
>
>= start slow and look at any bounces
>
>- maybe collect DMARC stats but for a small volume MTA, not very interesting

ALSO back in 2011 (when the world was a little simpler perhaps) I worked
on a M3AAWG BCP on this topic -- which eventually went nowhere ... the
list then was (and I stress this was not sufficiently peer reviewed then
to be authoritative, but it was written by some experts)

* Use a static IPv4 address for your email system

* Do not share this IPv4 address with user machines

* Do not host your email system 'in the cloud'

* Make sure that your IP address is not listed in the PBL

* Provide an MX record

* Provide meaningful and consistent reverse DNS

* Your system should say HELO (or EHLO) with its hostname

* Keep your software completely up-to-date

* Ensure that only authorised users can send email through your system. 

* Limit outgoing email volumes

* Accept reports of problems with your systems

* Review the mail system logs on a regular basis

* Be reliable (viz have at least 4 9s availability)

* Don't be an open relay

* Don't create backscatter

* Maintain a good reputation

-- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop