Re: [mailop] Phishing hosted by Cloudflare-ipfs.com / Abuse Handled by Sparkpostmail.com?

[Hans-Martin Mosner via mailop]

IPFS is a p2p file storage, so cloudflare doesn't control what content is put 
there, they don't even know who put it there, so it's a natural extension of 
their "we're not responsible, it's our customer's responsibility, but we won't 
tell you who that customer is" policy.

I chose to reject all IPFS URLs. If people have a legitimate use for 
them,they'll have to tell me so I make an exception for them.

Cheers,
Hans-Martin



May 13, 2024 at 5:04 PM, "Benoit Panizzon via mailop"  wrote:



> 
> Hi all
> 
> Our customers increasingly get phishing emails targeting our email
> platform accessible under the domain: Cloudflare-ipfs.com
> (interplanetary file system, I guess that is their name for CNS).
> 
> I reported some of those to the cloudflare abuse desk.
> 
> To my surprise, after usually 1 or two days I get a replies From:
> "Cloudflare"  about them blocking some of the
> single URL we report.
> 
> So is sparkpostmail.com linked to cloudflare?
> 
> Unfortunately the basic issue is not being addressed. The phishers
> seem to be able to generate new URI under cloudflare-ipfs.com much
> faster than ab...@spakpostmail.com is able to block them.
> 
> Even SpamAssassin now has a rule matching those:
> 
> URI_CLOUDFLAREIPFS References Interplanetary File System PtP
>  content via CloudFlare, likely phishing
> 
> Mit freundlichen Grüssen
> 
> -Benoît Panizzon-
> -- 
> I m p r o W a r e A G - Leiter Commerce Kunden
> __
> 
> Zurlindenstrasse 29 Tel +41 61 826 93 00
> CH-4133 Pratteln Fax +41 61 826 93 01
> Schweiz Web http://www.imp.ch/
> __
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.

[Hans-Martin Mosner via mailop]

Am 17.03.24 um 14:05 schrieb Jaroslaw Rafa via mailop:

Dnia 17.03.2024 o godz. 08:30:39 Hans-Martin Mosner via mailop pisze:

does IPv6 (not exclusively though), and I've been trying to usher in
the future by setting up at least dual stack on my home DSL
connection (that at least works now after years of IPv6 routing
issues with my previous home DSL and no way of contacting tech-savvy
support there) and in our company (where I set up an IPv6 tunnel
which worked until the tunnel provider closed shop).

I don't quite understand what exactly the end user has to do to have dual
stack on his home connection. The ISP either provides IPv6 to you or not,
there's nothing to do for you.
Well when I first did it my provider had no IPv6 so I used a tunnel. And even now I have to enable it in my router, 
otherwise I get only IPv4. So I didn't have to do much, but it also didn't happen magically.


My current ISP (BTW, one of the biggest cable providers in Europe, you can
probably guess which one it is) currently provides by default an IPv6 *only*
connection to the home users, even if you have IPv4-only devices in your
LAN. They use the solution called DS-Lite: the modem/router they lease to
you does an IPv4-over-IPv6 tunnel(!) to some point inside the ISP's network,
where the packet is decapsulated, a CG-NAT is done to some public IPv4
address and the connection continues via IPv4 to the target address. IPv6
connections just pass through unchanged.


I would prefer to avoid going through a NAT, but for most home users this is 
probably not an issue.

My point is mostly that it's quite possible to get IPv6 if you want, most small or medium organizations just don't have 
the expertise to do it, and the providers are not very helpful.


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.

[Hans-Martin Mosner via mailop]

Am 17.03.24 um 04:23 schrieb Jarland Donnell via mailop:

I'm gonna be "that guy" though for a minute.

If there are any IPv6 only mail servers, they are hobbyists trying to prove a point. There are a ton of IPv4 only mail 
servers. In short, there is no benefit to sending mail over IPv6 beyond the ideological preference some people have 
for feeling like they're ushering in the future. A future they've been predicting would arrive any day now for well 
over a decade. 


Well I might suppose I'm one of those. My personal web/mail server does IPv6 (not exclusively though), and I've been 
trying to usher in the future by setting up at least dual stack on my home DSL connection (that at least works now after 
years of IPv6 routing issues with my previous home DSL and no way of contacting tech-savvy support there) and in our 
company (where I set up an IPv6 tunnel which worked until the tunnel provider closed shop).


I do believe that mail and network admins at organizations of any size should make themselves knowledgeable and gain 
experience with IPv6 networking. Instead I see massive inertia and ignorance, and that's sad.


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.

[Hans-Martin Mosner via mailop]

Am 15.03.24 um 09:11 schrieb Alexandre Dangreau via mailop:

Hello,

In fact, if you need a /64 IPv6 range you probably use the wrong service. For 
VPS and Public Cloud instances (PCI) the IPv6 range is shared with all the VM, 
so each VM (VPS or PCI) have one single IPv4 (/32) and one single IPv6 (/128).

Only baremetal have a dedicated /64 IPv6 range. The support team could help you 
to find a server corresponding to your needs.



Of course such a "feature" can be used as a selling point for more 
expensive service options. It is still irresponsible to fence ordinary 
users together with spammers into a single /64 (and given the "success" 
of keeping spammers out, every /64 managed by OVH will have a number of 
spammers at any point in time). If unrelated users share a /64, you 
should disable outgoing access to port 25 (and probably some other 
ports) completely and advertise this service as "not suitable for e-mail 
operation"; that would also reduce the spam load on other networks a bit.


There are enough /64s available that you can give each customer her own.

Cheers,
Hans-Martin

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

Re: [mailop] Filter out emoji from email adresses

[Hans-Martin Mosner via mailop]

Am 04.03.24 um 22:40 schrieb Sebastian Nielsen via mailop:


Anyone that have a general algoritm to filter out emoji from sender addresses?

It's possible that the problem isn't specific to emojis but to any unicode code point in the supplementary planes (code 
point values above U+). Applications which were written when unicode was 16 bit only may have problems.


So one possible method would be to identify such code points and replace them with something that works in 16-bit 
unicode, such as the character code U+FFFD which is normally rendered as �.


Where to apply such a filter would largely depend on your specific mail setup. I can imagine that a small milter might 
do the trick.


However, getting the users to update their MUAs to something from the current 
millenium might not be a bad idea after all...

Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] One click unsubscribe in mailing list messages

[Hans-Martin Mosner via mailop]

Am 25.02.24 um 04:10 schrieb Philip Paeps via mailop:


It's actually encouraging to see the web-MUAs driving improvement in this space.  Parsing List-Unsubscribe: to present 
a button feels like a very obvious thing to do.  It's surprising how few traditional MUAs have ever done that.


Yes. I'm looking at you, thunderbird...

This should be a no-brainer, and it's a shame that the major open source MUA doesn't seem to support it. There's 
probably an add-on to do this, I just can't access the thunderbird add-on search at the moment, so don't know for sure.


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] One click unsubscribe in mailing list messages

[Hans-Martin Mosner via mailop]

Am 24.02.24 um 00:12 schrieb Mark Fletcher via mailop:

On Fri, Feb 23, 2024 at 3:09 PM Jay Hennigan via mailop  
wrote:


There are many systems that scan links in email and falsely unsubscribe.
I'd make it two-click. When clicked, have it go to a page that says:

You are about to unsubscribe [address] from mailing list [name of list].
Are you sure you want to do this? [Yes] [No]

Sorry, I misspoke/wasn't clear. It does do that now.

People still click on that Yes button.


Well if someone forwards mail containing their personal unsubscribe link to someone else, they are asking for it. 
Blindly forwarding such content is stupid.


You may want to give your subscribers the option of having a one-click unsubscribe link in every message (with a 
properly worded warning that forwarding such a link is risky) versus a monthly mailing list reminder which contains a 
link to subscription management but no information worthy to be forwarded. I don't know whether that's posssible with 
common mailing list systems though.


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Outgoing Spam from Microsoft IPs

[Hans-Martin Mosner via mailop]

Am 16.02.24 um 03:37 schrieb Matt Palmer via mailop:

Although I must say that


without reverse DNS

would seem to be the easier blocking option -- when was the last time you
saw legitimate mail from an IP without rDNS?

- Matt


We do that, with some exceptions, as we indeed get some legitimate mail 
without rDNS. However, there seems to be some issue with our rule-based 
engine which results in those e-mails not getting the proper 4.7.1 
response that we use for missing rDNS.


Since the rule engine is lacking in other areas, too (basically we can't 
express complex rules based on combinations of triggers), I intend to 
rewrite it, but that's a volunteer work in my spare time, of which there 
isn't that much :-)


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Outgoing Spam from Microsoft IPs

[Hans-Martin Mosner via mailop]

We've been seeing runs of spam mails from Microsoft IP addresses without 
reverse DNS (possibly cloud servers).

One is sending with addresses , starting on February 8.

The other (same or different spammer?) uses  and started 
just yesterday.

Have others seen these? Is there some way to identify the host IPs which are used by those cloud servers, so one could 
block incoming SMTP from them if Microsoft can't be bothered to block outgoing SMTP?


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] problem setting up open-dmarc

[Hans-Martin Mosner via mailop]

Am 09.02.24 um 16:20 schrieb Gellner, Oliver via mailop:
A not really serious reply: I'm interested to learn how I can get amused by looking at XML data, this would greatly 
improve my professional life. Until now I have been more in the state of wanting to jump out the window when I see 
DMARC reports like the following:

...
   
 
   194.127.216.50
   0


This is mostly a matter of tooling, XML is not fit for human consumption. Being a software developer, I wrote my own 
tools to parse and present DMARC reports which are not perfect but ok for my purposes. I'm not sure I could find 
sufficiently general open source tools quickly, but it's not impossible that there are some somewhere.


You might as well use the services of some company which specializes in DMARC training and handling, this might be a 
reasonable route if you expect considerable volume of actionable DMARC reports (in our case, most reports result either 
from spam mails who use our domain names without authorization, so that's a sign DMARC is working a bit as intended, or 
from our mails sent through mailing lists which live in the last millenium and don't preserve DKIM signatures or apply 
DMARC mitigations and whose admins ignore my requests to fix their systems).


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Ooops - sorry

[Hans-Martin Mosner via mailop]

Am 02.02.24 um 04:03 schrieb Lou Katz via mailop:

Wound up way back in my archive and responded to an old, dead issue.


If only the issue were as dead as it is old... SPF is a PITA that stays.

:-)
Hans-Martin


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

Re: [mailop] Extortion spam from OVH-hosted *.sbs domains

[Hans-Martin Mosner via mailop]

Am 26.01.24 um 09:42 schrieb Simon Bressier via mailop:

Hi all,

FYI Hans-Martin, I reached out to ovh team yesterday night to push your message, seems your abuse report has been 
processed by the proper team. No idea if they answered you, but at least, they have handled the report, and probably 
done the appropriate actions.


Actions maybe, appropriate probably not.

Today the spammers use .sbs domains on OVH IPs again:

mx.h.orku.sbs 51.68.81.175
mx.j.eown.sbs 51.89.230.64
mx.a.mykf.sbs 146.59.116.127

I can't see the content, as we refuse to accept anything from *.sbs at the 
moment, for good reasons.

Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Extortion spam from OVH-hosted *.sbs domains

[Hans-Martin Mosner via mailop]

Am 26.01.24 um 09:42 schrieb Simon Bressier via mailop:

Hi all,

FYI Hans-Martin, I reached out to ovh team yesterday night to push 
your message, seems your abuse report has been processed by the proper 
team. No idea if they answered you, but at least, they have handled 
the report, and probably done the appropriate actions.


Thanks Simon!

Good to know the abuse address is not a black hole, although it would be 
a bit nicer if there were at least some feedback indicating that the 
something was done (not a bot feedback confirming receipt, although that 
would still be more than silence). Since the *.sbs spam stopped, I 
already assumed that the situation had been dealt with.


Cheers,
Hans-Martin

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

[mailop] Extortion spam from OVH-hosted *.sbs domains

[Hans-Martin Mosner via mailop]

Tonight we received a huge wave of extortion spams from OVH hosted domains trying to get bitcoin payments. The senders 
claim that recipients watched child porn.


This is the final straw for me to add a rule to reject all mail traffic from OVH until the sender is whitelisted. OVH is 
completely unresponsive to abuse complaints, they won't even react when clearly criminal activity happens from their IP 
space.


The domains used were:

aoyn.sbs
bnop.sbs
burx.sbs
enux.sbs
fojr.sbs
hnls.sbs
nbot.sbs
ouhb.sbs
pxur.sbs
rnuh.sbs

with the IP addresses

51.89.5.129
51.89.5.145
51.89.175.30
51.89.175.173
51.89.175.196
54.38.1.200
57.128.16.249
57.128.60.137
57.128.83.193
57.128.123.32
57.128.165.75
57.128.166.120
91.134.96.213
91.134.97.224
91.134.97.232
135.125.66.34
135.125.66.86
135.125.66.217
135.125.217.78
141.94.64.94
141.95.108.175
148.113.137.42
148.113.139.81
148.113.140.91
148.113.141.117
148.113.143.4
162.19.68.117

It's probably pointless to call for a general OVH boycott, as much as I would 
like to do that :-)

Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone else noticing an increase in spam from Office365 distribution lists?

[Hans-Martin Mosner via mailop]

Am 17.01.24 um 15:35 schrieb Hans-Martin Mosner via mailop:

Am 17.01.24 um 15:20 schrieb Paul Menzel via mailop:
With this in mind, did somebody compile a block list yet? Or should I just create a whitelist? 


A block list does not make sense, as new domains are added continuously. It's 
just too simple.

