from:"Stefan Bauer via mailop"

Re: [mailop] any postmaster or contact to knauf.com around? delivery issues

2024-04-30 Thread Stefan Bauer via mailop

Wow. Indeed. Thank you. The ip is 217.160.0.245 and yes, the complete ASN
is blocked.

Am Di., 30. Apr. 2024 um 13:50 Uhr schrieb Marco Moock :
>
> Am 30.04.2024 um 12:28:50 Uhr schrieb Stefan Bauer via mailop:
>
> > Sender-Domain IP is in UCEPROTECTL3, however none of his sending
> > systems. Bad thing is, that this is one of the cluster-ips from
> > IONOS/1&1, so many of our senders, having their domains hosted at
> > IONOS/1&1 are currently affected even though non of the mail-sending
> > systems appears in any blacklist.
>
> UCEprotect level 3 means the entire ASN. If that is listed, every IP
> address is being affected, unless registered at whitelisted.org.
>
> Please check that at http://www.uceprotect.net/de/rblcheck.php
>
> It is a bad behavior if they drop mails instead of rejecting them with
> a proper message.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] any postmaster or contact to knauf.com around? delivery issues

2024-04-30 Thread Stefan Bauer via mailop

Hi,

knauf.com is accepting much of our delivered mails, however afterwards
probably drop them as recipients reported via phone, that none of the mails
arrive in their mailboxes.

Mail to postmaster@ and a known contact at knauf.com did not yield any
response so far.

Apr 23 10:12:54 mx3 postfix/smtp[654640]: 724585DCFA: to=<
postmas...@knauf.com>, relay=mailstream-eu1.mxrecord.io[172.65.245.214]:25,
delay=51, delays=0.36/50/0.18/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok:
queued as 4VNvxf1pTvz2CcMQ)

Sender-Domain IP is in UCEPROTECTL3, however none of his sending systems.
Bad thing is, that this is one of the cluster-ips from IONOS/1&1, so many
of our senders, having their domains hosted at IONOS/1&1 are currently
affected even though non of the mail-sending systems appears in any
blacklist.

Any help is greatly appreciated.

Thank you.

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

[mailop] Communication / Feature Requests & Bugfixing in OpenXchange

2023-10-25 Thread Stefan Bauer via mailop

Dear Mailops,

anyone in here using OpenXchange? We are still evaluating OX but having a
hard time to get real informations or feedback at all.

a, I made some feature-recommendations ¹²³ in the forum, not a single reply
:/
Even a reply like, we do not accept requests this way would help.

b, There are public announcements regarding securty/patches and CVE-numbers
in release notes
(
https://software.open-xchange.com/products/appsuite/doc/Release_Notes_for_Patch_Release_6251_7.10.6_2023-09-25.pdf
)

but no public information regarding the bugs or bug-numbers
(CVE-2023-29051, MWB-2315).
Jira-System ist not public: https://jira.open-xchange.com/browse/MWB-2315

So it's hard to rate the impact for own installation.

Would be nice to have some more communication especially if a feature
requests will be considered.

Thank you.

¹
https://forum.open-xchange.com/forum/open-xchange-community-edition/open-xchange-discussion/95460-feature-request-e-mail-send-current-email-as-new-mail
²
https://forum.open-xchange.com/forum/open-xchange-community-edition/open-xchange-discussion/95291-support-for-delivery-receipt-confirming-howto-request
³
https://forum.open-xchange.com/forum/open-xchange-community-edition/open-xchange-discussion/95459-feature-request-calendar-jump-to-current-day
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] How open is openxchange? + can not process ics-files in inbox with OX

2023-06-21 Thread Stefan Bauer via mailop

Hi folks,

we are still evaluating OpenXchange but having a hard time, finding an
active community around this software.

The public bugzilla tracker was shut down¹, the public forum is more or
less inactive and the official mailing lists are announce only² lists.

Are there any other places to discuss technical issues/topics with other
admins?

For example, we can not display/process ICS-files in users inboxes³.

Thank you.

Stefan


¹
https://forum.open-xchange.com/forum/open-xchange-app-suite/open-xchange-app-suite-announcements/93711-bugzilla-bug-reporting-changes

² https://lists.open-xchange.com/mailman/listinfo

³
https://forum.open-xchange.com/forum/open-xchange-community-edition/open-xchange-installation/95330-appsuite-can-t-parse-ics-files-in-mails-message-folder-inbox-has-been-closed
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [OFFLIST] Re: Open-Xchange - user source/management - best practice?

2023-05-03 Thread Stefan Bauer via mailop

Thanks Wolfgang for your insights.
@Michael - sure:

I'm talking about small setups (5-50users) per site with a so planned -
local OX installation. All sites have an existing ADS and right now are
using MX Exchange.
I simply dont like to have to maintain the users in 2 places.

Thank you.

Stefan

Am Do., 4. Mai 2023 um 02:43 Uhr schrieb Michael Peddemors <
mich...@linuxmagic.com>:

>
> Do you have a use case you can share, eg type of customers, and number
> of accounts?  Might have some recommendations.
>
>
>
> On 2023-05-03 10:24, Stefan Bauer via mailop wrote:
> > Dear Mailops,
> >
> > I'm evaluating open-Xchange and hoping to reach some of you that also
> > use it and can find some answers as the public open-xchange forum is
> > rather dead and no mailinglist exists.
> >
> > How do you maintain the OX-own user-database and keep them in sync with
> > other directories(LDAP,ADS) regarding new/deleted/modified users?
> >
> > Currently we have all user information in LDAP but OX seems to be only
> > able to use LDAP as authentication source and requiers to have all users
> > at least in it's on DB. That makes it rather complicated as I need to
> > have a kind of sync in place.
> >
> > A previously available tool called oxldapsync is deprecated¹.
> >
> > Any help is greatly appreciated.
> >
> > Thank you.
> >
> > Stefan
> >
> > ¹ https://www.oxpedia.org/wiki/index.php?title=OXLDAPSync_Guide
> > <https://www.oxpedia.org/wiki/index.php?title=OXLDAPSync_Guide>
> >
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
>
>
> --
> "Catch the Magic of Linux..."
> 
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> A Wizard IT Company - For More Info http://www.wizard.ca
> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> 
> 604-682-0300 Beautiful British Columbia, Canada
>
> This email and any electronic data contained are confidential and intended
> solely for the use of the individual or entity to which they are addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and are not intended to represent those of the company.
>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Open-Xchange - user source/management - best practice?

2023-05-03 Thread Stefan Bauer via mailop

Dear Mailops,

I'm evaluating open-Xchange and hoping to reach some of you that also use
it and can find some answers as the public open-xchange forum is rather
dead and no mailinglist exists.

How do you maintain the OX-own user-database and keep them in sync with
other directories(LDAP,ADS) regarding new/deleted/modified users?

Currently we have all user information in LDAP but OX seems to be only able
to use LDAP as authentication source and requiers to have all users at
least in it's on DB. That makes it rather complicated as I need to have a
kind of sync in place.

A previously available tool called oxldapsync is deprecated¹.

Any help is greatly appreciated.

Thank you.

Stefan

¹ https://www.oxpedia.org/wiki/index.php?title=OXLDAPSync_Guide
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] double-singing with 2 independant DKIM-signatures for same domain

2022-08-26 Thread Stefan Bauer via mailop

Thank you. We will adjust our internal policy.

Am Fr., 26. Aug. 2022 um 12:43 Uhr schrieb Laura Atkins via mailop <
mailop@mailop.org>:

