Hi Patrick,
Not quite and in some ways I wish it were like you suggested.
World -> uni (mxin/spam|av/mxout) -> o365 -> uni (mxin/spam|av/mxout) -> google
As I said originally we treat O365 simply as a mail store as if it were an on site Exchange service - except obviously it is in the cloud. This allows us to ensure that we apply the same policies to outbound email as we do to inbound (including av and spam checking) - this is considered as "reputation management". Letting O365 send straight outbound - means that we have little control of what it is actually up to particularly if an account has been nobbled and we want to stop a user sending mail outbound rather quickly.
Admittedly it is a long way round to get anywhere and having lots of MX hosts makes things look a whole lot more complicated than they are as the MXs have very specific jobs to do - so if/when mail gets backed up I usually have a good idea of why based on where any queue is.
So when google generates the MDF it goes to mxout (as part of the SMTP transaction) - which then sends it round to mxin and so back to the beginning of the pipeline. It is all made worse by our addresses in O365 actually being something like: paul27@??? - so by the time the address has been rewritten any sense of the original inbound mail and any MDF due to the forwarding issue is a right pain to correlate.
Cheers
Paul Osborne
Senior Systems Engineer
Canterbury Christ Church University
Tel: 01227 782751
________________________________________
From: Exim-users <exim-users-bounces+paul.osborne=canterbury.ac.uk@???> on behalf of Patrick von der Hagen <patrick.hagen@???>
Sent: 19 October 2015 11:03
To: exim-users@???
Subject: Re: [exim] Sender rate limiting based on recipient address?
Hi Paul,
I got some issues understanding the mail flow in your situation. Just to
make sure:
world -> university -> o365 -> google
If the google-account was deleted/disabled, why would google generate an
MDF? The mail should be rejected by google, so not "leaving" o365? And I
would expect o365 to have procedures in place to handle it? How are your
servers involved at all?
On 16.10.2015 16:50, Osborne, Paul (paul.osborne@???) wrote:
> Hi,
>
> I have had a slightly odd situation where a member of the university
> (best leave it at that) has decided that they do not like our O365
> offering (which we treat effectively as a mail store) and decided
> that they wanted to forward their email to Google. This in itself is
> not a particular issue and worked fine.
>
> Then at some point their Google account was deleted (no idea why and
> don't really care) at which point the forwarder in O365 continued to
> forward email to Google which generated a MDF that came back with an
> ensuing game of email ping pong that resulted in us getting black
> listed for a time.
>
> Sadly due to address rewriting going on and new emails being
> generated for the forwards coming out of O365 (rather than a true
> message bounce) getting this spotted as a mail loop has proven to be
> a challenge.
>
> We do have sender rate limiting in place - however people higher up
> the food chain than me have insisted it is set the same as O365 to
> give parity of user experience. The downside of this is that O365
> rate limiting is apparently set to: 10,000 recipients per day and 30
> messages a minute. So pretty much low enough to be useless.
>
> https://technet.microsoft.com/en-gb/library/exchange-online-limits.aspx#RecipientLimits
>
> At this point I am thinking about implementing rate limiting on the
> basis of a sender being able to send X number of mails per unique
> recipient email address per day - to reduce the flow enough so that
> things start to back up a bit internally and my monitoring can spot
> when this happens.
>
> However looking at the rate limiting config in Exim although I can it
> seems limit the amount of recipients that a sender can mail to, I
> cannot see that I can limit the amount of mails that a user can send
> to individual recipients. It may be the case that I am failing to
> parse the documentation and for that I apologise, but if anyone has a
> suggestion on how to do this I would appreciate it.
>
>
> Cheers
>
> Paul
>
>
--
Karlsruher Institut für Technologie (KIT)
Steinbuch Centre for Computing (SCC)
Patrick von der Hagen
Zirkel 2, Gebäude 20.21, Raum 004.2
76131 Karlsruhe
Telefon: +49 721 608-46433
E-Mail: hagen@???
Web:
http://www.scc.kit.edu
KIT - Universität des Landes Baden-Württemberg und
nationales Forschungszentrum in der Helmholtz-Gemeinschaft