Maybe it's still a possible approach, I've noticed a number of domains which were used multiple times yesterday and 
today, so that could be a start.


Cheers,
Hans-Martin

akwvsldz.onmicrosoft.com
bekoduwa.onmicrosoft.com
btowk.onmicrosoft.com
calmaa.onmicrosoft.com
cwonvkes.onmicrosoft.com
elimf.onmicrosoft.com
es01ms.onmicrosoft.com
exlzbuch.onmicrosoft.com
hwmaevdc.onmicrosoft.com
icloudwater.onmicrosoft.com
jymmgqxbugfoo.onmicrosoft.com
kalinzo.onmicrosoft.com
lnhvu.onmicrosoft.com
lxebaifv.onmicrosoft.com
muvzwtns.onmicrosoft.com
nmvukcow.onmicrosoft.com
nrhhwdliwprctsbbugfoo.onmicrosoft.com
nwvakomb.onmicrosoft.com
oemdxabu.onmicrosoft.com
ohzxuawl.onmicrosoft.com
okawas220.onmicrosoft.com
omvehxsk.onmicrosoft.com
or02ms.onmicrosoft.com
or03ms.onmicrosoft.com
or05ms.onmicrosoft.com
oxzdtluw.onmicrosoft.com
skdwbmot.onmicrosoft.com
skeeepur.onmicrosoft.com
sp001ms.onmicrosoft.com
sp003ms.onmicrosoft.com
svnvb.onmicrosoft.com
t021ms.onmicrosoft.com
t024ms.onmicrosoft.com
troggue.onmicrosoft.com
tszlrhwn.onmicrosoft.com
us01ms.onmicrosoft.com
vknhsutl.onmicrosoft.com
vlaucbde.onmicrosoft.com
vocldbut.onmicrosoft.com
wuleu.onmicrosoft.com
x24m2v2.onmicrosoft.com
x337i94.onmicrosoft.com
x6472u0.onmicrosoft.com
x6m471q.onmicrosoft.com
xbyybto.onmicrosoft.com
xcoulsth.onmicrosoft.com
xjuj241.onmicrosoft.com
xpfyc9f.onmicrosoft.com
xx31656.onmicrosoft.com
xxkm2i6.onmicrosoft.com
xyl9v2y.onmicrosoft.com
zeusshow.onmicrosoft.com

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

Re: [mailop] Anyone else noticing an increase in spam from Office365 distribution lists?

[Hans-Martin Mosner via mailop]

Am 17.01.24 um 15:20 schrieb Paul Menzel via mailop:
With this in mind, did somebody compile a block list yet? Or should I just create a whitelist? 


A block list does not make sense, as new domains are added continuously. It's 
just too simple.

I've had good experience with a whitelist, but that requires quite some manual work, as there are a number of 
onmicrosoft.com subdomains from which our users get legit mail. So we're handling them with temp reject codes, and I 
check the logs regularly (several times per day) to whitelist domains that look valid (which is most often possible in 
our case by just looking at the domain name).


False positives and false negatives do happen, but they are rare enough to make 
this a workable approach.

Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Samsung and SIZE

[Hans-Martin Mosner via mailop]

Am 15.01.24 um 07:54 schrieb Sebastian Nielsen via mailop:

  That header is supposed to be attached by the originating MUA, and I don't 
*think* transit MTAs are permitted to rewrite it...

Problem is, that when MUA or first MTA has a incorrect date set, the email 
comes like last in inbox... have seen emails set with 1970-01-01 00:00:00 Or, 
even worse, it has a date that is like, several months off, so you have to 
SEARCH your inbox after that unread email that was popped into the middle.

Thus to avoid that irritating problem, both for my users, and for myself, I 
just set the Date: header to the server time, correcting any incorrect dates.

Whats so wrong with it.


Mailers creating DKIM signatures are likely to include Date:, so your "correction" would invalidate many DKIM 
signatures. It's up to your users to decide which is less inconvenient, especially if you always modify the header 
instead of only when the date is off by more than a day or so.


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Incoming spam from outlook.com

[Hans-Martin Mosner via mailop]

Am 15.12.23 um 14:49 schrieb L. Mark Stone via mailop:

We too are seeing high volumes of such email.

Historically, we have avoided deploying greylisting*, but are curious if 
greylisting would block these emails?  Could anyone who is doing greylisting 
comment on whether these garbage emails are being resent?


Greylisting is generally ineffective against spam sent through a regular 
e-mail infrastructure. It only helps when the sending software is either 
set up to avoid retries or the sending IP is only used for a very short 
interval.


Spam sent via accounts on freemailers is generally hard to reject 
without resorting to content filtering. In some cases (when accurate 
Received-lines are present) you may be able to filter based on header 
information, but some providers (such as Google) hide this information, 
presumably to protect the privacy of their users.


Cheers,
Hans-Martin

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

Re: [mailop] salesforce phishing emails

[Hans-Martin Mosner via mailop]

Am 28.11.23 um 11:54 schrieb Mary via mailop:

Dear salesforce,

Please stop your clients from sending Facebook phishing emails.


I've been asking them something like that by way of abuse reports since end of September, to no avail. They don't seem 
to care.


Sadly, they host legitimate customers, too, so we can't block them completely.

Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Success MiTM attack

[Hans-Martin Mosner via mailop]

Am 22.10.23 um 12:23 schrieb Paul Menzel via mailop:
It was interesting and surprising to me, as the common perception is, that SSL certificates protect against MiTM 
attacks as it should provide authenticity. 


The weak point of SSL certificates is that clients are willing to accept new certs for the same domain as long as their 
signature path is correct (ending at one of the trusted root CAs). State-level agents may have ways of obtaining a 
certificate for a third party from a trusted authority, as long as they convince the authority that their interception 
request is lawful.


What can clients do to prevent MitM attacks? I think (but have no in-depth knowledge) that pinning a trusted certificate 
should work (one that you trust due to external witnesses, not certification authorities that may be subject to Llaw 
enforcement exceptions). A new certificate for a communication partner should only be accepted if you get similar 
confirmation that this one is valid, too.


This is a weakness in the public key infrastructure based on trusted authorities - and I believe that this weakness 
isn't accidental, but is present for exactly the purpose of allowing "lawful interception".


For known trusted communication partners, you can install the certificate of their own CA (which is easy and 
well-supported) and disable acceptance of certificates from other CAs for the given domain (which may or may not be 
supported, depending on the TLS stack used, but that's the "pinning" that I believe should be possible but have no 
direct knowledge about).


A P2P certificate signing system such as the PGP web of trust may work to avoid interception, but I don't think it 
really scales well. And don't get me wrong, I'm not against lawful interception when it's used to prosecute and possibly 
prevent serious crimes, but the judgement of what constitutes serious crimes may differ between different people and 
agencies.


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] belgacom.be / skynet.be - massing phishing

[Hans-Martin Mosner via mailop]

Am 13.10.23 um 18:30 schrieb Mary via mailop:

Hello everyone,

Anyone from belgacom.be notice massive amounts of phishing with/from skynet.be 
addresses?

I've tried to report them without success. Posted on spamcop.net in case anyone 
would notice, again without success.


No, they don't notice, they probably don't care. I've reported this for a while, without noticeable effect. After a 
while I stopped and use the spamblocking mechanisms. If some Belgacom customer has a legitimate need to communicate with 
our users they will need to talk to us for individual whitelisting.


Cheers,
Hans-Martin___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Noticeable increase of spam emanating from Colocrossing?

[Hans-Martin Mosner via mailop]

Hi,

does anybody else see a noticeable increase of spam from Colocrossing hosted IPs? I don't have hard data but my gut 
feeling is that the number of attempts have increased by a significant amount during the few weeks.


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] spamhaus false positive ?

[Hans-Martin Mosner via mailop]

Am 19.08.23 um 10:43 schrieb Pascal HOARAU via mailop:


Hello,

Since this night (French time) a lot of companies are blacklisted by spamhaus, 
mostly transactional IPs.

Do you have the same issue and any info ?

Regards,

Pascal


The spamhaus rejections that I see look all justified. Maybe you should give 
some examples?

If I may extrapolate "French time" to "OVH" or "Online SAS" I would not be too surprised to see blocks, but of course 
that's just guessing. Abuse desks who apparently do nothing are not a good way to stay out of blocklists.


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Hans-Martin Mosner via mailop]

Has anyone on this list tried forwarding (e.g. for ex-employees) via 
attachment? The original message would be kept intact, while the outer 
message clearly originates with the forwarding agent who may even add a 
human readable reminder to the addressee to let the sender know about the 
changed address.


Opening message attachments should be possible with most modern MUAs, but 
TBH I don't really have much experience with that.


Cheers,
Hans-Martin

Am 13. Juli 2023 09:46:11 schrieb Andrew C Aitchison via mailop 
:



On Wed, 12 Jul 2023, Michael Peddemors via mailop wrote:


And yes, email forwarding will break.. but email forwarding remotely should
be killed off anyways.. everyone can log into two accounts.


Universities would like to allow the world to contact staff who have
recently left. We forward paper mail; why not email ?
Former staff don't have door keys.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


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

[mailop] SPF +all considered harmful

[Hans-Martin Mosner via mailop]

Most likely none of you would consider adding +all to an SPF record a smart 
move, here's another reason why you shouldn't do it:


Google cloud services are being used to spam (ongoing for a long time, 
Google doesn't seem to care). What I noticed today is that the spammer is 
using domains with SPF +all as sender and HELO domains, presumably hoping 
to avoid SPF based rejections or quarantine.


This might lead to bad reputation for the domains involved...

Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SendGrid is deleting your mail

[Hans-Martin Mosner via mailop]

Am 22.06.23 um 06:52 schrieb Matt Harris via mailop:




On Wed, Jun 21, 2023 at 6:11 PM Sebastian Nielsen via mailop 
 wrote:

>>The RFC forbids doing that, and I argued against it

The RFC and reality is two different things. If a client don't want to 
retry, I think they are free to choose to
not retry.


This is a terrible take, imho. It's anathema to building standards-compliant and hence interoperable systems that 
allow the internet as a whole to function correctly while each of us make different choices in terms of 
providers, hardware, and software to use.


Sometimes deviating from RFCs may be necessary to ensure stable and safe operations, because the RFC authors did not 
foresee all circumstances and every way malicious parties could try to exploit the system.


However, as soon as you deviate from the RFCs you must accept responsibility for the resulting effects on legitimate 
use. If SendGrid decides to react in a non-standard way to 4xx SMTP responses, they are fully responsible for lost 
tickets, order and invoice information etc. that might have been sent through their service.


For newsletters and promotional mail this is entirely acceptable. For transactional mail with actual value and legal 
weight, not so much.


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Strange mail delivery from microsoft

[Hans-Martin Mosner via mailop]

Am 19.06.23 um 06:36 schrieb Klaus Ethgen via mailop:

I have some update..

Greylisting was not the problem I had/have with microsoft.
Your original mail sounded a little different. However, upon re-reading it is possible that you activated greylisting in 
response to the previous perceived attacks (this might be a foreign language subtleties issue, we both don't have 
english as our primary language).

Due to
ongoing attacks (especially also from big clouds like microsoft) I have
a limit of 10 connections per IP and hour. That seems not enough for
microsoft to deliver 1 or 2 mails per days relyable.
Ok, so you're doing something that you didn't mention before. 10 connections per IP and hour is a bad idea if you want 
to receive mail.


What a shity provider!


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, blaming them for your inability to receive mails from their customers isn't really appropriate. 
There are enough actual faults Microsoft can be blamed for :-)


Cheers,
Hans-Martin

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

Re: [mailop] Strange mail delivery from microsoft

[Hans-Martin Mosner via mailop]

Am 18.06.23 um 18:53 schrieb Klaus Ethgen via mailop:

Hi,

I have tighten my firewall a bit and seen many attacks from Microsoft
(40.92.0.0/16).

Attacks or mail delivery attempts?

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.


How do you reject them? Using a 4xx temp error? Or some other mechanism, such as closing the connection prematurely? If 
you do it in the firewall, it might do something else than a normal greylisting mailserver would.


Microsoft's outgoing mailservers might try to distinguish between greylisting hosts and unreachable hosts, preferring to 
retry from a completely different IP when hosts are unreachable, under the assumption that it might be a routing issue.




Could you please tell me how to handle that broken mail delivery? It
triggers all, my mailserver attack filter as well as greylisting.


If it consistently breaks valid mail, it's probably your side that's broken :-)

Greylisting is something that only makes sense when dealing with very braindead ratware on hijacked home network 
connections. Any real outgoing MX, whether operated by legitimate organizations or by spammers, will retry and thus 
defeat the intent of greylisting. I would just drop greylisting from the list of effective anti-spam measures.


Cheers,
Hans-Martin

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

Re: [mailop] Port 25 Pingback?

[Hans-Martin Mosner via mailop]

Am 16.06.23 um 20:02 schrieb Benny Pedersen via mailop:

Mike Hillyer via mailop skrev den 2023-06-16 19:48:

Sources or hosts?

I don’t expect a given host to answer on port 25 just because it
sends, but the domain in the return path should be accepting mail
properly. If they can’t be bothered to receive their DSNs then they
are not likely a good-faith sender.


DSN is not sent, its generated by there own closed port 25 still, so DSN works 
without port 25 listners

maybe accept and bounce should really be stopped ? 


Huh? Whether some address will generate a DSN is not really under their control. What's necessary is that their envelope 
sender address is prepared to receive bounces as it isn't always possible to decide final delivery at the SMTP 
transaction stage.


Of course it would be nice to eliminate accept-and-bounce, but that's not going to happen with SMTP which is after all a 
store-and-forward protocol.


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Port 25 Pingback?