> To answer your first question: a lot of mail is double signed. Signing
> with 2 identical d= but different s= is unusual, but I don’t think it’s
> prohibited anywhere. I also don’t think the RFC addresses anything about
> mail disposition in case of failures. It could be that the 2 identical d=
> one passing and one failing is causing a spam filter somewhere to act up.
>
> Given the problem is inside your infrastructure, the easiest fix is
> probably on your end. I’ve not had good experiences getting 3rd parties to
> modify these kinds of decisions (even when they’re clearly buggy and acting
> in ways that are probably unintended) and they often have what they
> perceive as valid reasons for making them.
>
> laura
>
>
>
> On 26 Aug 2022, at 11:02, Stefan Bauer via mailop 
> wrote:
>
> The other party is putting our mails in junk/spam folder. Mail is not
> rejected and reports, that the reason is invalid dkim signatur.
>
> Am Fr., 26. Aug. 2022 um 11:56 Uhr schrieb Laura Atkins via mailop <
> mailop@mailop.org>:
>
>> When you say “fail” do you mean the mail is being rejected? Or just that
>> one signature is failing to verify with DKIM?
>>
>> laura
>>
>>
>>
>> On 26 Aug 2022, at 10:32, Stefan Bauer via mailop 
>> wrote:
>>
>> Hi folks,
>>
>> are 2 DKIM-signatures in a mail with different s= but for same d= a
>> problem in general?
>>
>> According to RFC 6376 4.2 i would say no, the receiver should check both
>> signatures and not perm fail on the first, however we see some trouble with
>> some recipients:
>>
>> Log from receivers:
>>
>> 2022-08-22T06:35:38+02:00 S2VG300MR01 MTA[10124]: 2022-08-22 06:35:38
>> [10124] 1oPzA2-0002dI-Qd acl_check_dkim: fail domain.tld domain.tld
>> 2022-08-22T06:35:38+02:00 S2VG300MR01 MTA[10124]: 2022-08-22 06:35:38
>> [10124] 1oPzA2-0002dI-Qd DKIM: d=domain.tld s=18022801 c=relaxed/relaxed
>> a=rsa-sha256 b=2048 t=1661142932 [verification failed - signature did not
>> verify (headers probably modified in transit)]
>>
>> We have 2 mail worlds, that send mail for same domain. Sometimes, a mail
>> from world 1, enters world 2, gets processed and send to third party. This
>> way, the mail has 2 signatures.
>>
>> Thank you.
>>
>> Stefan
>>
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://list.mailop.org/listinfo/mailop
>>
>>
>> --
>> The Delivery Experts
>>
>> Laura Atkins
>> Word to the Wise
>> la...@wordtothewise.com
>>
>> Email Delivery Blog: http://wordtothewise.com/blog
>>
>>
>>
>>
>>
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://list.mailop.org/listinfo/mailop
>>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
>
> --
> The Delivery Experts
>
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com
>
> Email Delivery Blog: http://wordtothewise.com/blog
>
>
>
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] double-singing with 2 independant DKIM-signatures for same domain

2022-08-26 Thread Stefan Bauer via mailop

The other party is putting our mails in junk/spam folder. Mail is not
rejected and reports, that the reason is invalid dkim signatur.

Am Fr., 26. Aug. 2022 um 11:56 Uhr schrieb Laura Atkins via mailop <
mailop@mailop.org>:

> When you say “fail” do you mean the mail is being rejected? Or just that
> one signature is failing to verify with DKIM?
>
> laura
>
>
>
> On 26 Aug 2022, at 10:32, Stefan Bauer via mailop 
> wrote:
>
> Hi folks,
>
> are 2 DKIM-signatures in a mail with different s= but for same d= a
> problem in general?
>
> According to RFC 6376 4.2 i would say no, the receiver should check both
> signatures and not perm fail on the first, however we see some trouble with
> some recipients:
>
> Log from receivers:
>
> 2022-08-22T06:35:38+02:00 S2VG300MR01 MTA[10124]: 2022-08-22 06:35:38
> [10124] 1oPzA2-0002dI-Qd acl_check_dkim: fail domain.tld domain.tld
> 2022-08-22T06:35:38+02:00 S2VG300MR01 MTA[10124]: 2022-08-22 06:35:38
> [10124] 1oPzA2-0002dI-Qd DKIM: d=domain.tld s=18022801 c=relaxed/relaxed
> a=rsa-sha256 b=2048 t=1661142932 [verification failed - signature did not
> verify (headers probably modified in transit)]
>
> We have 2 mail worlds, that send mail for same domain. Sometimes, a mail
> from world 1, enters world 2, gets processed and send to third party. This
> way, the mail has 2 signatures.
>
> Thank you.
>
> Stefan
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
>
> --
> The Delivery Experts
>
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com
>
> Email Delivery Blog: http://wordtothewise.com/blog
>
>
>
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] double-singing with 2 independant DKIM-signatures for same domain

2022-08-26 Thread Stefan Bauer via mailop

Hi folks,

are 2 DKIM-signatures in a mail with different s= but for same d= a problem
in general?

According to RFC 6376 4.2 i would say no, the receiver should check both
signatures and not perm fail on the first, however we see some trouble with
some recipients:

Log from receivers:

2022-08-22T06:35:38+02:00 S2VG300MR01 MTA[10124]: 2022-08-22 06:35:38
[10124] 1oPzA2-0002dI-Qd acl_check_dkim: fail domain.tld domain.tld
2022-08-22T06:35:38+02:00 S2VG300MR01 MTA[10124]: 2022-08-22 06:35:38
[10124] 1oPzA2-0002dI-Qd DKIM: d=domain.tld s=18022801 c=relaxed/relaxed
a=rsa-sha256 b=2048 t=1661142932 [verification failed - signature did not
verify (headers probably modified in transit)]

We have 2 mail worlds, that send mail for same domain. Sometimes, a mail
from world 1, enters world 2, gets processed and send to third party. This
way, the mail has 2 signatures.

Thank you.

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

Re: [mailop] relay=mx.rheinmetall.ca[207.61.105.111]:25 - 5.7.1 IP address refused. To find the reputation of this IP address, visit www.trustedsource.org

2021-11-06 Thread Stefan Bauer via mailop

Thanks. Will try to reach out directly to their postmaster address.

Am Sa., 6. Nov. 2021 um 23:04 Uhr schrieb :

> You asked Friday and didn't get a response. I assume either because most
> list members are checked out for the weekend or truly no one is familiar
> with this. It could easily be the latter, I am quite unfamiliar with the
> message myself. I'm going to suggest that this is an on premises
> filtering system at the recipient's end and that the only way to resolve
> it is to have your contact inside the company reach out to their IT
> department.
>
> On 2021-11-06 16:23, Stefan Bauer via mailop wrote:
> > Hi,
> >
> > can anyone help to understand the error message? My sending ip is not
> > in any list i'm aware of, listed.
> >
> > The webpage trustedsource.org [1] does also not allow to check
> > IP-addresses.
> >
> > Anyone from McAfee or Reinmetall around?
> >
> > sending ip is: 116.203.31.6 / 2a01:4f8:c0c:92be::1
> >
> > Thanks.
> >
> > Stefan
> >
> > Links:
> > --
> > [1] http://trustedsource.org
> > ___
> > 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] relay=mx.rheinmetall.ca[207.61.105.111]:25 - 5.7.1 IP address refused. To find the reputation of this IP address, visit www.trustedsource.org

2021-11-06 Thread Stefan Bauer via mailop

Hi,


can anyone help to understand the error message? My sending ip is not in
any list i'm aware of, listed.

The webpage trustedsource.org does also not allow to check IP-addresses.


Anyone from McAfee or Reinmetall around?


sending ip is: 116.203.31.6 / 2a01:4f8:c0c:92be::1


Thanks.


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

[mailop] relay=mx.rheinmetall.ca[207.61.105.111]:25 - 5.7.1 IP address refused. To find the reputation of this IP address, visit www.trustedsource.org

2021-11-05 Thread Stefan Bauer via mailop

Hi,



can anyone help to understand the error message? My sending ip is not in any 
list i'm aware of, listed.

The webpage trustedsource.org does also not allow to check IP-addresses.




Anyone from McAfee or Reinmetall around?



sending ip is: 116.203.31.6 / 2a01:4f8:c0c:92be::1



Thanks.



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

[mailop] WG: Best practices for outbound rate limiting?

2021-04-28 Thread Stefan Bauer via mailop

Hi Nami,



incoming rate limiting works fine, if your users send through a mailsever, that 
can deal with the 400-errors, your MTA generates, throttle and try again later. 
However if you have mail clients that send, a 400-error is a real error to the 
user and they probably do not even understand, whats going on and will try on 
and on.



Also outgoing rate limiting should be in place to not annoy other mailservers.



Additonally i always like to learn from users behavior. So i would not only 
limit amount of mail, i would also scan for spam/virus etc and monitor all of 
it.



Spammers do not only send many mails at once, they send also at very low rate 
but ongoing. Rate limiting would not take care of this.





Stefan Bauer.



-Ursprüngliche Nachricht-
Von: missytake via mailop 
Gesendet: Dienstag 27 April 2021 18:31
An: mailop@mailop.org
Betreff: [mailop] Best practices for outbound rate limiting?



Hi,

we have a small semi-open-registration mail server (not systemli.org, in

case you are wondering) and we would like to learn more about best
practices for rate limiting outgoing mail. We are using postfix.

We don't want to restrict our users too much, but obviously we also care

about not burdening the mail ecosystem with spam, and it's possible,
though not very likely that spammers find out how to automatically use
our registration mechanism.

The smtpd_client_message_rate_limit option seems to do the trick, and we

are thinking about setting it to 20 - is this enough to make it
unprofitable for spammers, but not annoy our users? What are your
experiences?

Thanks,
Nami

___
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] www.trustedsource.org - how to check/unblock/contact?

2021-03-24 Thread Stefan Bauer via mailop

Hi,



we fail to deliver mail to



status=deferred (host srvmail.diversa-gmbh.com[62.91.109.87] refused to talk to 
me: 550 5.5.0 550 5.7.1 IP address refused. To find the reputation of this IP 
address, visit www.trustedsource.org.)



Webpage only alows to checkfor URLs. Message indicates a block of our IPs.



sending ip is

Address: 116.203.31.6
Address: 2a01:4f8:c0c:92be::1



Anyone knows more?



Thank you.



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

Re: [mailop] Delivery issues with gmx recipients

2021-03-12 Thread Stefan Bauer via mailop

Might be related with the recent DMARC changes announced by 1&1.









-



Just a short info to whom it might interest:

Very soon, we will go live with DMARC check on incoming mails for all mailboxes 
operated by WEB.DE, GMX & mail.com.
That covers several hundred of recipient domains [1] and roughly 50% of the 
German email users.

For now we will handle reject and quarantine policies equally as quarantine. 
GDPR compliant, aggregated DMARC reports will follow as well (without giving an 
ETA). 

Best regards
Arne Allisat



-



-Ursprüngliche Nachricht-
Von: tobisworld--- via mailop 
Gesendet: Donnerstag 11 März 2021 22:07
An: mailop@mailop.org
Betreff: [mailop] Delivery issues with gmx recipients



Hello


We're an email provider in Switzerland and since about 16:45 our
Outbound Service for our customers has massive delivery issues with mail

to gmx recipients. We're getting

> 421-gmx.net (mxgmx115) Nemesis ESMTP Service not available 421-Service 
> unavailable 421-Reject due to policy restrictions.

Could someone of GMX contact me offlist as I cannot provide details via
a public-mailinglist


Thanks and have a good one


tobi

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

[mailop] How does one operate mailman3 with correct From & Sender Address - like this list?

2021-02-04 Thread Stefan Bauer via mailop

Hi,



I'm planning to operate a mailman list and want to make sure, that Reply-To is 
untouched (seems to be default on MM3) and From is list-address and Sender is 
list-bounce address.



However i do not see a simply way in MM3 to specify that. The settings - per 
list - only offer



Anonymous list (Yes/No)

Hide the sender of a message, replacing it with the list address (Removes From, 
Sender and Reply-To fields



but thats not what i want. Would be great if anyone on this list that operates 
a MM3 list could please share some infos.



Many thanks.



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

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

2021-01-06 Thread Stefan Bauer via mailop

Just my 5 cents:



As a small mail operator (10K mails/day) we disabled ___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] microsoft rejects mail to live.de but accepts for hosted exchange - 116.203.31.6 - part of their network is on our block list (S3140)

2020-12-31 Thread Stefan Bauer via mailop

Hi,



anyone aware of a bigger block at the moment?



We're having a single IP 116.203.31.6 but microsofts reject-message looks like 
there is a bigger block ongoing. Network is from hetzner (DE).



737675DD1E: to=, 
relay=eur.olc.protection.outlook.com[104.47.14.33]:25, delay=3.4, 
delays=0.01/3/0.37/0.02, dsn=5.7.1, status=bounced (host 
eur.olc.protection.outlook.com[104.47.14.33] said: 550 5.7.1 Unfortunately, 
messages from [116.203.31.6] weren't sent. Please contact your Internet service 
provider since part of their network is on our block list (S3140). You can also 
refer your provider tohttp://mail.live.com/mail/troubleshooting.aspx#errors. 
 
[VI1EUR04FT034.eop-eur04.prod.protection.outlook.com] (in reply to MAIL FROM 
command))



Mails to domains, hosted at exchange online however are accepted:



relay=mbccgroup-com01b.mail.protection.outlook.com[104.47.5.36]:25, delay=81, 
delays=75/3/0.65/2.4, dsn=2.6.0, status=sent (250 2.6.0 
 [InternalId=39771397163184, 
Hostname=VI1PR08MB4336.eurprd08.prod.outlook.com] 16779310 bytes in 1.202, 
13631.165 KB/sec Queued mail for delivery)



Dec 31 16:02:50 mx3 
relay=customer2-eu.mail.protection.outlook.com[104.47.1.36]:25, delay=5.1, 
delays=0.03/3/0.33/1.7, dsn=2.6.0, status=sent (250 2.6.0 
<20201231150245.CB90B5DD1C@mail> [InternalId=15504831938757, 
Hostname=AM6PR07MB5303.eurprd07.prod.outlook.com] 8446 bytes in 0.115, 71.226 
KB/sec Queued mail for delivery)



SDNS still shows IP as blocked.



Any ideas?



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

[mailop] observation - *OLC.PROTECTION.outlook.com does not offer STARTTLS when IP is blocked

2020-12-31 Thread Stefan Bauer via mailop

Hi,



one of our pub-ip seems to be blocked by MS. Side effect is, that 
olc.protection... is not offering starttls in this case.

Anyone else seen that?



# telnet eur.olc.protection.outlook.com. 25
Trying 104.47.18.161...
Connected to eur.olc.protection.outlook.com.
Escape character is '^]'.
220 AM7EUR06FT011.mail.protection.outlook.com Microsoft ESMTP MAIL Service 
ready at Thu, 31 Dec 2020 09:21:40 +
ehlo mydomain.com
250-AM7EUR06FT011.mail.protection.outlook.com Hello [116.203.31.6]
250-SIZE 49283072
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 SMTPUTF8



SNDS reports:



116.203.31.6,116.203.31.6,Yes,Blocked due to user complaints or other evidence 
of spamming



However the real data is only available the next day on 
https://sendersupport.olc.protection.outlook.com/snds/data.aspx

. How does one deal with that situation?



We monitor our outgoing mails but did not catch/see any malicious/spammy mail 
recently from this node/host.



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

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

2020-12-18 Thread Stefan Bauer via mailop

-Ursprüngliche Nachricht-
Von: Grant Taylor via mailop 

> At least in EU/Germany, that is against the law (GDPR/DSGVO)

Would you please elaborate? Either on list or direct, your choice.



If i setup for customer-domains MX records in a way, that a third-party is 
handling/processing meta-data or even mailcontent, i have to inform my 
customers about that and ask permission. If third-party is outside EU, there is 
not even a legal basis anymore since a few weeks, that would allow me to do so 
at all (see privacy shield got canceled). In all cases, I will be held 
responsible for my customers data unless third-party is signing contracts with 
me to accept  EU privacy laws. EU has severe penalty for companies, breaking 
the GDPR/DSGVO law.



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

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

2020-12-18 Thread Stefan Bauer via mailop

Grant,



Project Tar looks like a privacy nightmare to me.

Routing my mails to a stranger in case senders just don't honor the standard 
and dont talk to my primary MX.

They promise to reject, but who knows. At least in EU/Germany, that is against 
the law (GDPR/DSGVO)



Stefan



Von: Grant Taylor via mailop 

I prefer a slightly different approach.

1) Point the primary MX at a server with nothing listening. It will
send TCP Resets. -- I know this as "No Listing", a varient of "Grey
Listing". -- I have yet to see any negative side effects wit this.
2) Point the secondary MX at your main mail server. -- Business as usual.
3) Optionally - Point the tertiary at your backup mail server.
4) Point the last MX at something like Project Tar.


[1] Project Tar - https://wiki.junkemailfilter.com/index.php/Project_Tar

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

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

2020-12-18 Thread Stefan Bauer via mailop

We use low priority MX records on newly deployed hosts to be able to monitor 
the behaviour of these hosts without getting the full load.

If all looks sane, we bump the priority after a few hours/days.



Stefan



-Ursprüngliche Nachricht-
Von: John Levine via mailop 
Gesendet: Donnerstag 17 Dezember 2020 22:29
An: mailop@mailop.org
Betreff: [mailop] What's the point of secondary MX servers?



As we all know, MX records have a priority number, and mail senders
are supposed to try the highest priority/lowest number servers first,
then fall back to the lower priority.