[Hans-Martin Mosner via mailop]

Am 16.06.23 um 19:37 schrieb John Possidente via mailop:
A sender of legally mandated bulk mail who are very conscious of making sure they're dotting every i and crossing 
every t (because they're required to) asked me today whether port 25 pingback is still necessary. I immediately 
thought, "Of course not," but on second thought (before speaking, yay) realized that maybe I'm wrong.


Does anyplace still reject mail from sources that don't answer on port 25?

Thanks.


Since mail operators do all kinds of reasonable and unreasonable things to limit the amount of undesired mail, it's 
entirely possible.


I would not care about the domain of the sending SMTP client, but the RFC2821.mailfrom (envelope sender) and the 
RFC2822.from (header From: address) tend to be used as recipients of automatic respectively manual responses, and in my 
opinion the willingness to receive and handle both kinds of responses is part of good e-mail hygiene.


Cheers,
Hans-Martin

___
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

[Hans-Martin Mosner via mailop]

Am 31.05.23 um 01:18 schrieb Sebastian Nielsen via mailop:

I don't agree with your stance.

Hiding whois details doesn't mean you hiding your identity. Normally, this type 
of privacy is also used when you want to hide the actual person that is 
responsible for, lets say paying the domains.
Still, in this example the domain information for mailgun.co and mailgun.net is so thoroughly hidden that it isn't 
possible which legal entity owns them. I don't care about the private phone number of some poor fellow who is tasked 
with paying for the domains but for a commercial enterprise I one can reasonably expect truthful and working contact 
information as well as an identification of the legal entity. A role e-mail address and a phone number where someone can 
be reached in emergencies should not be to hard to implement for a sizable business.

Because, you don't want people calling these phones, about spam, about support 
cases, about things that SHOULD be taken through their ticket system.

Do mailgun.co and mailgun.net have working ticket systems?

But you still want a private phone there, that could be ringing in the middle 
of the night if something went amiss with their payment for their domain, so 
the domain doesn't get snapped by a squatter.
Who said that they wanted a private phone contact? Not Michael if I read his words correctly. Not me (I hate phone 
conversations). I don't think that any reasonable person expects private phone numbers in whois contacts. Companies must 
have company contact channels which should be public info, and for truly private domains I'm fine with not seeing their 
private contact data in whois. However, they should also be fine if my mail system does not accept mail from essentially 
anonymous sources and requires them to ask for whitelisting.

So I would say, this practice is legitimate for larger companies like mailgun.


Well, is this mailgun even? These are just domain names which use that sequence of characters, registered with 
registries and registrars who don't give a flying f for the actual identity of their customers. There is no way for me 
to find out whether these are fake or real. From my experience with NameCheap, "fake" is a pretty safe bet, I'm seeing 
those kind by the hundreds daily, and very rarely do I see a legitimate domain using them as registrar.



Just because details are hidden at location A or for automated tools doesn't 
mean they are dubious.
Same if they hide their details on website, but require filling out a captcha 
to get their office address. Doesn't mean they are shady.

You can still find their details on their official website 
https://www.mailgun.com/contact/
With a address to their office even.


To repeat myself: That contact info is for mailgun.com, not for mailgun.co nor mailgun.net. It is conceivable that 
somewhere hidden on mailgun.com's web site there is a mention of those two domains and that they are indeed operated by 
the same company, but the domain info itself does not say that.


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.


Cheers,
Hans-Martin

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

[mailop] Someone from nifty.com / sion.ne.jp an this list?

[Hans-Martin Mosner via mailop]

There's been an ongoing phishing wave originating from nifty.com. I (and most likely others) have sent abuse reports, 
but the root of the problem apparently hasn't been found and fixed. Would you please see that this phishing stops? If 
you contact me off-list, I will provide you with the addresses which we've seen in case you can use that to pinpoint the 
issue.


Cheers,
Hans-Martin

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

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

[Hans-Martin Mosner via mailop]

Am 25.05.23 um 07:33 schrieb Slavko via mailop:

I am confused now as in RFC 7505 sect. 4.2 one can read:

 Null MX is primarily intended for domains that do not send
 or receive any mail...

And:

 ...mail systems SHOULD NOT publish a null MX record for domains
 that they use in RFC5321.MailFrom or RFC5322.From addresses.

I understand that RFC as: nullMX's primary purpose is about
not receiving, but as side effect it can result as not sending too.

Is my understanding wrong?


Technically, null MX and SPF "-all" are two different things, as has been pointed out. SPF "-all" is clear-cut, and 
you'd be absolutely correct in refusing to accept such mail.


However, null MX is a different beast. Technically it only states that a domain does not receive mail. But when you look 
at common use cases and exception situations such as NDNs, domains with null MX can be regarded as being not fully 
functional when used in RFC5321.MailFrom, as they will not receive and process technical feedback about deliverability. 
In my experince, this is a significant factor in assessing whether you want to receive mails from such domains.


RFC5322.From is a somewhat different matter, especially when null-MX domains are used in mails which are clearly not 
intended to be replied to. For bulk mail this is fairly common, although I would vastly prefer if such mails had a 
working RFC5322.From address for handling replies from confused recipients (a recipient who has not subscribed to some 
mailing list should be able to contact the sender and demand removal of his address without investing lots of sleuthing 
work to find out who was responsible for the e-mail). So this can be regarded as a sign that you would prefer to refuse 
such mail, but arguably a much weaker one, and one that more likely would cause false positives.


Cheers,
Hans-Martin

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

Re: [mailop] SMTP disconnect… (Was: Hosteurope contact?)

[Hans-Martin Mosner via mailop]

Am 07.05.23 um 00:12 schrieb Thomas Walter via mailop:

Turns out

mx-out-02:~$ nc mx0.webpack.hosteurope.de 25
220 mx0.webpack.hosteurope.de ESMTP (mi005.mc1.hosteurope.de) (even more power) 
Sun, 07 May 2023 00:03:13 +0200
ehlo mx-out-02.fh-muenster.de
550-REJECT: 212.201.120.206 is in csi.cloudmark.com :
550-Listed as Poor Reputation Sender. Cloudmark Sender Intelligence Reputation
550 Remediation Portal https://csi.cloudmark.com/en/reset (ID:550:3:0)
mx-out-02:~$

All this trying to figure out what's going wrong, contacting support, etc. could've been avoided if they followed the 
RFC?


https://www.rfc-editor.org/rfc/rfc5321#section-4.1.1.10

4.1.1.10.  QUIT (QUIT)

   This command specifies that the receiver MUST send a "221 OK" reply,
   and then close the transmission channel.

   The receiver MUST NOT intentionally close the transmission channel
   until it receives and replies to a QUIT command (even if there was an
   error).

Or is there a new version to the standards that allows this? 


It's probably not sanctioned by the standards, but considering the aggressive push of spam mails into our systems I can 
understand when mailops reduce communication with a perceived bad sender to a minimum. However, a properly coded 
mailserver should adhere to the standards even if its operators choose to turn away SMTP clients early.


OTOH, your mail server acting as an SMTP client should handle the 550 code and at least log it, even if the other side 
behaves out of spec. Such information can be useful.


Cheers,
Hans-Martin

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

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

[Hans-Martin Mosner via mailop]

Am 06.05.23 um 18:44 schrieb Christian Seitz via mailop:

Hello,


...


I already tried to contact Yahoo before sending this email to the list and they acknowledged the issue "You are 
correct, we are indeed looking for an SOA for each individual subdomain if you're going to use it in the SMTP 
(RFC5321) MAIL FROM." and promised to forward the email headers to an engineer, but that was more than a week ago and 
we are having some users who complained about the issue. 


This sounds pretty much wrong. Requiring a separate SOA for every subdomain sending e-mail is nonsense, as your example 
shows. I'm doing volunteer work for an organisation where subdomains are used similarly yet we did not experience 
issues. One possible reason might be that our subdomains send mail via a central mail server, we use SRS to work around 
SPF breaking forwarding (some of our users have pretty ugly forwarding chains, and we can't really get them to simplify 
that) and the particular SRS engine happens to SRS-encode all SMTP sender addresses whose domain part isn't the main 
domain. I would not suggest you use SRS though (it's a half-working patch for the problems that SPF creates, which is a 
not-even-half-working patch for the spam/phishing problem)...


It would be interesting to see whether the outgoing SRS component can be changed to leave subdomains alone, but our 
users might not be amused that mail to Yahoo suddenly fails to be delivered.


Cheers,
Hans-Martin

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

Re: [mailop] ab...@microsoft.com => Mailbox full

[Hans-Martin Mosner via mailop]

Am 20.04.23 um 21:25 schrieb Jarland Donnell via mailop:
The age old problem: Hire a bunch of people to read it that aren't skilled enough to do anything about it, or hire 
people who are skilled to handle it but don't have the time or manpower to read it all. 


There's a third option: Handle most of the incoming reports automatically by matching them with known abuse-emitting 
servers (whether exploited or rented by the spammer), let the few skilled people look at the interesting stuff to 
identify trouble spots quickly, and give them sufficient banning power to keep the total amount of abuse emanating from 
your network at any time low enough that they are not overworked.


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] linodeusercontent.com/googleusercontent.com, I'm so done with you

[Hans-Martin Mosner via mailop]

Am 08.04.23 um 06:17 schrieb Jarland Donnell via mailop:
To be clear they have an amazing abuse team, easily the first people I would hit up if I were hiring in that area. 
Just top notch admins.
If they are top notch but have their hands tied they are essentially worthless to me. They could just as well have a 
good time playing darts and drinking beer, it wouldn't make a difference.


Blocking SMTP by default makes sense, but settling on the best way to handle opening it (automated? manual review?) is 
a discussion that is very easy to get stuck in. I don't know where they're at on that discussion by now, but when I 
left it was something I would have referred to as "on the table." That to say most of the stakeholders would entertain 
the discussion.


As a first approach, it might be helpful to only consider opening SMTP for customers whose identity you know with a 
sufficient certainty. Whether you then open it by default, make it an automated process, or have an additional manual 
review does not make much of a difference, and I'd say that opening port 25 for verified customers is sufficient. 
Spammers can easily create like 1 fresh accounts with different e-mail contacts and fake addresses daily using 
automated tools, but as soon as they are required to provide verifiable data for a KYC process they will be gone. Of 
course, this hinges on the premise that a spamming account will be terminated quickly and the customer will be banned 
from ever having an account again with you.


AI-supported categorizing of new accounts into "likely genuine" and "likely fake" might also help. I have no practical 
experience with this, but it would be really interesting to know whether providers try or tried this and what the 
results are.




There's likely an attached fear that appearing even remotely hostile to customers could quickly drive them to a 
competitor in a pretty competitive market. You have to think that as much as people like you and I would appreciate 
them doing it, their customers would likely only be speaking up about it to say the opposite. You might decrease abuse 
complaints but you might also decrease NPS scores, and the people sending abuse complaints are usually not your 
customers (so pleasing them doesn't = $). You might think that reducing IP blacklisting could reduce customer 
complaints and bad NPS scores. I don't think reality actually plays out that way because Gmail doesn't use external 
blacklists (that I'm aware of), and Microsoft will unblock individual IPs upon request (sometimes after some back and 
forth), and that accounts for almost all of what people want anyway. And even that would only matter to customers that 
run mail servers anyway. 


And that's why I'm still in favor of blocking spammer-hosting providers swiftly and broadly. It needs to affect the 
non-spamming customers, too, to be a strong economic incentive for keeping spammers out. Of course I also punch holes 
when contacted by affected e-mail users, but at least I have a chance to tell them that they're with a bad provider and 
are supporting criminal activities by letting themselves being used as human shields.


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] linodeusercontent.com/googleusercontent.com, I'm so done with you

[Hans-Martin Mosner via mailop]

Am 04.04.23 um 23:02 schrieb Brandon Long via mailop:
Google Cloud, which I assume is what googleusercontent.com  is from this, is only 
unblocked for smtp for supposedly good customers... though I think they are allowed to connect to the Workspace relays 
(but then I wouldn't expect them to come from googleusercontent.com  but from the 
regular Workspace IPs).  I  would expect that to be enough to keep the spam at least grey, but if it's worse than 
that, then someone would need to take steps.  I'm not on the teams involved any more, so I don't know if they're aware 
or not.
Blocking outgoing port 25 for essentially anonymous customers is certainly a good thing, thanks for noting that Google 
Cloud is most likely doing that. So if only good customers get outgoing port 25 privilege, I have to assume that a lot 
of good customers have been hacked, or maybe just one who is being used to send thousands of spams. Since the hostnames 
of those cloud IPs don't reveal anything about the customer and I'm not going to set up our mail system to intercept and 
store all those messages for in-depth analysis, I don't know which it is. Google Cloud should know and take appropriate 
action.


You can report the abuse on the Cloud abuse form at https://support.google.com/code/go/gce_abuse_report though I 
recognize that's not how people like to report spam.


IMHO abuse web forms are essentially a way of saying: "we don't want to hear from 
you, we don't care" :-)

I just don't have enough time to navigate all those forms, which often enough request information which I'm not willing 
to share in the context of an abuse report (mandatory phone number? You must be kidding, I don't want abuse related 
calls to my private or work phone).


I must admit that my e-mail reporting isn't optimal yet, either. I did not yet implement ARF and X-ARF for my abuse 
reporting due to limited time, and most of it is done through Spamcop (which has the acceptable kind of web form - paste 
everything here and we'll take care of the rest), also due to limited time. For those providers who appear often and 
which Spamcop doesn't want to send reports to, I've made a number of crude scripts, but that doesn't really scale. 
Someday I will find the time to streamline this.


Well, enough venting for now...

Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] linodeusercontent.com/googleusercontent.com, I'm so done with you