I understand why secondary MX made sense in the 1980s, when the net
was flakier, there was a lot of dialup, and there were hosts that only
connected for a few hours or even a few minutes a day.

But now, in 2020, is there a point to secondary servers? Mail servers
are online all the time, and if they fail for a few minutes or hours,
the client servers will queue and retry when they come back.

Secondary servers are a famous source of spam leaks, since they
generally don't know the set of valid mailboxes and often don't keep
their filtering in sync?  What purpose do they serve now?

R's,
John

PS: I understand the point of multiple MX with the same priority for
load balancing.  The question is what's the point of a high priorty
server that's always up, and a lower priority server that's, I dunno,
probably always up, too.



___
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] Sophos appliance reject mails from specific domains with Administrative prohibition, confirmed spam in logs

2020-08-20 Thread Stefan Bauer via mailop

Thank you. Thats what i expected.



Unfortunately sophos requires one be a customer as it seems. Sophos answer:



"Please ask recipient to raise a ticket with us so we can submit emails to lab 
team.".



Stefan





-Ursprüngliche Nachricht-
Von: Olivier Depuydt via mailop 
Gesendet: Donnerstag 20 August 2020 11:13
An: Stefan Bauer 
CC: mailop 
Betreff: Re: [mailop] Sophos appliance reject mails from specific domains with 
Administrative prohibition, confirmed spam in logs

Hello.

You need to contact Sophos support (through) their website.
They are using an internal list on their equipment in addition to the regular 
public blacklists.


Best regards,

Olivier

Le jeu. 20 août 2020 à 10:58, Stefan Bauer via mailop  a 
écrit :
Hi,



since days, we try to find out why one of our customer domain is blocked, when 
sending mails to remote sites, where Sophos UTM-appliance (e.g. UTM-430) are in 
place.



All we see is at smtp level:



mailto:john@famo24.de> >: host 
mail3.famo24.de[80.155.146.58] said: 550
    Administrative prohibition (in reply to end of DATA command)



Recipients (admins) confirm, that according to local FW logs, they see 
'confirmed spam'.



All of our sending IPs are in no blacklist nor have been over the last years.



I checked all the known blacklists. Even cyrens own site. All is green and good.



One of our sending IPs is 116.203.31.6



Anyone with an idea?



Thank you.



Stefan

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


--
Olivier Depuydt

Site Reliability Engineer



Web  |  Blog <http://cheetahdigital.com/blog>   |  Linkedin  |  Twitter  |  
Facebook
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Sophos appliance reject mails from specific domains with Administrative prohibition, confirmed spam in logs

2020-08-20 Thread Stefan Bauer via mailop

Hi,



since days, we try to find out why one of our customer domain is blocked, when 
sending mails to remote sites, where Sophos UTM-appliance (e.g. UTM-430) are in 
place.



All we see is at smtp level:



: host mail3.famo24.de[80.155.146.58] said: 550
    Administrative prohibition (in reply to end of DATA command)



Recipients (admins) confirm, that according to local FW logs, they see 
'confirmed spam'.



All of our sending IPs are in no blacklist nor have been over the last years.



I checked all the known blacklists. Even cyrens own site. All is green and good.



One of our sending IPs is 116.203.31.6



Anyone with an idea?



Thank you.



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

[mailop] microsofts SNDS unavailable - anyone else?

2020-07-23 Thread Stefan Bauer via mailop

https://postmaster.live.com/snds/



throws:




Server Error in '/SNDS' Application.


Runtime Error

Description: An exception occurred while processing your request. Additionally, 
another exception occurred while executing the custom error page for the first 
exception. The request has been terminated.




Anyone else?



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

Re: [mailop] Outbound from M365 to relay off our SMTP with SMTPAUTH

2020-07-21 Thread Stefan Bauer via mailop

Hi,



my last info is, that office365 does not support authentication with external 
connectors. However you can authenticate O365 with your smtp relay.




I run some mixed authentication. We check the source ip's¹ from microsofts 
range, check the O365 client cert and check the mail-from addresses.



https://endpoints.office.com/endpoints/worldwide?clientrequestid=b10c5ed1-bad1-445f-b386-b919946339a7



Make sure, you monitor microsofts list of pub-ips so you keep up with new 
ranges.



Stefan



-Ursprüngliche Nachricht-
Von: Kevin A. McGrail via mailop 
Gesendet: Samstag 18 Juli 2020 21:19
An: mailop 
Betreff: [mailop] Outbound from M365 to relay off our SMTP with SMTPAUTH


Hi All,

I've got a long outstanding Anyone out there know what I'm missing in trying to 
have M365 relay all outgoing mail through our on-premise SMTP servers?

I've opened support tickets but they went to evolveip.net with no response.

Here's what I used to do:

  - Admin | Exchange -> Mail Flow | Connectors -> create new connector
  - from 365 to partner
  - use when email sent to these domains
  - list domain names
  - route email through smart hosts
  - set to smtp.pccc.com

Has that setting been moved?  Does it not work with SMTP AUTH anymore?

Happy to share more info.

Regards,

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

Re: [mailop] host mx.tiscali.co.uk[62.24.139.42] said: 453 4.1.1 wJGljsu8zj2dp Recipient Lookup Failed (TT513)

2020-07-18 Thread Stefan Bauer via mailop

No. Recipient is valid. Unknown recipients should be a perament error.



I also tried postmaster@ and get same TT513 error.



Also from different sending-systems.



Can anyone successfully deliver mails to @tiscali.co.uk at the moment?




Stefan





-Ursprüngliche Nachricht-
Von: Colin Stanners (lists) via mailop 
Gesendet: Freitag 17 Juli 2020 19:33
An: mailop@mailop.org
Betreff: Re: [mailop] host mx.tiscali.co.uk[62.24.139.42] said: 453 4.1.1 
wJGljsu8zj2dp Recipient Lookup Failed (TT513)

Never seen it but isn’t that a case of recipient mailbox incorrect/no longer 
active?

 
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Stefan Bauer via 
mailop
Sent: Friday, July 17, 2020 1:08 AM
To: mailop 
Subject: [mailop] host mx.tiscali.co.uk[62.24.139.42] said: 453 4.1.1 
wJGljsu8zj2dp Recipient Lookup Failed (TT513)

 
Hi,

 
smtp Jul 17 07:50:52 mx2 postfix/smtp[31049]: 51CBC5EBE3: 
to=, relay=mx.tiscali.co.uk[62.24.139.42]:25, 
delay=9509, delays=9505/3/0.35/1.2, dsn=4.1.1, status=deferred (host 
mx.tiscali.co.uk[62.24.139.42] said: 453 4.1.1 wJGljsu8zj2dp Recipient Lookup 
Failed (TT513) (in reply to RCPT TO command))

 
According to the reply tiscali gives, they can not lookup the recipient. Anyone 
seen TT513?

 
Thanks.

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

[mailop] host mx.tiscali.co.uk[62.24.139.42] said: 453 4.1.1 wJGljsu8zj2dp Recipient Lookup Failed (TT513)

2020-07-17 Thread Stefan Bauer via mailop

Hi,



smtp Jul 17 07:50:52 mx2 postfix/smtp[31049]: 51CBC5EBE3: 
to=, relay=mx.tiscali.co.uk[62.24.139.42]:25, 
delay=9509, delays=9505/3/0.35/1.2, dsn=4.1.1, status=deferred (host 
mx.tiscali.co.uk[62.24.139.42] said: 453 4.1.1 wJGljsu8zj2dp Recipient Lookup 
Failed (TT513) (in reply to RCPT TO command))



According to the reply tiscali gives, they can not lookup the recipient. Anyone 
seen TT513?



Thanks.



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

Re: [mailop] Post-processing Journal-Mails coming from O365, forwardedMail

2020-07-09 Thread Stefan Bauer via mailop

I did in my first mail.



https://nopaste.linux-dev.org/?1321451



Stefan





-Ursprüngliche Nachricht-
Von: Luis E. Muñoz via mailop 
Gesendet: Freitag 10 Juli 2020 02:49
An: mailop 
Betreff: Re: [mailop] Post-processing Journal-Mails coming from O365, 
forwardedMail





On 8 Jul 2020, at 22:36, Stefan Bauer via mailop wrote:

> there is a feature in O365 that forwards mails (in/out/both..) to an 
> archive-mailbox for long-term archiving.
>
> We grab this mails via pop. However our available mail-readers 
> (Thunderbird, Kopano) show the original mail as attachment.
>
> This is the „envelope wrapper“ format. It contains the _final_ 
> recipient(s) of the email (eg after aliasing, distribution list 
> expansion etc), and contains the original email - headers and body - 
> unchanged. The advantage is that the archiving process does not need 
> to do any of the logic Exchange does (no further LDAP lookups etc).

Can someone donate a test message through pastebin? I would like to take 
a look at one directly.

Best regards

-lem

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

Re: [mailop] Post-processing Journal-Mails coming from O365, forwardedMail

2020-07-08 Thread Stefan Bauer via mailop

Von: Matthias Leisi via mailop 
Gesendet: Donnerstag 9 Juli 2020 00:27
An: mailop 
Betreff: Re: [mailop] Post-processing Journal-Mails coming from O365, 
forwardedMail

there is a feature in O365 that forwards mails (in/out/both..) to an 
archive-mailbox for long-term archiving.

We grab this mails via pop. However our available mail-readers (Thunderbird, 
Kopano) show the original mail as attachment.

This is the „envelope wrapper“ format. It contains the _final_ recipient(s) of 
the email (eg after aliasing, distribution list expansion etc), and contains 
the original email - headers and body - unchanged. The advantage is that the 
archiving process does not need to do any of the logic Exchange does (no 
further LDAP lookups etc).


I understand. Are there any command line unix tools, to split off, the original 
mail?



This makes it very hard for handling/searching/reading of these mails.

Are there any tools available to just have the attachment that is the real and 
original mail?

These messages are typically read by an email archiving solution (mailpiler, 
mailarchiva, cryoserver, mailstore etc) for long-term storage, full-text search 
and other features.


We already purchased an archiving software but unfortunately can not handle 
"envelope wrapper" format accordingly.



Thank you.



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

Re: [mailop] Post-processing Journal-Mails coming from O365, forwardedMail

2020-07-07 Thread Stefan Bauer via mailop

Hi Faisal,



we are using the Journal Rules. Thats what i tried to describe with " there is 
a feature in O365 that forwards mails (in/out/both..) to an archive-mailbox for 
long-term archiving."



Stefan



-Ursprüngliche Nachricht-
Von: Faisal Misle 
Gesendet: Dienstag 7 Juli 2020 15:55
An: Stefan Bauer ; mailop 
Betreff: Re: [mailop] Post-processing Journal-Mails coming from O365, 
forwardedMail

 Have you tried journal rules?

https://docs.microsoft.com/en-us/exchange/security-and-compliance/journaling/configure-journaling

Best,
Faisal Misle
MCSA: Office 365

PGP Key: C8FD029B


On Tue, Jul 7, 2020 at 6:20 AM, Stefan Bauer via mailop mailto:mailop@mailop.org> > wrote:

Hi,


there is a feature in O365 that forwards mails (in/out/both..) to an 
archive-mailbox for long-term archiving.


We grab this mails via pop. However our available mail-readers (Thunderbird, 
Kopano) show the original mail as attachment.


This makes it very hard for handling/searching/reading of these mails.


Are there any tools available to just have the attachment that is the real and 
original mail?



example-mail can be found here:



https://nopaste.linux-dev.org/?1321451



I tried ripmime, but that removes relevant header-parts.



Thank you.



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

[mailop] Post-processing Journal-Mails coming from O365, forwardedMail

2020-07-07 Thread Stefan Bauer via mailop

Hi,


there is a feature in O365 that forwards mails (in/out/both..) to an 
archive-mailbox for long-term archiving.


We grab this mails via pop. However our available mail-readers (Thunderbird, 
Kopano) show the original mail as attachment.


This makes it very hard for handling/searching/reading of these mails.


Are there any tools available to just have the attachment that is the real and 
original mail?



example-mail can be found here:



https://nopaste.linux-dev.org/?1321451



I tried ripmime, but that removes relevant header-parts.



Thank you.



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

Re: [mailop] A1/aon.at contact

2020-07-07 Thread Stefan Bauer via mailop

A1 is busy fixing there network¹.



https://www.zdnet.com/article/hackers-breached-a1-telekom-austrias-largest-isp/



SCNR.



Stefan

-Ursprüngliche Nachricht-
Von: Sabine Rogg via mailop 
Gesendet: Dienstag 7 Juli 2020 12:25
An: mailop@mailop.org
Betreff: [mailop] A1/aon.at contact

Hello together,

 
Is there someone from aon.at/A1 on list?

If there is, please contact me off-list.

 
We tried to reach out to you, but the @postmaster mailboxes are full.

 
Best Regards,

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

Re: [mailop] keeping rejected mails in queue for second attempt acceptable?

2020-06-07 Thread Stefan Bauer via mailop

-Ursprüngliche Nachricht-
Von: Ralph Seichter via mailop 

* How and when would you decide that the recipient responding with 5xx
was due to the message itself or due to a blacklisted IP address?
That's not something that can be decided based on SMTP.

You are right. I can not rely on any sub return-code or error-message as others 
also stated here.

But sometimes the error messages are clear and also the intention of the 
recipients so one backs off.



* Can you unilaterally decide if it was acceptable to withhold the
non-delivery status from your customers?

Of corse not. However there could be an opt-in for senders so they give the 
delivery completely in other hands.

It's just a theoricaly question to see the pro/cons. And i now starting to see 
some of them.



* Are your customers OK with not being informed about your problems due
to blocked IP addresses, or do they feel misled regarding the quality
of your services?



Informing the customers of service disruption is important to stay transparent 
and something we do. However should it be primary happen by bouncing mails back 
that in most cases, are not clear to the sender or will be read at all? There 
are (also) other channels to bring it to customers attention.



* Why not solve the underlying issue of having your addresses blocked?




You know, as you are a mailop yourself, it happens from time to time. There is 
no silver bullet and for this rare cases, we are trying to deal with it in a 
more modern and better way.

Just some examples, that we have seen the last years:



- we change hostnames of our mailservers but other MX have outdated/old 
DNS-informations. I'm not talking about the TTL, sometimes anti-spam appliances 
cache DNS-informations for more than one week. Thats what we saw.

- other MX detect portsans from neighbor-networks and decide to block the 
parent-network (/23 in our case)

- other MX rely solely on geo-location of sending ip or have outdated 
informations as networks have changed owner



> I dont want to bother my users with bounces and have them send mails
> over and over again until problem is solved.

As a hypothetical customer of yours, I'd insist on knowing about every
failed e-mail, especially if it was due to problems on your end. If you
cannot address the issue that gets your IP addresses blocked, I would
choose a different service provider. A mistrusting individual might
interpret your "don't want to bother" as "don't want to risk losing".



Sure and by default, a regular bounce is and should always be the default 
behavior. But as stated earlier, it could be an opt-in option to have mail 
delivered without another sender interaction.

If this is a real benefit for the user, it's reasonable to think about making 
it an option.



-Ralph

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

[mailop] keeping rejected mails in queue for second attempt acceptable?

2020-06-06 Thread Stefan Bauer via mailop

Hi,



once in a while, some of our outgoing customer mails are rejected by remote 
sites with a 500 code because one of our sending IPs are temporary blacklisted. 
or due to other reasons we are not able to deliver the mail. I'm only talking 
about cases, where the mail itself, is not the reject reason.



I'm thinking about not bouncing this mails back to my users, and give them 
another try after the problem is solved with remote site.



Is this acceptable / sounds like a good idea?



I dont want to bother my users with bounces and have them send mails over and 
over again until problem is solved.



Thank you.



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

Re: [mailop] [External] dcc down / dead?

2020-05-23 Thread Stefan Bauer via mailop

looks great again! Thank you folks.



If the domain rans out again, just drop me a note and i will be more than happy 
to pay for domain & hosting as i really appreciate this service.

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

[mailop] dcc down / dead?

2020-05-23 Thread Stefan Bauer via mailop

Hi,



seems like the main DCC servers are down (dcc1-6.dcc-servers.net), also the 
website.

Archive last mails are from end 19.



Anybody knows more? Did i miss some announcement?



Cheers



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

Re: [mailop] hostedemail.com contact - IP manually blacklisted - 116.203.31.6

2020-05-18 Thread Stefan Bauer via mailop

Thank you Brian,



so far no response.

What i find strange is, that the remote site is temp-rejecting specific mail 
since days, however is using dsn=4.7.1 so we keep trying.

I'm pretty certain, trying over and over again will not boost our reputation :)



Stefan