[Hans-Martin Mosner via mailop]

Those two cloud providers are currently providing 99% of the incoming spam at 
one site.

googleusercontent.com sends a never-ending flood of DHL phishing mails.

linodeusercontent.com sends unsolicited ad crap using a domain "klwinkel.app".

Time for large scale IP range blocking, I really can't stand this anymore.

Is there anybody there who reads abuse reports, tracks down culprits and 
*fooking shuts them down*?

Aggravated,
Hans-Martin

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

Re: [mailop] sender domain reputation

[Hans-Martin Mosner via mailop]

Am 28.03.23 um 14:19 schrieb John Levine via mailop:

It appears that Dan Malm via mailop  said:

And then we have freenom, still giving away .tk, .ml, .ga, .cf and .gq
domains for free... I don't block those TLDs, but they spew out enough
spam that they go directly to the spam folder.

Not any more.  Meta/Facebook sued them for endless phishing and they
stopped taking new registrations several months ago.


Well, either they are taking registrations again or this is an old one: 
c8r97.cf was seen in a fake dating spam today.

I still don't see a compelling reason to accept mail from or referencing those 
domains.

Cheers,
Hans-Martin

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

Re: [mailop] How to address Microsoft if spaming Office365 customers cause collateral damage for other Office365 customers sharing the same IP?

[Hans-Martin Mosner via mailop]

Am 30.03.23 um 18:11 schrieb Francois Petillon via mailop:

On 3/30/23 16:37, Benoit Panizzon via mailop wrote:

Unfortunately, this massively affects other Office365 customers. But
they complaint because we (operating the SWINOG blacklist) block them,
they don't complaint to Microsoft for being the source of the issue and
find it hard to address such issues with Microsoft.



What would be the best way to address such issues for Office365
customers?


...

In other words, there are 15 spamming domains that generated 90% of the mail traffic on this IP a,d Microsoft does 
nothing while they have had the information for months.



But I would also love to hear from anyone that had to deal with the subject.

François

I try to tackle this by analyzing domains present in mail headers and rejecting mails accordingly. As you've 
experienced, talking the Office365 customers into leaving their crappy host isn't working, so I will have to accept that 
a significant part of the traffic from O365 sources is legit, and blocking their IPs is not an option.


Of course I would love to see the big providers keep the spam at bay on their egress, but I realize that this wish won't 
be granted unless there is massive financial incentive to do so. These are profit-oriented corporations after all, 
ethical behavior doesn't generate income in their market.


Cheers,
Hans-Martin

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

[mailop] Sendgrid abuse forwarding to Google - not one of your brightest ideas

[Hans-Martin Mosner via mailop]

I tried to report a phishing spam to Sendgrid, and look what I got:

   - The following addresses had permanent fatal errors -

(reason: 552-5.7.0 This message was blocked because its content presents a 
potential)

   - Transcript of session follows -
... while talking to aspmx.l.google.com.:

DATA

<<< 552-5.7.0 This message was blocked because its content presents a potential
<<< 552-5.7.0 security issue. Please visit
<<< 552-5.7.0https://support.google.com/mail/?p=BlockedMessage  to review our
<<< 552 5.7.0 message content and attachment content guidelines. 
t7-20020a02540700b0038a27d5a3b9si13875032jaa.5 - gsmtp
554 5.0.0 Service unavailable

Well doh, abuse reports tend to include the messages being reported, and those messages tend to contain bad content. 
Forwarding your abuse mail to a google mailbox isn't really a good idea...


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Human contact at Proximus/Belgacom?

[Hans-Martin Mosner via mailop]

Hello,

abuse reporting to Proximus/Belgacom is made as inconvenient as possible by

 * Not accepting e-mail reports (automatic reply points to abuse submission 
form)
 * Telephone number as required field on the submission form (I absolutely 
don't want to be contacted by phone
   regarding abuse reports)

Does anyone know of a human contact at Proximus who would accept e-mailed evidence of bank phishing sent via their 
servers? These phishing e-mails have been coming for a long time (in my inbox, I find copies of the automatic reply from 
2021 and 2022).


I think I may have asked this in the past and most likely did not get a response, so my only recourse would be to fully 
block mailsecXXX.isp.belgacom.be (again).


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF and DMARC Passed Phishing Spam from Oracle.com

[Hans-Martin Mosner via mailop]

Am 23.02.23 um 05:30 schrieb Peter Beckman via mailop:

It seems that if you are able to get a server in oraclecloud.com, you can
send SPF- and DMARC-passing spam to be sent by Oracle.com, which includes a
phishing URL attempt.


Actually, sending SPF- and DMARC-passing spam is possible from about any cloud 
service.

As long as the cloud providers don't enforce a strict KYC requirement for 
allowing outbound SMTP, this won't change.
Requiring accurate domain WHOIS information would at least make it a lot harder for spammers to create new domains to 
spam from, but that train has long passed the station, reached the final destination, been deposited on the scrap heap.


Cheers,
Hans-Martin

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

Re: [mailop] How to get Google to set a null MX for gmail.co ?

[Hans-Martin Mosner via mailop]

Am 16.02.23 um 17:57 schrieb Tom Perrine via mailop:


The subject says it all.

We’ve got users (who doesn’t?) who fat-finger gmail.com to gmail.co – 
apparently A LOT.

The domain gmail.co seems to be an anti-squat domain, and on HTTP it throws a 404 – as expected. (Although they could 
have redirected to gmail.com – whatever).


But, there’s no MX, so SMTP falls back to the A, and mail sits in our outbound 
queues until it expires, etc.

Any idea who/how to suggest to Google that a null MX would be appreciated?


I prefer to do these things on my own, then I can be sure they get done in a 
reasonable timeframe.

Our /etc/postfix/transport map has about 700 error entries for fat-finger domains. For many of them, it would be 
difficult and time-consuming to find the actual domain owners, convince them to add an MX record, etc. On the other 
hand, adding a new entry is a matter of 10-15 seconds. Guess which option I prefer.


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Hetzner

[Hans-Martin Mosner via mailop]

Am 08.02.23 um 02:44 schrieb Michael Peddemors via mailop:

On 2023-02-07 14:00, Hans-Martin Mosner via mailop wrote:
Another thing is that it should go absolutely without question that 
as the hoster will not divulge the identity of their customers to 
abuse reporters,


Okay, going to start a flame war with this

Huh?

Anyone who wants to run an email server on the internet in this day 
and age, understands the need for transparency if they want their 
email accepted by others. 


The flame war didn't happen. You're preaching to the choir, but the 
service providers aren't listening, and they don't care.


I have never been successful in extracting customer identifying 
information for clear spam senders from any service provider, whether 
shady or legit. They just don't disclose this info, typically citing 
personal data protection reasons. I've given up asking.


If the customer doesn't identify themselves on their website (which of 
course spammers won't do), you basically have to don your private 
investigator hat and put together the info puzzle pieces that you can 
get, yielding tentative clues but no solid evidence.


Yes, I'm blocking them pretty radically. The spammers without thinking 
twice, and their providers (ASNs) after some check that there won't be 
too many legit customers affected. Works fine for me but I'd rather have 
the spammers put on the pillory so that everyone interested can block 
them and spit on them.


Cheers,
Hans-Martin

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

Re: [mailop] Hetzner

[Hans-Martin Mosner via mailop]

Am 07.02.23 um 13:31 schrieb Ralph Seichter via mailop:


When a
third party X complains that Hetzner customer Y is a spammer, I consider
it only appropriate that Hetzner passes the complaint along and asks Y
for a statement, and does not simply impose restrictions on Y based on
X's say-so.


There's a lot that can be done between those two extremes.

One thing is that upon receiving complaints, a hoster should make sure that they actually know who the customer is, and 
that the customer isn't using shady and possibly fake identity, payment options, etc. A customer going out of their way 
to hide their true identity should be a red flag.


Another thing is that it should go absolutely without question that as the hoster will not divulge the identity of their 
customers to abuse reporters, they must also not divulge the identity of abuse reporters to their customers. Even 
hinting at the possibility that they might do that completely destroys the trust in them that I as an abuse reporter 
might have. This is why I am not reporting anything to Hetzner anymore but block single IPs immediately.


When I report abuse, I expect the hoster to first do some plausibility checks, including checks whether there are 
reports from other sources about the same customer. If there is good reason to assume that the customer is a victim 
himself, it would be appropriate to work with them to fix the issue, and in the meantime place some restrictions on 
their outgoing traffic to contain the damage. If there are reasonable indicators that the customer might be the 
originator of abuse, they need to be warned and put on a watchlist.


As an abuse reporter, I often have a more complete picture of the spammer's activity, for example I tend to be able to 
follow some of them from hoster to hoster by their choice of host and domain names, registrars, etc. When I suggest that 
a customer be disconnected due to spamming it is normally because they are very clearly the perpretators, not victims. 
Otherwise I simply report and leave the judgement up to the hoster.


Cheers,
Hans-Martin

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

Re: [mailop] Anyone know about this list washing organization from yesterday?

[Hans-Martin Mosner via mailop]

Am 08.12.22 um 17:25 schrieb Michael Peddemors via mailop:

The IP(s) are geo-located as Romania, but the IPs are registered to Dutch and 
UK companies..

All the domains are tossing a cloudflare unknown error..

Digital Virtualisation Solutions London, 5.157.216.0/22
GMG Amsterdam Infrastructure, 185.246.110.0/23
BIZNET Amsterdam Infrastructure, 185.246.136.0/23, 185.246.138.0/23
Digital Virtualisation Solutions London,

All maintained by.. mnt-by: GLOBALAXS-MNT 


... Also known as M247 (don't know which company is a customer/subsidiary of 
which, don't care much either).

As far as I can tell, a spammer haven. IIRC, some time ago they claimed to get a grip on spamming customers, but they 
probably have their private definition of spamming that doesn't fully correlate with what we usually mean when we say spam.


Cheers,
Hans-Martin

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

Re: [mailop] off-topic? useless Subject tags

[Hans-Martin Mosner via mailop]

Am 27.11.22 um 17:19 schrieb ml+mailop--- via mailop:

Hmm, so something "tagged" the previous mail as
[Marketing Email]

Subject: Re: [mailop] [Marketing Email]  t-online.de

Seems to be really bogus to me

IMHO it would be nice if those (misleading) "tags" could be removed
before replying, similar to "[External]", "[Probably Spam]", etc,
esp. if they fill up the Subject: header such that the actual value
is barely displayed...


It's somewhat difficult for software to decide which tags are bogus. Mailing list software could at least check whether 
a tag has been newly inserted in a thread, but that's probably beyond the control of mailop's operators.


Looks like the tag was inserted by the mail system used by John Devine, he probably does not have control over it. Of 
course he could have removed that tag by himself, but that's something easily overlooked.


Cheers,
Hans-Martin

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

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

[Hans-Martin Mosner via mailop]

Am 24.11.22 um 17:20 schrieb Martin Flygenring via mailop:

... [Google says] Our system has detected an unusual rate of unsolicited mail 
originating from your IP address.
...
Now, the interesting part is that for almost 98% of the mails currently in queue, Google is the original sender of the 
email.


I don't see a contradiction here. Google is a massive sender of spam, so it would only be normal to classify their email 
as unsolicited...


Cheers (somewhat tongue-in-cheek),
Hans-Martin

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

Re: [mailop] Massive bounce report campaign

[Hans-Martin Mosner via mailop]

24. November 2022 08:48, "Cyril - ImprovMX via mailop" mailto:mailop@mailop.org?to=%22Cyril%20-%20ImprovMX%20via%20mailop%22%20)>
 schrieb:
I'd love to be able to drop them, but the situation is made in a way 
that we can not do anything:
That user configured their bounce domain to pass through us, but we didn't send 
their bouncing email in the first place. they use another service for that.
So there's still a lot you can do:
* reject mail destined for their bounce domain at the SMTP level, that 
still consumes resources but not as much as trying to queue and forward it.
* if you have valid contact details (and if they are your customer, you 
should have those), get them on the phone and make it crystal clear to them 
that their spam campaign needs to stop immediately.
* you might choose to exercise legal options to have them pay damages 
for interfering with your business. I'm in no way legal expert for any 
jurisdiction, so you'd need to discuss this with your lawyer.
Sadly, Outlook/Hotmail/Microsoft might be the least helpful in all of 
this. They are too big to care.

Cheers,

Hans-Martin
___
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'

[Hans-Martin Mosner via mailop]

They are validating addresses using incomplete SMTP dialogs. Either 
nullroute or block at the MAIL FROM stage, so they don't even get to check 
whether RCPT TO would be accepted.


Cheers,
Hans-Martin

Am 30. Oktober 2022 23:23:51 schrieb Michael Peddemors via mailop 
:



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.  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?



--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


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

Re: [mailop] How do I break Gmail forwarding?

[Hans-Martin Mosner via mailop]

"multiple people" - 3..5, or 60..100?

If it's not too many who could have done it, ask them, have them fess up, 
and let the one who did it repair it.


Otherwise, blocking the gmail address on mail ingress is probably the 
simplest solution.


Cheers,
Hans-Martin

Am 24. Oktober 2022 15:16:30 schrieb Tara Natanson via mailop 
:


At some point someone set up a gmail address which forwards automatically 
to our postmaster address.  Yes I realize someone had to have clicked 
something to allow this to happen (multiple people monitor the box).  But I 
cannot undo it.  I do not control the original mailbox the mail is being 
forwarded FROM.


Anyone have any tricks I'm missing?

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


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

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

[Hans-Martin Mosner via mailop]