-Ursprüngliche Nachricht-
Von: Brian Ellwood via mailop 
Gesendet: Montag 18 Mai 2020 18:00
An: Stefan Bauer 
CC: mailop 
Betreff: Re: [mailop] hostedemail.com contact - IP manually blacklisted - 
116.203.31.6



You should find assistance via h...@opensrs.com.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] hostedemail.com contact - IP manually blacklisted - 116.203.31.6

2020-05-18 Thread Stefan Bauer via mailop

Hi,

one of our sending IPs (116.203.31.6)  seems to got blacklisted by 
hostedemail.com. However this ip adress is not blacklisted. We monitor around ~ 
50 public DNS-BLs.

Feedbackloops did not generate a single report yet.

Can anyone bring some light into this?

smtp May 18 16:04:19 mx3 postfix/smtp[19286]: D292C5DEF0: to=, 
relay=mx.domain.net.cust.b.hostedemail.com[64.98.36.4]:25, delay=26310, 
delays=26303/5/1.2/0, dsn=4.7.1, status=deferred (host 
mx.domain.net.cust.b.hostedemail.com[64.98.36.4] refused to talk to me: 554 
5.7.1 Service unavailable; Client host [116.203.31.6] blocked using 
urbl.hostedemail.com; Your IP has been manually blacklisted)

thank you.

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

Re: [mailop] Ewetel postmaster wanted - your IP 116.203.31.6 seems to be dynamic - please use the smarthost of your ISP

2020-03-10 Thread Stefan Bauer via mailop

Too bad - no mails to ewe for now and no response back from them.

If anyone has a EWE/EWETEL contact, would be kind if one could reach out to
them.

thank you.

Stefan

-Ursprüngliche Nachricht-
Von: Jan-Philipp Benecke via mailop
Gesendet: Montag 9 März 2020 16:04
An: Stefan Bauer
CC: mailop
Betreff: Re: [mailop] Ewetel postmaster wanted - your IP 116.203.31.6 seems to
be dynamic - please use the smarthost of your ISP

Hey Stefan,

we hadn't any problems with them. We wrote them about our block on 14.01. and
they did respond on the same day.
When did you wrote them ? Did your wrote postmas...@ewetel.net or did you wrote
postmas...@ewe.net ?

Based on their answer, i think they have a internal list with dynamic ip ranges.

Best,
Jan-Philipp

Jan-Philipp Benecke
Deliverability Engineer

Fon: +49 4402 97390-00
E-Mail: j...@cleverreach.com <mailto:j...@cleverreach.com>

CleverReach GmbH & Co. KG
HRA 4020 Oldenburg (Oldb.)
cleverreach.de
<http://www.cleverreach.com/de/>
<http://www.cleverreach.com/de/>
Vertreten durch: CleverReach Verwaltungs GmbH, HRB 210079 Oldenburg (Oldb.)
//CRASH Building | Schafjückenweg 2 | 26180 Rastede | Germany
Geschäftsführung: Jens Klibingat, Sebastian Schwarz & Sebastian Strzelecki
Aufsichtsrat: Rolf Hilchner & Heinz-Wilhelm Bogena

Stefan Bauer via mailop schrieb am 09.03.20 um 15:03:

Hi,

it's just DNS round robin for our senders. did not had a sigle issue with that
over the previous 2 years.

Still thinking, that ewetel/ewe just uses ancient RBLs, that reports the
specific IP from a dynamic-block.

Stefan

-Ursprüngliche Nachricht-
Von: Vytis Marciulionis
Gesendet: Montag 9 März 2020 14:52
An: Stefan Bauer
CC: mailop
Betreff: Re: [mailop] Ewetel postmaster wanted - your IP 116.203.31.6 seems to
be dynamic - please use the smarthost of your ISP

Hi Stefan,

This could also happen because your PTR record of sending IP address resolves
with 3 IPs e:
IP 116.203.31.6 - PTR securetransport.cubewerk.de - IPs 178.254.23.77;
116.203.31.6; 188.68.39.254

I know that technically it is nothing bad but, I can imagine why some sensors
could return errors, especially since the 3 IP addresses are from different
ASNs:

I guess those 3 IPs are set as fallback in this situation?

On Mon, Mar 9, 2020 at 11:03 AM Stefan Bauer via mailop mailto:mailop@mailop.org> > wrote:
Never had delivery issues from hetzner-blocks so far (crossing fingers) but I'm
aware of the past.

Looks like there is at least one RBL around, that list our IP as dynamic.

https://www.rbl-dns.com/bl?ip=116.203.31.6

One just have to pay to get de-listed. What a wonderful world.

Stefan

-Ursprüngliche Nachricht-
Von: Andrew C Aitchison
Gesendet: Montag 9 März 2020 10:47
An: Stefan Bauer
CC: mailop
Betreff: Re: [mailop] Ewetel postmaster wanted - your IP 116.203.31.6 seems to
be dynamic - please use the smarthost of your ISP

On Mon, 9 Mar 2020, Stefan Bauer via mailop wrote:

> Any ewetel postmaster around? One of our IPs (subject) get flagged
> as dynamic during delivery to ewetel. However this IP is static.

I am not surprised that Ewetel has guessed wrong:
whois 116.203.31.6 -h whois.ripe.net <http://whois.ripe.net>
gives a /16 belonging to our old friends Hetzner.

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk <mailto:and...@aitchison.me.uk>

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

--
Pagarbiai,
Vytis Marčiulionis
+37064734475

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

Re: [mailop] Ewetel postmaster wanted - your IP 116.203.31.6 seems to be dynamic - please use the smarthost of your ISP

2020-03-09 Thread Stefan Bauer via mailop

Hi Jan,

i tried postmas...@ewe.net <mailto:postmas...@ewe.net> and postmas...@ewetel.de.

Will now try the third (your first suggestion) :)

thanks.

Stefan

-Ursprüngliche Nachricht-
Von: Jan-Philipp Benecke
Gesendet: Montag 9 März 2020 15:53
An: Stefan Bauer
CC: mailop
Betreff: Re: [mailop] Ewetel postmaster wanted - your IP 116.203.31.6 seems to
be dynamic - please use the smarthost of your ISP

Hey Stefan,

Based on their answer, i think they have a internal list with dynamic ip ranges.

Best,
Jan-Philipp

Jan-Philipp Benecke
Deliverability Engineer

Fon: +49 4402 97390-00
E-Mail: j...@cleverreach.com <mailto:j...@cleverreach.com>

Stefan Bauer via mailop schrieb am 09.03.20 um 15:03:

Hi,

it's just DNS round robin for our senders. did not had a sigle issue with that
over the previous 2 years.

Still thinking, that ewetel/ewe just uses ancient RBLs, that reports the
specific IP from a dynamic-block.

Stefan

Hi Stefan,

This could also happen because your PTR record of sending IP address resolves
with 3 IPs e:
IP 116.203.31.6 - PTR securetransport.cubewerk.de - IPs 178.254.23.77;
116.203.31.6; 188.68.39.254

I know that technically it is nothing bad but, I can imagine why some sensors
could return errors, especially since the 3 IP addresses are from different
ASNs:

I guess those 3 IPs are set as fallback in this situation?

On Mon, Mar 9, 2020 at 11:03 AM Stefan Bauer via mailop mailto:mailop@mailop.org> > wrote:
Never had delivery issues from hetzner-blocks so far (crossing fingers) but I'm
aware of the past.

Looks like there is at least one RBL around, that list our IP as dynamic.

https://www.rbl-dns.com/bl?ip=116.203.31.6

One just have to pay to get de-listed. What a wonderful world.

Stefan

On Mon, 9 Mar 2020, Stefan Bauer via mailop wrote:

> Any ewetel postmaster around? One of our IPs (subject) get flagged
> as dynamic during delivery to ewetel. However this IP is static.

I am not surprised that Ewetel has guessed wrong:
whois 116.203.31.6 -h whois.ripe.net <http://whois.ripe.net>
gives a /16 belonging to our old friends Hetzner.

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk <mailto:and...@aitchison.me.uk>

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

--
Pagarbiai,
Vytis Marčiulionis
+37064734475

Re: [mailop] Ewetel postmaster wanted - your IP 116.203.31.6 seems to be dynamic - please use the smarthost of your ISP

2020-03-09 Thread Stefan Bauer via mailop

Hi,

it's just DNS round robin for our senders. did not had a sigle issue with that
over the previous 2 years.

Still thinking, that ewetel/ewe just uses ancient RBLs, that reports the
specific IP from a dynamic-block.

Stefan

Hi Stefan,

This could also happen because your PTR record of sending IP address resolves
with 3 IPs e:
IP 116.203.31.6 - PTR securetransport.cubewerk.de - IPs 178.254.23.77;
116.203.31.6; 188.68.39.254

I know that technically it is nothing bad but, I can imagine why some sensors
could return errors, especially since the 3 IP addresses are from different
ASNs:

I guess those 3 IPs are set as fallback in this situation?

On Mon, Mar 9, 2020 at 11:03 AM Stefan Bauer via mailop mailto:mailop@mailop.org> > wrote:
Never had delivery issues from hetzner-blocks so far (crossing fingers) but I'm
aware of the past.

Looks like there is at least one RBL around, that list our IP as dynamic.

https://www.rbl-dns.com/bl?ip=116.203.31.6

One just have to pay to get de-listed. What a wonderful world.

Stefan

On Mon, 9 Mar 2020, Stefan Bauer via mailop wrote:

> Any ewetel postmaster around? One of our IPs (subject) get flagged
> as dynamic during delivery to ewetel. However this IP is static.

I am not surprised that Ewetel has guessed wrong:
whois 116.203.31.6 -h whois.ripe.net <http://whois.ripe.net>

gives a /16 belonging to our old friends Hetzner.

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk <mailto:and...@aitchison.me.uk>

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

--
Pagarbiai,
Vytis Marčiulionis
+37064734475
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ewetel postmaster wanted - your IP 116.203.31.6 seems to be dynamic - please use the smarthost of your ISP

2020-03-09 Thread Stefan Bauer via mailop

Never had delivery issues from hetzner-blocks so far (crossing fingers) but I'm 
aware of the past.

Looks like there is at least one RBL around, that list our IP as dynamic.

https://www.rbl-dns.com/bl?ip=116.203.31.6

One just have to pay to get de-listed. What a wonderful world.

Stefan

-Ursprüngliche Nachricht-
Von: Andrew C Aitchison 
Gesendet: Montag 9 März 2020 10:47
An: Stefan Bauer 
CC: mailop 
Betreff: Re: [mailop] Ewetel postmaster wanted - your IP 116.203.31.6 seems to 
be dynamic - please use the smarthost of your ISP

On Mon, 9 Mar 2020, Stefan Bauer via mailop wrote:

> Any ewetel postmaster around? One of our IPs (subject) get flagged
> as dynamic during delivery to ewetel. However this IP is static.

I am not surprised that Ewetel has guessed wrong:
  whois 116.203.31.6 -h whois.ripe.net
gives a /16 belonging to our old friends Hetzner.

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

[mailop] Ewetel postmaster wanted - your IP 116.203.31.6 seems to be dynamic - please use the smarthost of your ISP

2020-03-09 Thread Stefan Bauer via mailop

Any ewetel postmaster around? One of our IPs (subject) get flagged as dynamic 
during delivery to ewetel. However this IP is static.



No response to postmaster@ yet.



thank you.



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

[mailop] reputation with DKIM when d= differs from sender domain?

2019-11-14 Thread Stefan Bauer via mailop

Hi,



this list is of great help for me to be a good mailop. thank you.



Now the question:



Is it bad - in terms of reputation - when domain in dkim-header (d=...) differs 
from senders address?

signing is done correctly and pub-key is present at domain of corse - specified 
with d=...



like d=mydomain.com

Sender is Stefan 



And how is it with subdomains?



d=mydomain.com

Sender is Stefan 



I could not find anything in the RFC.



Thank you.



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

[mailop] winmail.dat TNEF - howto behave?

2019-11-14 Thread Stefan Bauer via mailop

Hi,



we run some antispam-mailservers with ~ 10.000 mails / day for our customers.



Due to emotet and stuff, we started blocking some file extensions with great 
success. Sometimes "bad" attachment slip through as they are encoded by TNEF.

Our spamfilter is not able to de-code it. Not even some of our Mailcliens can 
read the attachments at the end.



How do you treat "TNEF-mails" in your environment?



blocking doesnt sound right but sometimes i feel lilke i should just to show 
that proprietary stuff is bad.



Thank you.



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

[mailop] Avoiding bounces - custom spamfilter behind real-spamfilter that reject mails

2019-10-24 Thread Stefan Bauer via mailop

Hi,



here is a thing, that we do not see a real solution to it and would be happy, 
to get some ideas from other mailops.



We are doing MX-spamfilter service for some customers and forward "clean" mails 
to customer mailservers.

We are doing recipient-checks before accepting mails.



Sometimes, customers feel clever and have another local mailfilter on site, 
that rejects mails, after we already have accepted them at spamfilter level.



So the reject generates bounces at our spamfilters. Howto handle this?




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

[mailop] No SMTP-Auth in Office365 Mailflow Connectors - seriously Microsoft?

2019-06-14 Thread Stefan Bauer via mailop

Hi,



can anyone confirm that I'm just blind or that this is not possible with 
Microsofts Exchange Online (Office365) cloud solutions?



This works fine in all on-premise installations. I can not specify 
username/password for smtp authentication nor any certs.



I just want to set outgoing mails to smarthosts with authentication.



Any MS admin around that can elaborate on this?



I'm baffled.



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

Re: [mailop] Microsoft blacklisting a /16

2019-06-05 Thread Stefan Bauer via mailop

Please keep this on-list. This is of great help for all other mailops to 
improve own setup.

Thank you.



-Ursprüngliche Nachricht-
Von: Hetzner Blacklist via mailop 
Gesendet: Mittwoch 5 Juni 2019 17:43
An: mailop@mailop.org; Michael Peddemors 
Betreff: Re: [mailop] Microsoft blacklisting a /16



Hi Michael,

thanks for your post. Even if it doesn't really help with the issue
we're having, you make some great points (as usual). I thought I'd
respond to a few, in the hope this doesn't derail the reason for my
initial post.

> Hehehe.. how does that saying going about the "pot calling the kettle
> black"?

I was well aware of the schadenfreude this would cause on here, so you
can imagine how annoying this situation is for me to post anyway.

> (And please, no comments about GDPR, GDPR allows you to publish
> information if their is a legitimate reason, and the customer permits it.)

You've hit the nail on the head... "if the customer permits it". We've
had this discussion before, so I thought you knew that we have rwhois,
it's simply an opt-in system that many customers don't opt-in to.

> Will comment that your IP Space 'appears' to be improving recently,

I'm very glad to hear that :)

> but still, steps can be performed easily to improve this..

I would love to hear about these easy steps. I have a long list of
improvements I'm trying to push through here, and if there are some easy

things I'm forgetting or overlooking, I'd like to know. I'd be happy to
take this off-list.

Kind regards

Bastiaan van den Berg
-
Hetzner Online GmbH


Am 05.06.2019 um 16:37 schrieb Michael Peddemors via mailop:
> Hehehe.. how does that saying going about the "pot calling the kettle
> black"?  But aside from comments about what people are saying about
> Azure
> 
> It really is when those /28's start firing up on your network.. I would
> 'like' to say it is a problem with vetting new customers, however I
> can't...  There is no SWIP information on those ranges..
> 
> Do remember, SWIP/rwhois does help let others know when a customer got

> their IP space, helps both your good customers, and helps others
> determine what is the issue when sudden traffic trips the switches..
> 
> (And please, no comments about GDPR, GDPR allows you to publish
> information if their is a legitimate reason, and the customer permits it.)
> 
> Will comment that your IP Space 'appears' to be improving recently, but
> still, steps can be performed easily to improve this..
> 
> Technically, it should be easier for you to notice the bad apples than

> it is for the rest of the world, with simple small things.. But this is
> still a real problem at some of the largest *cough* providers as well.

> 
> The internet is a scary place, and whether it is rhetoric from
> politicians around the globe, or those involved in the infosec
> community, I expect to see a lot more cases where the idea's of openness
> on the internet, becomes more about putting up 'walls' first..
> 
> -- Michael --
> 
> PS.. hehehe.. had a chuckle.. love this email header..
> 
> X-TnetOut-SpamCheck: no es spam, Unknown
> 
> "No es spam Senor!"  reminds of old cartoon lines..
> 
> 
> 
> 
> On 2019-06-05 4:25 a.m., Hetzner Blacklist via mailop wrote:
>> Hello Mailop,
>>
>> For the past two years things have been going really well for us in
>> regards to the Microsoft blacklist. We've had very few issues, probably
>> because we aggressively check the SNDS and block/terminate IPs/clients
>> that send spam to Microsoft. Now, all of a sudden and without warning,
>> Microsoft has blacklisted the entire range 5.9.0.0/16.
>>
>> Just to show how extreme that is, of our almost 1.4 million IPs,
>> Microsoft has currently blacklisted 70,390, of which 65,496 are from the
>> range above. So without that range, Microsoft would have around 5,000