Am 19.10.22 um 13:33 schrieb Heiko Schlittermann via mailop:

   554 IP=168.119.159.241 - A problem occurred. …

The sending IP belongs to a rented host (rented from a major German
hoster).

@mailops: What's your opinion?


I consider this unacceptable (at least when they don't offer a whitelisting 
option).

But there's another side to the story:

That hoster is Hetzner. With their equally unacceptable policies regarding abuse reports, they are at least partially 
creating this problem for their customers themselves.


If I lived in another part of the world, I would perhaps run a similar policy. There are a number of foreign providers 
with unhelpful attitudes towards spam reports, and those tend to enter our "reject-by-default" list sooner or later. We 
do offer a whitelisting option though, as spam checks are never 100% perfect.


Cheers,
Hans-Martin

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

Re: [mailop] Massive Spam Incident @ Outlook.com?

[Hans-Martin Mosner via mailop]

Am 10.10.22 um 15:25 schrieb Benoît Panizzon via mailop:

Hi Team

Anyone else observing an absurd increase of 'erotica' related spam
mails, most probably sent over phished Outlook.com accounts over the last 
couple of days?


On the account most affected by this, the wave seems to have stopped around 
17:15 UTC yesterday.

Impossible to say whether the spammer just got tired, or MS found an effective 
way to stop them.

Cheers,
Hans-Martin

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

Re: [mailop] Threat Update.. Tales from the Trenches..

[Hans-Martin Mosner via mailop]

Am 05.10.22 um 19:13 schrieb Michael Peddemors via mailop:


PS, don't know what o365 is doing, but a marked reduction in uncaught spam 
leaking from their networks..



Really? I'm seeing a constant stream of fake dating spam from apparently 
compromised O365 accounts, with no end in sight.

Many of them use link shorteners (mostly tinyurl.com), content text has so little variation that good old regex rules 
get all of them, so it seems to be just a single spamming operation. Targets are german, so that may be a reason you're 
not seeing those.


Looks like either password databases have been leaked somehow (although I consider that very unlikely) or the tenants 
get to implement their own password policies (which seem to be mostly "anything goes") so that newly created accounts 
get fixed or easily guessable passwords. I've yet to read another plausible explanation for this wide-spread compromising.


Cheers,
Hans-Martin

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

Re: [mailop] Gmail as well as Google Worskapce refuse all email from my domain

[Hans-Martin Mosner via mailop]

Am 02.10.22 um 13:56 schrieb Arek Patyk via mailop:

what is strange i have on this microsoft tenant another domain with
.digital suffix - and all mails from this domain are delivered to
gmail without any problems.


That might be an indication that the .pl TLD is at least part of the problem. The spam wave from compromised O365 
accounts on (not only but often) polish educational domains still continues, there does seem to be a general problem 
with how they are managed.


Cheers,
Hans-Martin

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

Re: [mailop] Gmail as well as Google Worskapce refuse all email from my domain

[Hans-Martin Mosner via mailop]

Am 02.10.22 um 12:44 schrieb Arek Patyk via mailop:

We have had MFA authentication on all accounts for years and we
checked all logs from email activity from last month. Compromising an
account is almost impossible. I must be something else.


It's not about you, it's about other Office365 customers who seem to be easily compromised (just judging by the 
statistics). Here's a list of just the polish O365 domains with compromised accounts seen in the last week, many of 
which seem to be educational institutions:


3lokonin.pl
edu.pckziuwalcz.pl
kasprzak.edu.pl
office365.spkeblowo.strefa.pl
office.reytan.edu.pl
pspilza.pl
redshift.net.pl
sp10nysa.edu.pl
sp4.ilawa.pl
sp4mm.edu.pl
sp6.elodz.edu.pl
sptolkmicko.szkola.pl
wmzdz.edu.pl
zs1plonsk.edu.pl
zs37.waw.pl
zs3.lukow.pl
zs-3.pl
zscl.pl
zsken.pl
zsropczyce.pl
zssam.edu.pl
zst.info.pl
zst-ostrow.edu.pl


But how to get info from google where the problem is?


Well, ... I don't know, sorry.

Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail as well as Google Worskapce refuse all email from my domain

[Hans-Martin Mosner via mailop]

There probably wasn't suspicious activity from your domain, but there has 
been a significant wave of fake dating spam sent via presumably compromised 
Office365 accounts. I've noticed such waves a number of times in the past, 
but haven't been able to get information about the root cause for such 
massive account break-ins. My guess is that there either has been some 
password file exfiltration (unlikely) or easily guessable standard 
passwords on newly created accounts. As most of the domains seem to be 
educational institutions, I suspect the latter.


I'm not in a position to influence Microsoft to enforce better password 
security on their hosted domains, and it's likely that their contracts 
wouldn't allow that anyway.


Cheers,
Hans-Martin

Am 2. Oktober 2022 12:05:05 schrieb Arek Patyk via mailop :


Hi,

I have my company domain hycom dot pl hosted on microsoft o365
exchange online for 7 years. Last week google servers stopped
accepting our mails. During last few days  I got:
550 5.7.350 Remote server returned message detected as spam -> 550
5.7.1 [40.107.22.60 7] Our system has detected that this message
is;likely unsolicited mail. To reduce the amount of spam sent to
Gmail,;this message has been blocked. Please visit;
https://support.google.com/mail/?p=UnsolicitedMessageError; for more
information. e17-20020a17090658d100b007833c7cf1dcsi6683774ejs.387 -
gsmtp

I have no idea what is going on and why.
Microsoft support  confirmed that there wasn't any suspicious activity.

I bought one  Google Workspace account to get support ;)
They said that my domain had a low reputation in Google, but he
couldn't say why. He advised me to wait...

I had definied SPF and DKIM
https://multirbl.valli.org/lookup/hycom.pl.html

Is there any way to contact someone in Google  who can help ?
Or any other idea what I can do more?

cheers,
Areq
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


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

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

[Hans-Martin Mosner via mailop]

Am 29.09.22 um 08:19 schrieb Alessio Cecchi via mailop:


I think it is not a correct behavior, if you can identify a message as unwanted 
why do you have to send it anyway?


Often such identification isn't 100% certain (in fact, no spam/ham distinction 
can ever be 100% correct).

Of course, if the message originated from a Microsoft customer it might be more reasonable to return it to the sender 
with an indication of what was considered questionable, but even the decision whether a message was created by the 
customer may be difficult in cases of mail forwarding etc.


Offloading the decision to the recipient at least ensures that no valid e-mail is ever prevented from reaching them, 
which is a (questionable IMO) legal requirement in the EU.


I'd rather prefer if they rejected identified spam instead of delivering it, but then I also want world peace. And a 
pony. With my luck, I'll get none of these.


Cheers,
Hans-Martin

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

Re: [mailop] mta4.de

[Hans-Martin Mosner via mailop]

Am 16.09.22 um 15:24 schrieb ask--- via mailop:

JFYI. new spam player from azure IP space calling themself "mta4.de" sending 
lottery spam.
first appearing in our logs yesterday. currently not yet listed at spamhaus.


Saw them too today. They were temp rejected because that's how we treat 
domains with NameCheap DNS (registrar-servers.com), for reasons... They 
retried in quick succession until I changed the temp reject into a perm 
reject for the domain.


Of course, those who gave them shelter (Microsoft/Azure as hosting 
provider, NameCheap as registrar and DNS provider, DENIC as registry) 
are unlikely to share any identifying information.


Cheers,
Hans-Martin

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

Re: [mailop] The oligopoly has won.

[Hans-Martin Mosner via mailop]

Am 13.09.22 um 07:57 schrieb Eduardo Diaz Comellas via mailop:


I agree with the general sense that GMail is misbehaving at spam management, both incoming and outgoing processing is 
flawed (in my opinion).


I will just talk from the gmail's customer side: a customer of mine moved to gmail. They still have secondary domains 
hosted with us. A couple of weeks ago they started to miss email sent from the gmail'ed domain to their secondary 
domains.


After investigation, several IPs used by gmail to send the email were blacklisted. I had a tough time explaining to 
the customer that it was gmail's fault to still use this IPs to send their email. Gmail never acknowledged the problem 
and didn't change the outgoing IP addresses. The problem was only "solved" when the blacklisting expired. And this was 
to a paying customer with 200 Gsuite accounts...


Best regards



That's an example why you should only blacklist a "grey" source if you have 
very good reasons to do so.

 * Either you don't reasonably expect legit mail from there, in which case your 
blocking would only affect spam, which
   is ok.
 * Or you want to "teach" the senders to leave the spam-supporting provider. To 
my knowledge, this rarely works, if
   ever. You will be seen as the bad guy, and even if the sender decides to 
change service providers they won't be
   happy with you causing them significant costs and trouble.

Even though I'm squarely with the people who think Google does too little against outgoing spam, a blacklist provider 
who lists their outgoing IPs should be avoided.


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] The oligopoly has won.

[Hans-Martin Mosner via mailop]

Am 12.09.22 um 22:29 schrieb Grant Taylor via mailop:

On 9/12/22 2:01 PM, Slavko via mailop wrote:

Thus it was not self-hosted, only (semi) self-managed ;-)


I don't agree.

If you use that mentality, nobody, not even Google, self hosts as they get their facilities -> connectivity -> domain 
-> bla bla bla from someone else.


I consider it self hosted if you run the MTA software on a system and are responsible from there up the stack. 


It's self hosted if you are visible as being responsible for it (i.e. have an IP range SWIPed to you, or have a rDNS 
entry which points to a domain that is associated with you).


If you take cover behind anonymous hosting, anonymous domain registration, etc. you're indistinguishable from those 
myriads spamming organization who use exactly those anonymization services to avoid being held responsible.


There's no responsibility if you can't be held responsible.

Cheers,
Hans-Martin

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

Re: [mailop] does outbound.protection.outlook.com ignore 550 for RCPT?

[Hans-Martin Mosner via mailop]

I'd guess that myprasarana.onmicrosoft.com is compromised (or has 
compromised accounts). I've seen this name before, reported the spam, and 
put it on our reject list. Don't know whether Microsoft failed to forward 
the spam report, or the tenant's admins are simply incompetent.


Cheers,
Hans-Martin

Am 7. September 2022 08:21:33 schrieb ml+mailop--- via mailop 
:



My system is getting spammed by outbound.protection.outlook.com

mail=
rcpt=, stat=550
rcpt=, stat=550

and this happens again and again.
(note: it happened before with other MAIL addresses)

It their MTA broken -- ignoring 550 for RCPT?
Or is the sender submitting the mail again and again?
the latter seems unlikely based on the logs:

Sep 6 22:18:13 mail=
Sep 6 22:19:16 mail=
Sep 6 22:20:19 mail=
Sep 6 22:21:21 mail=
Sep 6 22:22:24 mail=
Sep 6 22:27:26 mail=
Sep 6 22:32:28 mail=
Sep 6 22:37:31 mail=
Sep 6 22:42:33 mail=
Sep 6 22:47:36 mail=
Sep 6 22:52:39 mail=
Sep 6 23:02:42 mail=
Sep 6 23:12:45 mail=
Sep 6 23:22:49 mail=
Sep 6 23:32:53 mail=
Sep 6 23:42:57 mail=
Sep 6 23:53:01 mail=
Sep 7 00:03:05 mail=
Sep 7 00:13:09 mail=
Sep 7 00:23:12 mail=
Sep 7 00:33:15 mail=
Sep 7 00:43:18 mail=
Sep 7 00:53:22 mail=
Sep 7 01:03:26 mail=
Sep 7 01:13:30 mail=
Sep 7 01:23:34 mail=
Sep 7 01:33:37 mail=
Sep 7 01:43:40 mail=
Sep 7 01:53:44 mail=
Sep 7 02:03:47 mail=
Sep 7 02:13:51 mail=
Sep 7 02:23:54 mail=
Sep 7 02:33:57 mail=
Sep 7 02:44:01 mail=
Sep 7 02:54:05 mail=
Sep 7 03:04:09 mail=
Sep 7 03:14:12 mail=
Sep 7 03:24:17 mail=
Sep 7 03:34:21 mail=
Sep 7 03:44:25 mail=
Sep 7 03:54:29 mail=
Sep 7 04:04:32 mail=
Sep 7 04:14:35 mail=
Sep 7 04:24:39 mail=
Sep 7 04:34:42 mail=
Sep 7 04:44:45 mail=
Sep 7 04:54:49 mail=
Sep 7 05:04:54 mail=
Sep 7 05:14:58 mail=
Sep 7 05:25:02 mail=
Sep 7 05:35:05 mail=
Sep 7 05:45:09 mail=
Sep 7 05:55:13 mail=
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


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

Re: [mailop] SMTP noise from *.bouncer.cloud

[Hans-Martin Mosner via mailop]

Am 04.09.22 um 21:49 schrieb Radek Kaczynski via mailop:

> Those few domains with small traffic are:
> - bringmesomejuice.com 
> - iusedtolikeit.com 
> - sometimeinthepast.com 
> - mybigfluffyfriend.com 

You certainly realize why this marks your operation shady (just as most other 
e-mail verification businesses)?

Personal e-mail addresses are protected private information under european GDPR laws. When you process this data (and 
probing mail servers to see whether an e-mail exists is already some kind of processing) you need a valid reason under 
those laws, and of course you need to be identifiable, because the owner of such an e-mail address has a legal right to 
know who stores and processes their data for which purposes.


If you're using domain names registered through proxy services, hosted on a cloud provider who wouldn't reveal your 
identity unless we pry it from their cold dead hands, you're actively subverting these laws.