>> blacklisted IPs (a number I'm very proud of considering three years ago
>> that was at 380,000).
>>
>> I, along with many customers, have sent delist requests to Microsoft,

>> but only a handful of them have been accepted. Even the escalations team
>> (the actual humans) can't help. I don't understand why, and am looking
>> for answers, as are the confused/angry customers contacting us about
>> this.
>>
>> I'm hoping I can reach Michael Wise through this post, since I don't see
>> any other way of clarifying this situation. If anybody else has any tips
>> or advice though, I would obviously appreciate that as well.
>>
>> Please note that I fully understand (and support) blacklisting single

>> IPs, and can understand why blacklists like Microsoft do escalation
>> listings of /24s. The question here is about an entire /16.
>>
>> Kind regards
>>
>> Bastiaan van den Berg
>> -
>> Hetzner Online GmbH
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
> 
> 
>

Re: [mailop] Howto be a good mailop (best practice / insights wanted)

2019-05-31 Thread Stefan Bauer via mailop

Hi Ken,

yes - thank you. I will then go with

Complaints-To: ab...@address.here - even though havent seen this header in the 
wild anywhere so far.

Stefan

-Ursprüngliche Nachricht-
Von: Ken O'Driscoll via mailop 
Gesendet: Freitag 31 Mai 2019 13:55
An: mailop@mailop.org
Betreff: Re: [mailop] Howto be a good mailop (best practice / insights wanted)

On Fri, 2019-05-31 at 11:03 +, Stefan Bauer via mailop wrote:
> Hi Ken,
> 
> thanks again for your input. Regarding
> Add a custom header (X-abuse)
> 
> is this really a thing? Could not find many mails in my inbox with that
> header present at all nor any official recommendations about that.
> Stefan

Hi Stefan,

Yes, it is fairly popular with ESPs (X-Report-Abuse, X-Complaints-To are

fairly common sights). Also web hosting providers and commercial SMTP
services (like you) tend to add a few custom headers to identify specific
subscribers. It's not universal by any means but I'd recommend it for the
service you're offering.

And, to to be fair, RFC 6648 (which is a best practice not a standard)
depreciates the use of the "X-" prefix in favour of general meaningful
custom headers (e.g. Complaints-To) so doing that is probably better.

Does that answer your question?

Ken.

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

Re: [mailop] Howto be a good mailop (best practice / insights wanted)

2019-05-31 Thread Stefan Bauer via mailop

Hi Ken,

thanks again for your input. Regarding

Add a custom header (X-abuse)

is this really a thing? Could not find many mails in my inbox with that header 
present at all nor any official recommendations about that.

Stefan

-Ursprüngliche Nachricht-
Von: Ken O'Driscoll via mailop 
Gesendet: Mittwoch 8 Mai 2019 20:01
An: mailop@mailop.org
Betreff: Re: [mailop] Howto be a good mailop (best practice / insights wanted)

On Wed, 2019-05-08 at 16:45 +, Stefan Bauer via mailop wrote:
> we have in place:
> 
> only allow pre-defined sender-addresses after auth
> monitor mail-queues for high connection count
> monitor RBLs if we're listed
> only allow single mail / 5s to be sent outgoing
> anti-virus checking of attachments

Hi Stefan,

off the top of my head I would add:

 * Monitor abuse@ and make sure that this address a) exists for your client
   domains and b) you receive a copy of messages sent to them.
 * Restrict access to the submission port to either the client IP range.

 * Lock accounts after X failed logins and get an alert about that.
 * Have a third (failover/fallback) sending capability with a different
   data centre. Periodically route enough email though that to ensure that
   it will not be throttled in case you need it. But, don't use it as a
   primary.
 * Understand what your normal usage profile looks like - graph the mail

   queues. This will help you build policies / tech. around detecting
   unusual behaviour. E.g. tougher throttling outside of business hours
   etc.
 * Add a custom header (X-abuse) to make it clear where the email came from
   and how to report abuse of your service.
 * Make it clear on your website how a non-customer can contact you to
   report abuse.
 * Run a cut-down spam filter on the outbound mails (look for stuff like

   freemail reply to addresses, fuzzy checksum hits, spam URLs). Some of

   that will be false positives so just put it into a holding queue and
   create a service desk ticket for it to be reviewed.
 * Have a clear upgrade path if case they wish to send marketing emails. If
   you don't, they will just try to send them through your platform.
 * Publish an Acceptable Use Policy (AUP) and make them agree to it as a

   pre-condition to using your service. Spamhaus have a good template to

   start from on their website.
 * Monitor bounces and tie that it with your monitor solution.
 * Monitor the health of your clients connecting IPs (and possibly
   website). Any indication of a compromised site is grounds for locking

   the account until a human can review. 
There is likely more, above is, as I said, off the top of my head. Good
luck.

Ken.

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

Re: [mailop] Howto be a good mailop (best practice / insights wanted)

2019-05-09 Thread Stefan Bauer via mailop

Hi Ken,

awesome. Thats a bunch of helpful steps! Thanks a lot!

Cheers

Stefan

-Ursprüngliche Nachricht-
Von: Ken O'Driscoll via mailop 
Gesendet: Mittwoch 8 Mai 2019 20:01
An: mailop@mailop.org
Betreff: Re: [mailop] Howto be a good mailop (best practice / insights wanted)

On Wed, 2019-05-08 at 16:45 +, Stefan Bauer via mailop wrote:
> we have in place:
> 
> only allow pre-defined sender-addresses after auth
> monitor mail-queues for high connection count
> monitor RBLs if we're listed
> only allow single mail / 5s to be sent outgoing
> anti-virus checking of attachments

Hi Stefan,

off the top of my head I would add:

 * Monitor abuse@ and make sure that this address a) exists for your client
   domains and b) you receive a copy of messages sent to them.
 * Restrict access to the submission port to either the client IP range.

 * Lock accounts after X failed logins and get an alert about that.
 * Have a third (failover/fallback) sending capability with a different
   data centre. Periodically route enough email though that to ensure that
   it will not be throttled in case you need it. But, don't use it as a
   primary.
 * Understand what your normal usage profile looks like - graph the mail

   queues. This will help you build policies / tech. around detecting
   unusual behaviour. E.g. tougher throttling outside of business hours
   etc.
 * Add a custom header (X-abuse) to make it clear where the email came from
   and how to report abuse of your service.
 * Make it clear on your website how a non-customer can contact you to
   report abuse.
 * Run a cut-down spam filter on the outbound mails (look for stuff like

   freemail reply to addresses, fuzzy checksum hits, spam URLs). Some of

   that will be false positives so just put it into a holding queue and
   create a service desk ticket for it to be reviewed.
 * Have a clear upgrade path if case they wish to send marketing emails. If
   you don't, they will just try to send them through your platform.
 * Publish an Acceptable Use Policy (AUP) and make them agree to it as a

   pre-condition to using your service. Spamhaus have a good template to

   start from on their website.
 * Monitor bounces and tie that it with your monitor solution.
 * Monitor the health of your clients connecting IPs (and possibly
   website). Any indication of a compromised site is grounds for locking

   the account until a human can review. 
There is likely more, above is, as I said, off the top of my head. Good
luck.

Ken.

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

[mailop] Howto be a good mailop (best practice / insights wanted)

2019-05-08 Thread Stefan Bauer via mailop

Hi,



we're providing a small smtp sent-service for our customers (via submission 
port / auth only - postfix). ~ 7.000 outgoing mails / day (via 2 hosts in 
different data centers/ip networks).



As the amount of mails increase, we would like to be ready for



- stolen auth-data to our service is used for sending spam



- broken clients send thousand of mails/minute



- one of our pub-ips get blacklisted / rerouting traffic?



- ISPs block our complete provider networks (and we are included)



- Perm-blocks with 5xx, always return all 5xx to senders?





How do you guys prepare yourself for this?



we have in place:



only allow pre-defined sender-addresses after auth

monitor mail-queues for high connection count

monitor RBLs if we're listed

only allow single mail / 5s to be sent outgoing

anti-virus checking of attachments



Would be awesome to get some insight how "big sites" handle this and maybe 
other cases.



Thank you!



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

53 matches

Mail list logo