Of course, by stepping forward to participate in this discussion you're exposing yourself to quite some fire, that's 
pretty courageous and certainly a bit better than those cowards who prefer to stay anonymous. But still your business 
model is the same as theirs.


Even if you try to appear as friendly and open, would you be willing to reveal the names of your customers who requested 
an e-mail address verification if you were asked by the e-mail owner?


I had an exchange with someone from a similar service a while ago, after I found out that they (and some other mail 
validation services who didn't even reply to my request) have been trying to check an e-mail address on our server which 
did not exist (we reject such accesses without revealing whether the address exists or not). I set up the address as a 
spam trap when I noticed, and a very short time after this it received porn and fake dating spam. I asked the validation 
service who their customer was, and they could or would not tell me (they claimed that they didn't have that data 
anymore, I can't verify or falsify that claim, of course).


As soon as a validation service is transparent about who they work for when checking an address, I may exempt them. Fat 
chance.


Cheers,
Hans-Martin

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

Re: [mailop] State of the Union - Update due to activity..

[Hans-Martin Mosner via mailop]

Am 30.08.22 um 22:49 schrieb Michael Peddemors via mailop:

On 2022-08-30 13:33, Hans-Martin Mosner via mailop wrote:

I just checked a few samples, really can't be bothered to do it for all of them.

NameCheap (registrar-servers.com) DNS all over the place (in fact didn't find 
one that had another registrar).

It's gotten so bad that I refuse all traffic from domains with such DNS unless 
they are explicitly whitelisted.



I get the frustation.. Should point out they 'have' been getting better and more pro-active on addressing abusive 
domains..


But if we adopted that policy (It's gotten so bad..) we would be blocking Gmail 
by now *toungue in cheek*


I do. Gmail addresses need whitelisting now. It's **really** gotten so bad.

Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] State of the Union - Update due to activity..

[Hans-Martin Mosner via mailop]

I just checked a few samples, really can't be bothered to do it for all of them.

NameCheap (registrar-servers.com) DNS all over the place (in fact didn't find 
one that had another registrar).

It's gotten so bad that I refuse all traffic from domains with such DNS unless 
they are explicitly whitelisted.

Cheers,
Hans-Martin

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

Re: [mailop] unknown domain in MAIL (outlook.com)

[Hans-Martin Mosner via mailop]

In my experience, most of outlook.com emitted spam mails are from 
compromised accounts, very often at educational institutions who may be 
allocating student accounts en masse with standard passwords (just 
guessing). I report them, but as most large mail providers, they don't seem 
to reply with any meaningful info on whether they stopped the spam and what 
they did.


Cheers,
Hans-Martin

Am 11. August 2022 10:51:10 schrieb ml+mailop--- via mailop 
:



My system is getting spammed by outbound.protection.outlook.com

First they are sending every 10 minutes to the same two unknown
addresses until I blocked the sender (@emss.gov.eg) then it stopped.

Now they are sending to the same addresses using
lr...@incm.gov.uk
as sender -- AFAICT the domain does not exist at all.
Isn't that something which should be checked by them
(it seems such a trivial thing to do)?

--
Address is valid for this mailing list only, please do not reply
to it directly, but only to the list.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


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

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Hans-Martin Mosner via mailop]

My main question would be: what do you hope to gain?

There are some legit senders who still use non-encrypted mail. And as long as 
we don't want to take on the tedious task of educating those senders or 
convincing our users that they don't want to get mail from those senders, we 
need to allow it.
Disabling support for less secure transport encryption protocols doesn't 
increase security if the senders can then switch to unencrypted transport as a 
fallback.

If you're Google or Microsoft, you might be able to pull that off. Otherwise it 
only works if your users are willing to live with the consequences.

FWIW, rejecting unencrypted connections also does reduce the amount of spam a 
little bit, but it's almost unnoticeable in my experience.

Cheers,
Hans-Martin

3. August 2022 13:34, "Sidsel Jensen via mailop" mailto:mailop@mailop.org?to=%22Sidsel%20Jensen%20via%20mailop%22%20)>
 schrieb:
Hi MailOps

We were having a discussion on the possibility to disable TLS 1.0 and 1.1 for 
MTA to MTA communication, and based on the numbers we've seen so far, it 
doesn't look that far fetched.

What's the common consensus in the mail community about this currently?

It's already been disabled for our customers towards fx. imap and smtp, and we 
all agree those pesky old versions should be phased out, sooner rather than 
later, but have you also disabled it for MTA to MTA communication as well or 
are you still considering it? And what scenarios are currently holding you back?

And what about PLAIN - do you still allow that as the fallback option or are 
you also considering disabling that?

I'm looking forward to read your replies :-)
Kind Regards,
Sidsel Jensen

Architect of Deliverability and Abuse @ Open-Xchange
___
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?

[Hans-Martin Mosner via mailop]

23. Juli 2022 00:54, "Atro Tossavainen via mailop"  schrieb:

> Er, I think you mean
> 
> https://msbl.org/ebl.html

Yeah, basically that, except that i'm thinking of a somewhat wider scope by 
also covering compromised mailboxes, which gets closer to the PII danger zone 
as those woould belong to individuals more likely than the typical spammer 
addresses which are probably controlled by spammer teams or at least have not 
the slightest relation to the particular spammer using them.

But the presence of the EBL shows that other people think that hashed e-mail 
addresses are reasonably safe to handle, even though they (like most BL 
operators) prefer to stay somewhat anonymous. That's at least a partial answer 
to my concerns.

Cheers,
Hans-Martin
___
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?

[Hans-Martin Mosner via mailop]

22. Juli 2022 22:20, "Luis E. Muñoz via mailop"  schrieb:

> Going back to the example of an ESP, does the hash of the email address 
> equate the email address as
> per GDPR?

This probably reaches well into the area of legal expertise and may therefore 
be off-topic here, but it would be very interesting to know what people think 
about this anyway.

Especially in the area of freemailer spam (and somewhat ESP spam, of course), 
hashes of spammy mail senders could be used to share reputation among mailops 
without handling actual e-mail addresses. I could contribute dozens of fresh 
advance fee fraud gmail address hashes every day, which could potentially be 
used by others to refuse unsolicited mail.

Cheers,
Hans-Martin
___
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?

[Hans-Martin Mosner via mailop]

Am 22. Juli 2022 11:34:16 schrieb Laura Atkins via mailop :





ESPs have many, many problems, but the fixes being suggested here on mailop 
are overly simplistic and evidence a lack of conceptual understanding of 
how bulk email is sent in 2022.
Suggested technical fixes are certainly too simplistic when they are based 
on insufficient understanding of how bulk email is being handled.


However, there are some basic requirements which should enable ESPs to keep 
their shop relatively free from spam:


* Have clear contractual rules against unsolicited email, together with 
clear consequences when those rules are violated.
* Have a working and knowledgeable abuse desk that is able to discern 
whether complaints are spurious or a sign of systematic unsolicited email 
sending.
* Authorize this abuse desk to restrict service to a customer until issues 
are resolved.

* Know your customer in the first place, to avoid onboarding repeat offenders.
* And of course, have management buy-in about spam prevention. An abuse 
desk working against sales and management interest will inevitably fail.


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Request for contact details of the postmasters of freenet.de

[Hans-Martin Mosner via mailop]

Am 05.07.22 um 14:45 schrieb Klaus Tachtler via mailop:

Hi,

I would look for contact information for the postmasters at freenet.de, as we have a problem with bulk email delivery 
to that provider.


Unfortunately, we have not yet received any response to the contact form on the freenet.de homepage, nor have we 
received any response to the usual e-mail addresses to postmaster and hostmaster. 


I had some mail exchange with postmaster at freenet.de regarding the problem (I assume it's the same issue that you 
have) around June 14. After that, no further responses to my questions, so maybe the (single) postmaster is on vacation 
or they don't like to be pestered with deliverability problems of people who aren't their customers.


Cheers,
Hans-Martin

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

Re: [mailop] Someone from freenet.de on this list?

[Hans-Martin Mosner via mailop]

Am 25.05.22 um 07:59 schrieb Hans-Martin Mosner via mailop:

Please contact me off-list.

Your "rate-limiting" handling of non-SPF mail isn't rate-limiting but blocking 
legitimate traffic.

Cheers,
Hans-Martin


So it's been a month since that problem raised its head, and after several mail exchanges there's not a satisfying 
solution. Legit traffic is still blocked with a nonsensical tempfail error message.


Here's the scoop:

Our (not heeg.de's but another domain's) users are individual church congregations which use Mailman mailing lists for 
coordination of working groups, member information, etc. So it's clean opt-in, not unsolicited bulk e-mail, and of 
course if there are any complaints (people change their minds, and human errors happen) we resolve them with the 
associated parties quickly. Most of the lists predate the invention of DMARC by years or decades...


Now Freenet.de started to interpret DMARC strictly and to refuse acceptance of mails with broken DKIM and SPF with the 
rather cryptic error message "458 Ratelimit exceeded". Took me a while and some mail conversation to figure out what 
that really means...


Now we could switch on DMARC mitigations in the mailing lists - I've notified the owners of the affected lists about 
this, but I'm not yet convinced that I should toggle this globally without list owner's agreement. And this change would 
not help the currently queued mails of course.


Since freenet.de seems to be the only mail provider that does this (and does not seem to be open to exempting mailing 
list servers, as many others do) I'm trying to get a clearer understanding of whether it would be reasonable to just 
bite the bullet to comply with their extreme interpretation, or to be more adamant in requesting an exception. Other 
huge providers seem to be able to handle this without an issue.


What do you think? As the DMARC designers didn't consider the needs of mailing lists, who should carry most of the 
burden in working around this design failure?


 * The sender mail systems publishing DMARC records (over which the sending 
users don't have any control)?
 * The recipient mail systems interpreting DMARC (over which the recipients 
don't have any control)?
 * The mailing list operators sitting in the middle who didn't choose DMARC but 
are still affected by it?

Cheers,
Hans-Martin___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] OVH contact required - 54.38.34.203 - vps-28239cc9.vps.ovh.net

[Hans-Martin Mosner via mailop]

Am 20.06.22 um 20:25 schrieb Hans-Martin Mosner via mailop:

Am 20.06.22 um 07:35 schrieb Hans-Martin Mosner via mailop:
I've reported a list of a few dozen IPs at OVH that are clearly used by one snowshoe spammer to Pierre-Edouard and to 
abuse@OVH, but to no effect.


Today I see an effect, very nice. All of those (including the ones that I didn't report yet because I only saw them 
later) are gone. Thumbs up! 


Spoke too early. Looks like the spammer just removed recipients from their list whose host isn't reachable (because they 
are in our IP block list). Still sending to other recipients, though, so apparently not terminated by OVH.


So thumbs down again. And sorry for self-responses, I'll stop now.

Cheers,
Hans-Martin

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

Re: [mailop] OVH contact required - 54.38.34.203 - vps-28239cc9.vps.ovh.net

[Hans-Martin Mosner via mailop]

Am 20.06.22 um 07:35 schrieb Hans-Martin Mosner via mailop:
I've reported a list of a few dozen IPs at OVH that are clearly used by one snowshoe spammer to Pierre-Edouard and to 
abuse@OVH, but to no effect.


Today I see an effect, very nice. All of those (including the ones that I didn't report yet because I only saw them 
later) are gone. Thumbs up!


There are some more to go, though :-)

Cheers,
Hans-Martin

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

Re: [mailop] OVH contact required - 54.38.34.203 - vps-28239cc9.vps.ovh.net

[Hans-Martin Mosner via mailop]

Am 15.06.22 um 10:40 schrieb Pierre-Edouard Caron via mailop:


I’m not aware about their process but I know that they wait multiples reports 
before to block.
They are improving the pipeline to give more notifications that the report have 
been handle.

I've reported a list of a few dozen IPs at OVH that are clearly used by one snowshoe spammer to Pierre-Edouard and to 
abuse@OVH, but to no effect.


Apparently "improving the pipeline" does not involve "working on the issues", maybe "deciding on a color scheme for 
abuse reporting web form" is eating up all of the committe meeting time? :-)


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] freenet anybody?

[Hans-Martin Mosner via mailop]

Am 09.06.22 um 12:17 schrieb Heiko Schlittermann via mailop:

Hi,

I'm seeking a responsible person for freenet.de. We're running into
their ratelimits and need more information, in order to track this issue
on our side.

 Best regards from Dresden/Germany
 Viele Grüße aus Dresden
 Heiko Schlittermann


I posted the same issue on May 25th. No response, so they don't seem to have 
anybody on this list.

It's gotten a little better after I implemented SRS, but it's not completely 
gone.

And it's somewhat unclear what their interpretation of "rate limiting" is - looks more like "we're blocking your mail 
until someone decides to unblock" :-)


Cheers,
Hans-Martin

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

[mailop] Leaseweb

[Hans-Martin Mosner via mailop]

Hi,

it's probably no surprise to anybody, but Leaseweb is a confirmed spammer haven.

I gave it a last try today, reporting a number of IP addresses which are 
apparently operated by just one spammer.

Positive results:

 * Leaseweb accepts e-mail complaints to the abuse address listed in their IP 
whois record. Yay!
 * They have a ticket system that's simple, easy to use, looks nice, extracts 
IP addresses and domain names from abuse
   report mails. That's much more than many other providers do!

Negative results:

 * The spam still continues.
 * Their bot response basically says
   /Your abuse notification has been processed and marked as resolved by our 
customer. Leaseweb therefore considers
   this issue as concluded./
 * Of course, their notion of "resolved" and "concluded" is different from 
mine. I would have expected that the spam
   stops, but no, not with Leaseweb.

Outcome of the experiment:

Leaseweb IP ranges will go into the IP level block list, to be removed whenever I feel like it after having too much 
beer, or the server gets rebooted (approx. once every 1-2 years).


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Fwd: *** SPAM *** Sparkpost sending spam on behalf of \"Time Travel Promotion LP\"

[Hans-Martin Mosner via mailop]

Am 21.05.22 um 18:46 schrieb Kent McGovern via mailop:

I sent this directly to Hans-Martin, wanted to share it with the list as well.

Kent McGovern
Sr.Deliverability Strategist
Sparkpost

-- Forwarded message -
From: *Kent McGovern* 
Date: Sat, May 21, 2022 at 10:26 AM
Subject: Re: [mailop] *** SPAM *** Sparkpost sending spam on behalf of \"Time Travel 
Promotion LP\"
To: Hans-Martin Mosner 


Hi Hans-Martin,

Thank you for letting us know. We will investigate this issue and get back to 
you.


While I appreciated that response, I'm somewhat disappointed with the action.

The spammer continues to send their spam mail. Looks like they convinced Sparkpost that what they're doing isn't spam 
but valuable information sent to a hand-picked audience who *wants* that information.


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Contact at Contabo?

[Hans-Martin Mosner via mailop]

Ok, I'll wait a bit. Initial mail was on Sunday, so a response on Monday 
would be pretty quick, but not something one should depend on :-)


Am 31. Mai 2022 08:57:01 schrieb Carsten Schiefner via mailop 
:



Morning, Hans-Martin -

On 31.05.2022 07:26, Hans-Martin Mosner via mailop wrote:

does anybody have a working contact at Contabo? Mail to abuse@ does not
seem to have an effect.


last time I have been in touch with them as their customer, it took them
four working days to get back to me, although on a mere and totally
non-urgent FYI message.

Inbound was , outbound however was .

Best,

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


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

[mailop] Contact at Contabo?

[Hans-Martin Mosner via mailop]

Hello,

does anybody have a working contact at Contabo? Mail to abuse@ does not seem to 
have an effect.

Cheers,
Hans-Martin

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

Re: [mailop] *LIKELY SPAM 27.9* Re: Any reason to NOT block the entire .cam domain?

[Hans-Martin Mosner via mailop]

Am 27.05.22 um 21:38 schrieb Michael Rathbun via mailop:


Here are the domains this gang has used in the last seven days:


If you look up the MX records for these domains, you see a certain clustering around one provider. The IP addresses that 
I checked don't accept port 25 connections at this time, but probably they did when the spam run was active.


Whether blocking a whole ASN is more advisable than blocking a whole TLD is a matter of opinion - I've often seen that 
past spammer hosting in an ASN's IP space was a good predictor for future spamminess, but of course as with TLDs you 
will always have some legitimate servers in the mix...


Cheers,
Hans-Martin

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

Re: [mailop] Forum/Blog spam turned up to 11

[Hans-Martin Mosner via mailop]

Oops, I didn't read your post to the end, with invalid target addresses 
it's likely a different thing. Early in the morning, not the time I should 
talk, high chance of uttering nonsense :-(


Am 27. Mai 2022 07:34:06 schrieb Hans-Martin Mosner via mailop 
:
This is most likely reflector spam containing URL shortener links (bit.ly, 
u.to, or some other) in the name field of contact forms.


Depending on scale, I would advise either to switch off automatic 
confirmation of contact form submissions and always respond personally when 
submissions are serious, or at least checking non-URL fields for URL 
contents and blocking the submission in that case.


External systems which send this kind of spams can be considered 
"exploited" and will be blocked at the server where I manage the mail 
system, and accordingly, our users are strongly discouraged from generating 
automated replies in their web forms, as I don't want our server to be 
categorized as spam-emitting by others.


Cheers,
Hans-Martin

Am 27. Mai 2022 01:18:15 schrieb Jarland Donnell via mailop 
:



Over the last week or so I've noticed an exceptional increase in
outbound emails from my customers to invalid recipients. Obviously this
is problematic but understandable. All of the customers in question run
websites that send an email to confirm registration, and all of the
recipients are properly formatted email addresses. They just don't
exist, and they're increasing at an unusual rate. Others may have the
same going on but may not yet be aware of the pattern. My hope is that
by sharing the pattern others might begin to fight against it as well.

Here is a look at some censored logs: https://clbin.com/Gxeoo

Notice the trend being username + 4 digits, primarily at free email
providers and regional ISPs. Examples:

heidireynoldsplad2...@gmail.com
susanpowersvgjfae2...@cox.net
pabloharveyfhi6...@rediffmail.com
florencenashhqjqj8...@orange.fr
carlosfranklinlydy2...@comcast.net

It's really off the charts, and it's impacting a wide variety of
customers who have no relation to each other. The only similarity being
that they send out website registration confirmations in all cases.

Of course, my first theory is forum spam / blog comment spam. Even if
they can't accomplish the spam, they have most likely built complete
automation to handle this process of mass registrations for a wonderful
"spray and pray" technique. Since the email accounts don't exist,
they're most likely hoping that a confirmation isn't actually required
to begin submitting content to the sites that they register on.

Use this how you will <3

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


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


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

Re: [mailop] Forum/Blog spam turned up to 11

[Hans-Martin Mosner via mailop]

This is most likely reflector spam containing URL shortener links (bit.ly, 
u.to, or some other) in the name field of contact forms.


Depending on scale, I would advise either to switch off automatic 
confirmation of contact form submissions and always respond personally when 
submissions are serious, or at least checking non-URL fields for URL 
contents and blocking the submission in that case.


External systems which send this kind of spams can be considered 
"exploited" and will be blocked at the server where I manage the mail 
system, and accordingly, our users are strongly discouraged from generating 
automated replies in their web forms, as I don't want our server to be 
categorized as spam-emitting by others.


Cheers,
Hans-Martin

Am 27. Mai 2022 01:18:15 schrieb Jarland Donnell via mailop 
:



Over the last week or so I've noticed an exceptional increase in
outbound emails from my customers to invalid recipients. Obviously this
is problematic but understandable. All of the customers in question run
websites that send an email to confirm registration, and all of the
recipients are properly formatted email addresses. They just don't
exist, and they're increasing at an unusual rate. Others may have the
same going on but may not yet be aware of the pattern. My hope is that
by sharing the pattern others might begin to fight against it as well.

Here is a look at some censored logs: https://clbin.com/Gxeoo

Notice the trend being username + 4 digits, primarily at free email
providers and regional ISPs. Examples:

heidireynoldsplad2...@gmail.com
susanpowersvgjfae2...@cox.net
pabloharveyfhi6...@rediffmail.com
florencenashhqjqj8...@orange.fr
carlosfranklinlydy2...@comcast.net

It's really off the charts, and it's impacting a wide variety of
customers who have no relation to each other. The only similarity being
that they send out website registration confirmations in all cases.

Of course, my first theory is forum spam / blog comment spam. Even if
they can't accomplish the spam, they have most likely built complete
automation to handle this process of mass registrations for a wonderful
"spray and pray" technique. Since the email accounts don't exist,
they're most likely hoping that a confirmation isn't actually required
to begin submitting content to the sites that they register on.

Use this how you will <3

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


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

[mailop] Someone from freenet.de on this list?

[Hans-Martin Mosner via mailop]

Please contact me off-list.

Your "rate-limiting" handling of non-SPF mail isn't rate-limiting but blocking 
legitimate traffic.

Cheers,
Hans-Martin

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

[mailop] *** SPAM *** Sparkpost sending spam on behalf of \"Time Travel Promotion LP\"

[Hans-Martin Mosner via mailop]

Hi,

just a heads-up about ESP Sparkpost. They are delivering spam mail for "Time Travel Promotion LP" (using sending domains 
findingsale.com, offer-experts.com, perfect-quotes.com, quotes-expert.com, service-expert.net, verticalmailer.com, 
yougetnow.com).


Most of these domains have no identifying information, but verticalmailer.com 
points points to Time Travel Promotion LP.

I've notified Sparkpost about this spammer back in February, did not get a 
response, so I sent another mail today.

You might want to advise potential users of ESP services that Sparkpost may 
offer limited deliverability.

Cheers,
Hans-Martin

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

Re: [mailop] To Sendinblue, Mailjet, SES, ActiveCampaign, and every other

[Hans-Martin Mosner via mailop]

Am 10.05.22 um 10:29 schrieb Jarland Donnell via mailop:

I need these two email addresses removed from EVERY newsletter on EVERY 
platform:

jarl...@mxroute.com
ab...@mxroute.com

Sendinblue, Mailjet, SES, ActiveCampaign, and every other company that fits in a category with these companies. I know 
there are representatives in this mailing list. I am so sick and tired of reporting every single spam email and maybe, 
just maybe, I get removed from one newsletter a week. I was maliciously attacked, my inboxes registered for an ungodly 
amount of mailing lists that did not use any kind of double opt in standards. These mailing lists are all supported by 
the companies mentioned. I am done with single reports and mostly being ignored. I need representatives from these 
companies to push a message up the chain: Find EVERY mailing list with these two emails in them and REMOVE them.


Thank you, and apologies for the time wasted by anyone else who took a moment 
to read this.


If the companies mentioned read as far as this, here's a very serious 
suggestion:

Don't just remove the addresses from customers' lists, but remove the customers, as they are obviously using addresses 
without consent, which would be against your AUP (you do have an AUP that requires confirmed opt-in, do you?). Make 
notes to ensure that you don't accept them as customers in the future.


If your customer accounts were hacked, you can probably share the guilt with them. Your procedures regarding 
transmission of recipient lists should require sufficient authentication, preferably using some 2FA mechanism. This 
isn't rocket science!


Cheers,
Hans-Martin

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

[mailop] Sendinblue sending suspicious mails claiming to be from DEKA GreenVest

[Hans-Martin Mosner via mailop]

Hello,

just a heads-up: It looks like a current e-mail campaign sent out by SIB on behalf of "gvestdeka.com" and directing 
recipients to "deka-bankdepot.com" facilitates bank account phishing.


gvestdeka.com is registered through dynadot.com. They probably won't reveal the 
identity of their customer, of course.
Creation Date: 2022-05-04T15:17:27.0Z

deka-bankdepot.com is registered through "REG.RU Protection Service" which 
instills a certain level of trust ... NOT.
Creation Date: 2022-05-02T21:26:04Z

Sendinblue, do you verify the identity of customers who send banking-related 
campaigns AT ALL?

Yours,
Hans-Martin

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

Re: [mailop] Understanding specific issue with from header field in google bounce reply

[Hans-Martin Mosner via mailop]

The base-64 encoding must only be done on the "comment" part of the From 
address, not on the "" part.


Cheers,
Hans-Martin

Am 2. Mai 2022 09:14:09 schrieb Alexander Neilson via mailop 
:

Hi Team

Please feel free to let me know this was not a suitable question for this 
list, apologies in advance if so.


At $dayjob one of my fairly new staff forwarded me a bounce message from 
gmail for an outbound email we were sending to a supplier.


Headers are down at the end of the email but the bounce message was:
554
5.0.0 

A test email sent from the same system to my own emails (hosted by gmail) 
didn't receive a bounce back so I am of the feeling there must be a From: 
header being included correctly in the message. So trying to investigate 
the header as to why it may not be a valid address and I was hoping for 
some assistance / guidance as to if I am interpreting the RFC correctly as 
to validity or am I barking up the wrong tree entirely.


The user whose email bounced has a last name with an accented character 
which is not a valid ASCII printable character and if I am reading RFC 6854 
S2.1 and RFC 5322 S2.2 correctly the header field must contain printable 
ASCII code points (and a couple of allowed other characters in the header 
field body.


I did note that the from header in the bounced email was shown as:
=?utf-8?b?IkZlcm5hbmRvIFNhbnRvcyBEZSBTw6EiIDxmZXJuYW5kby5zQGdsLmNvLm56?=
=?utf-8?b?Pg==?=
Converting this from Base64 encoded UTF-8 into plain UTF-8 I see the string:
"Fernando Santos De Sá" 
Which is correct for my user (however obviously not ASCII.

A few questions
Have I correctly identified the issue (or most likely issue) triggering 
this message from gmail?
Is there a good document for guidance on catching invalid values (including 
UTF-8 strings) and how they should be handled for headers in email (I see 
in RFC 5322 S3.2.4 there is an allowance for quoted strings that allow 
characters that are other than allowed in atoms but I guess if that was 
valid for what I was generating above the email wouldn't have bounced - 
possibly an issue because the whole string was Base64 encoded?) so I can 
look to catch situations that are problematic in future and provide a 
generalized system?
Does anyone have any guidance on other situations they have hit with email 
systems rejecting what is often accepted so I can try to generally test for 
known "fun interactions" and handle them?


(noting these emails are generated out of our in house developed operations 
management system so its my code that did the wrong thing originally here 
and what I need to get fixed)


Thank you for your time.

Headers from the bounce:

Notes:
email system isn't currently depositing emails into the sent box so user 
receives CC of emails sent on their behalf so they see what has gone out
antispamcloud is our spam filter provider who scans all inbound and 
outbound emails but error message was generated by gmail when trying to 
hand off the email. Providers web portal for checking message status 
decoded source email address and name string.


Original
message headers:
Return-Path: 
Received: from gl-ex02.gl.co.nz ([45.118.188.115])
   by mx262.antispamcloud.com with esmtps 
   (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128)

   (Exim 4.92)
   (envelope-from )
   id 1nlMq1-000A9Y-Mo
   for ; Mon, 02 May 2022 05:35:15 +0200
Received: from GL-EX02.internal.gl.co.nz (192.168.33.22) by
GL-EX02.internal.gl.co.nz (192.168.33.22) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.2.1118.7; Mon, 2 May 2022 15:35:02 +1200
Received: from gl-be04.internal.gl.co.nz (192.168.33.37) by
GL-EX02.internal.gl.co.nz (192.168.33.22) with Microsoft SMTP Server id
15.2.1118.7 via Frontend Transport; Mon, 2 May 2022 15:35:02 +1200
Content-Type: text/plain
MIME-Version: 1.0
From: =?utf-8?b?IkZlcm5hbmRvIFNhbnRvcyBEZSBTw6EiIDxmZXJuYW5kby5zQGdsLmNvLm56?=
=?utf-8?b?Pg==?=
To: 
CC: 
Subject: Global Jobsheet  - Fixing
Message-ID: <0368d464-ce75-4993-893a-6861eaebc...@gl-ex02.internal.gl.co.nz>
Date: Mon, 2 May 2022 15:35:02 +1200
X-Originating-IP: 45.118.188.115
X-MailAssure-Domain: gl.co.nz
X-MailAssure-Username: 45.118.188.115
Authentication-Results: antispamcloud.com; auth=pass 
smtp.auth=45.118.188@gl.co.nz

X-MailAssure-Outgoing-Class: ham
X-MailAssure-Outgoing-Evidence: Combined (0.09)
X-Recommended-Action: accept
X-Filter-ID: 
Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/SWj98WPq4CtCgxem7mj3kPUtbdvnXkggZ

3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yFJoHAUTOjf1aFNKd7CnV+O+QzD67WU21zwtdtt9m3QQ/C
h5SE4jAyhe1COeASyU/5LRRHPJulhFeIJoq48nHN5WCy5VkstzhnxgTXqsdmp0LoMm7rojSS/Sxh
qDMvUmM1LQhYNBd1FP7U4OZT407FpuGXed8VjoeeEKguXydrkSH+3gVyyqW6++HqPXPhE0NcYe4a
MjKFhzJKmH0BGgJrQLk01CIbYZxgOAvibIM/Z6W7d1t4HzZ7ipKhj9PWSiyZOZh/196Uh/xDSW9g
kA3LEWgKIJ7Ay0RVJqlA03GHx5mIvc52cbna8kydvLENQgQtChAJ8MhPXbXvhZAyklffRAwX31WV
Y5lWjWxuGSRuxRfiiXKDnS3cS+VcIvEFMphhKzy27dJ+eI97x1+KvbnG5YE5enyccp7RH4WQio3u

Re: [mailop] Does anyone know, how operates h-email.net email service?

[Hans-Martin Mosner via mailop]

Am 29.04.22 um 15:16 schrieb Benoît Panizzon via mailop:

Hi List

Privacy Policies make it hard for us to solve the email issue of one of
our customers.


I could rant quite a bit about misguided privacy in the operation of networking services but I'll better stop before I 
start...


As everybody involved refuses to cooperate in solving your customer's problem, maybe you or your customer needs to use 
legal tools to get them to cooperate. I don't get exactly what your customer's problem is, but if there is some kind of 
damage done to their reputation or data privacy it should be possible to file a criminal charge against unknown persons 
(listing the involved parties as possible accomplices) which may enable ways of getting the identity information 
currently withheld by the involved parties.


Consulting a law expert may be a good idea, I'm not one and I don't even play 
one on the internet.

Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Hans-Martin Mosner via mailop]

Am 18.04.22 um 21:02 schrieb Bill Cole via mailop:

On 2022-04-18 at 13:32:07 UTC-0400 (Mon, 18 Apr 2022 12:32:07 -0500)
Larry M. Smith via mailop 
is rumored to have said:


...
I'm going to disagree.  To the best of my knowledge Yahoo, Vz, AOL, or 
Microsoft do NOT re-queue messages after receiving a 5xx response -- Qmail does.


Did you mean "GMail?"

FWIW, I've not seen GMail (or Qmail) do that. Do you know how to reproduce it?

I have a current sample where GMail did this. They apparently do it for 5.7.1 responses to DATA only, and not always, 
but I don't have complete statistics for this.


Here are the log entries for the recent run (which were rejected after DATA due to a known-spammer body pattern, which 
is one possible way to keep the ever-changing GMail 4-1-9ers somewhat in check.) Note that identical message ID provies 
that this isn't the spammer repeatedly trying to get his/her fraud message across, but Google trying to force the spam 
down our throat :-)


Apr 18 19:43:34 mail postfix/cleanup[23243]: 7D1D4120D85: 
message-id=
Apr 18 19:50:22 mail postfix/cleanup[24996]: 7C34B120D72: 
message-id=
Apr 18 20:13:48 mail postfix/cleanup[27908]: 8189A120D84: 
message-id=
Apr 18 20:40:41 mail postfix/cleanup[459]: 059EB120D0C: 
message-id=
Apr 18 21:25:48 mail postfix/cleanup[15781]: DAAD7120D74: 
message-id=
Apr 18 22:16:56 mail postfix/cleanup[28107]: 43595120D0C: 
message-id=
Apr 18 23:43:07 mail postfix/cleanup[14675]: 0F230120D30: 
message-id=
Apr 19 01:13:13 mail postfix/cleanup[25151]: 50B47120D0C: 
message-id=
Apr 19 02:44:45 mail postfix/cleanup[9739]: 23C56120D0C: 
message-id=
Apr 19 04:30:16 mail postfix/cleanup[29190]: 74078120D0C: 
message-id=
Apr 19 06:18:44 mail postfix/cleanup[16471]: D7F3B120D0C: 
message-id=


When I detect those in the logs I add the MAIL FROM address to the known-spammer list, which causes the mail to be 
rejected earlier in the SMTP dialogue and seems to stop the retries. Most times I don't care whether they're retrying 
repeatedly, though, it costs more of their resources than mine.


Cheers,
Hans-Martin

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

Re: [mailop] does ESP have the preference for email domains

[Hans-Martin Mosner via mailop]

Actually, it's not a strict block, but we temp reject first, and switch to 
accept or reject with a mitigation web form address. So, don't let our 
policy discourage you!


Cheers,
Hans-Martin

Am 18. April 2022 13:15:09 schrieb wilson via mailop :


I am sorry that one small operator has noticed me by PM that he does
block email based on TLDs such as this one I am using.

Laura Atkins via mailop wrote:

I don’t believe folks are blocking based on TLDs. I also recommend that
senders stick to the more common and ’standard’ TLDs. I don’t actually
see a contradiction here.

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


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

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

[Hans-Martin Mosner via mailop]

Am 08.04.22 um 18:37 schrieb Brayden via mailop:

Digital Ocean blocks port 25 by default and I've heard getting it unblocked can 
be a nightmare.

https://docs.digitalocean.com/support/why-is-smtp-blocked/

It's definitely a non starter for e-mail. Linode does the same but their guide is 10x more helpful so I reckon there's 
much better odds of it working 


Sadly, neither DO nor Linode gets a real grip on those of their customers who either are being exploited or are 
deceptive spammers themselves. DO is perm blocked here (with the option to whitelist individual IPs when justified) due 
to their non-responsiveness to abuse reports, and Linode is very close to it.


Cheers,
Hans-Martin

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

Re: [mailop] Business Office 365 hosted Exchange IP Addresses shared between customers? Lateral damage on spam sending customer.

[Hans-Martin Mosner via mailop]

Friends don't let friends run mail servers on shared cloud services.

Seriously, mail is a reputation thing. If your IP address or IP range has a 
bad reputation because you have to share it with scum, don't be surprised 
that your mail isn't getting through. If you don't use your own domain name 
that hopefully has a positive reputation, don't expect good deliverability.


When reputable cloud providers want to sell their services as suitable for 
e-mail they need to get a grip on abuse. What I see from the big ones such 
as Microsoft, Google, Amazon, Linode, Digital Ocean, OVH is pretty 
underwhelming. A lot of smaller ones apparently are good enough at keeping 
spammers out that they're completely under my radar. Of course, I see very 
little, so others may have better data on those.


Cheers,
Hans-Martin


Am 29. März 2022 10:21:04 schrieb Benoit Panizzon via mailop 
:



Hi List

One of the local electricity plants is sending invoices via hosted
Office 365 emails services to it's customers, many hosted on our email
platform. It's a larger Office 365 customer.

Many of those emails were rejected as spam. So they opened a case with
our abuse desk. I noticed their IP address was blacklisted for a
couple of days and managed to get an evidence of the email that caused
the listing.

It was definitely spam and it looks like it was sent by a different
Office 365 customer which shares the same Office 365 'outlook.com'
outbound IP address. It's not yet clear ob this was due to one of their
accounts being phished or if they 'purchased' web-harvested spamtrap
addresses somewhere.

Can Office 365 customers request a static IP address from Microsoft to
avoid such issues, or is this something they have to live with?
Unfortunately they also seem not to get any support from Microsoft when
facing such an issue.

Mit freundlichen Grüssen

-Benoît Panizzon-
--
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


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

[mailop] Bogon? 81.70.92.213

[Hans-Martin Mosner via mailop]

Hi folks,

in a trustworthy Received: line of a spam I found the source IP 81.70.92.213. Strangely, this IP is pingable, and 
traceroute finds a way, but neither the IP whois nor the BGP looking glass show to whom it belongs. Not being really 
knowledgeable about the global routing mechanisms, this somehow looks like a bogon to me.


Did anyone else see IPs in that vicinity and has a better explanation?

Cheers,
Hans-Martin

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

Re: [mailop] large number of mail connections

[Hans-Martin Mosner via mailop]

Am 20.03.22 um 00:57 schrieb Geoff Mulligan via mailop:

I have 3 different mail servers that are currently being inundated with mail 
connections from:

109.237.103.42

This appears to be from Russia - go figure.

Geoff


HostGlobalPlus - I've blocked the whole 109.237.96.0/21 at the IP level and even as a "Received:" header matching rule, 
nothing good ever came from there.


Cheers,
Hans-Martin

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

Re: [mailop] Mass of Spam from Linode Networks associated with wewe.global

[Hans-Martin Mosner via mailop]

Same spammer is using <> sender addresses now, with a wild mixture of atlassian.net, trend-global.com, google.com, 
sparkpostmail.com domains mentioned in various header lines. All fake I presume.


Cheers,
Hans-Martin

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

Re: [mailop] Mass of Spam from Linode Networks associated with wewe.global

[Hans-Martin Mosner via mailop]

Am 10.03.22 um 15:54 schrieb Jim Ackley via mailop:
Thanks to everyone who submitted an abuse report for this so far. Our Trust & Safety team is aware of an uptick of 
spam reports associated with wewe.global domains. We’re investigating each report we receive, so please keep them coming.


It's been over a week since that mail (and several weeks since the spam was first reported to you), and the spam is 
still flowing.


What are you actually doing? Investigating single reports doesn't seem to help.

 * Have you analyzed all information related to the customers from whose 
machines these spams originate?
 * Registration names & e-mails, IP addresses of accesses to your web pages, 
payment information, etc.?
 * Do you really KNOW who your customers are before you grant them outgoing 
SMTP permission?

I'm still reporting each individual IP address (at most once per 24h so your abuse desk has time to read and investigate 
every single one) and I'm still getting requests back from some abuse workers to enter abuse reports via your web form 
which I decline politely, as it absolutely does not scale to use manual web forms to report automated spam floods.


If there was any reason to expect that an automated report via some API or so would lead to a timely disconnection of 
the spam-emitting VMs I would even invest a day modifying my reporting tools to use such API. But until now, there's 
nothing but assertions of "we're investigating". That is not enough!


Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Hans-Martin Mosner via mailop]

23. Februar 2022 14:10, "Sinclair, John via mailop" mailto:mailop@mailop.org?to=%22Sinclair,%20John%20via%20mailop%22%20)>
 schrieb:
Staring at the end of the Google Suite (aka Workspace) free lunch days. 
Trying to find a free solution that will still let me use a custom domain, not 
coming up with much, so thinking about going back to rolling and hosting my own 
email server for the family. What’s the best of breed these days for 
small/micro servers hosting five-ish email accounts, probably no more than 1TB 
total – looking for as-close-to-gmail-as-possible webmail, IMAP access for 
mobile, might even throw a nextcloud/freenas type of environment on for file 
storage/sharing. Not interested in hosting my own IMAP and using a free gmail 
account as a client – looking to only have the family have to keep one username 
(on the custom domain) and basically cut out Google entirely. I have the 
hardware and the bandwidth, it’s more of a what OS/email/webmail is best of 
breed these days, not only for robustness/security, but also something that can 
have at least some attempt at blocking most of the spam…

Thoughts?

I'm a UNIX/Linux guy, so naturally I'd favor a solution built on Linux or 
FreeBSD (although my personal experience is restricted to Linux these days).

For a full featured modern package with reasonable spam resistance I can vouch 
for Mailu (https://mailu.io) which requires Docker as a basis. Under the hood, 
this is postfix as MTA, dovecot for IMAP/POP3, rspamd as anti-spam solution (I 
think the SPF/DKIM/DMARC stuff is located there, too), Roundcube or RainLoop as 
webmail (both pretty usable, probably not as feature-rich as GMail), PostgreSQL 
for account persistence, and REDIS as memory cache mostly for the rspamd 
engine. Supports Letsencrypt out of the box, of course.
It does take some effort to set up the basics right (Docker and configuration) 
but then runs very reliably and is a breeze to manage.
Sadly, it does not integrate Mailman, so I had to do that manually, which is 
kind of a pain.

For a significantly smaller solution, you would need to install the parts from 
scratch (all are available in the standard package repositories AFAIK) and wire 
them together manually. User management is quite a bit more tedious then, but 
you may be more flexible.

Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop