Fall back to relay after a 5XX reply from destination?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Fall back to relay after a 5XX reply from destination?

Luc Pardon
Hello,

I've been running a small volume Postfix mail server on a fixed IP for
15+ years or so.

Recently, my provider forced me from ADSL (being phased out here) to
VDSL, and I now find myself sending mail from a "dynamic" IP address...

As expected, some destinations refuse to accept my outgoing mail with a
550 (usually with a "you're blacklisted" message on top of it).


So, I am now looking for some magic that would make Postfix:

a) first attempt to deliver outgoing mail straight to the destination MX
(as it does now), and,

b) if that fails with a "550 Bad IP" (or equivalent), fall back to my
ISP relay server and send it through them.


These 2 steps would have to happen for each message separately, every
time. Even if the destination doesn't like my IP right now, it might
accept it in a few hours from now (happened this morning).

Ideally, that mechanism should be able to "predict" if it's worth a
relay attempt. For example, relaying will (hopefully) fix a "550 This IP
is blacklisted", but it won't help with a "550 No such user".


The "smtp_fallback_relay" param does not seem suitable for this, as the
destination host *can* be found and *is* reachable, it's just being rude
to me <g>.

I am currently "fixing" it with a transport map for the "rude" domains
(such as postfix.org <g>), but that is only a stopgap measure. If my IP
changes next week, other domains may dislike the new one although they
had no problems with the one before it.

Relaying *all* the outgoing mail through my ISP is *not* an option. As
long as the message sits on my own box, I can see what's going on (e.g.
greylisting). And if it's handed from here to the destination directly,
I have all the details on hand to help them debug it at their end. But I
loose all that control when I hand the message over to my ISP.

So please, no philosophical arguments, I promise I won't be impressed <g>.

To paraphrase: relaying through my ISP *must* be kept to an absolute
minimum, along the lines described above.



The question is: does Postfix have something like this ?

Or do I have to write something myself? If yes, any suggestions?

I have been RTFM, peeking in the smtpd.c client source, pondered about a
special bounce handler (to detect "bad IP" and forward to my ISP),
thought of playing with "smtp_dns_reply_filter" (add the relay server at
the end of the "real" MX's) etc., but had no "AHA!" experiences yet.

I will continue my search, but I thought I'd ask here as well, just in
case this wheel has been invented already.

If not, building a new one would certainly be cheaper (for me) than
obtaining a fixed IP. If available at all, they cost an arm and a leg
over here. Better keep my 2 arms and use them to type some code

NB: I'm running Postfix 3.2.0 now. Upgrading to 3.3.1 is planned, but
(from the readme) currently as low priority.

Many thanks in advance,

Luc
Reply | Threaded
Open this post in threaded view
|

Re: Fall back to relay after a 5XX reply from destination?

Wietse Venema
Luc Pardon:

> Hello,
>
> I've been running a small volume Postfix mail server on a fixed IP for
> 15+ years or so.
>
> Recently, my provider forced me from ADSL (being phased out here) to
> VDSL, and I now find myself sending mail from a "dynamic" IP address...
>
> As expected, some destinations refuse to accept my outgoing mail with a
> 550 (usually with a "you're blacklisted" message on top of it).

And if they were to accept your email, they may very well deliver
your message to the spam folder, because you are sending from an
inappropriate IP address.

> So, I am now looking for some magic that would make Postfix:
>
> a) first attempt to deliver outgoing mail straight to the destination MX
> (as it does now), and,

See http://www.postfix.org/postconf.5.html#soft_bounce to change
5xx into 4xx.  Instead of setting it globally in main.cf, you can
set it in master.cf as:

/etc/postfix/master.cf:
    smtp unix ..other stuff.. smtp
        -o soft_bounce=yes

> b) if that fails with a "550 Bad IP" (or equivalent), fall back to my
> ISP relay server and send it through them.

See http://www.postfix.org/postconf.5.html#smtp_fallback_relay to
add the ISP as a safety net.

Of course that same soft_bounce feature would prevent mail from
being bounced by the ISP as well.

If you really care that people see your email, spend the bucks for
a real IP address, or send all mail through an ISP.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Fall back to relay after a 5XX reply from destination?

Matus UHLAR - fantomas
In reply to this post by Luc Pardon
On 26.07.18 13:38, Luc Pardon wrote:
>Recently, my provider forced me from ADSL (being phased out here) to
>VDSL, and I now find myself sending mail from a "dynamic" IP address...

is it really dynamic? Was the previous one dynamic?
If not, ask them to assign you a DNS name that does NOT look like dynamic
(and is not listed in dynamic dns blacklists).

Wietse told you the rest. Imho there's no point in playing with what you
propose inatead of fixing the IP reputation.
 
--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Posli tento mail 100 svojim znamim - nech vidia aky si idiot
Send this email to 100 your friends - let them see what an idiot you are
Reply | Threaded
Open this post in threaded view
|

Re: Fall back to relay after a 5XX reply from destination?

John Stoffel-2
>>>>> "Matus" == Matus UHLAR <- fantomas <[hidden email]>> writes:

Matus> On 26.07.18 13:38, Luc Pardon wrote:
>> Recently, my provider forced me from ADSL (being phased out here) to
>> VDSL, and I now find myself sending mail from a "dynamic" IP address...

Matus> is it really dynamic? Was the previous one dynamic?
Matus> If not, ask them to assign you a DNS name that does NOT look like dynamic
Matus> (and is not listed in dynamic dns blacklists).

Matus> Wietse told you the rest. Imho there's no point in playing with what you
Matus> propose inatead of fixing the IP reputation.

Or do what I do and spin up a Digital Ocean droplet for $6/mo that
lets me run postfix/dovecot and my own domain (DNS costs extra, of
course) to handle all my email needs for my private domain.

John

Reply | Threaded
Open this post in threaded view
|

Re: Fall back to relay after a 5XX reply from destination?

Matus UHLAR - fantomas
>Matus> On 26.07.18 13:38, Luc Pardon wrote:
>>> Recently, my provider forced me from ADSL (being phased out here) to
>>> VDSL, and I now find myself sending mail from a "dynamic" IP address...

>>>>>> "Matus" == Matus UHLAR <- fantomas <[hidden email]>> writes:
>Matus> is it really dynamic? Was the previous one dynamic?
>Matus> If not, ask them to assign you a DNS name that does NOT look like dynamic
>Matus> (and is not listed in dynamic dns blacklists).
>
>Matus> Wietse told you the rest. Imho there's no point in playing with what you
>Matus> propose inatead of fixing the IP reputation.

On 26.07.18 11:14, John Stoffel wrote:
>Or do what I do and spin up a Digital Ocean droplet for $6/mo that
>lets me run postfix/dovecot and my own domain (DNS costs extra, of
>course) to handle all my email needs for my private domain.

or do what I do and have own dedicated server in ISP's hosting centre
running own services...

well, everyone has their possibilities.
if an ISP forces aDSL user to vDSL, they should take care of things like
blacklists and DNS records.

Anyway, whole point of this discussion that working around problems by
violating RFC and re-sending hardly (5xx) refused mail through an ISP is not
way to go.

and thus it's not problem to solve at postfix level, unless you of course
configure (temporarily) your ISPs mailserver as relayhost.


--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Holmes, what kind of school did you study to be a detective?
- Elementary, Watson.  -- Daffy Duck & Porky Pig
Reply | Threaded
Open this post in threaded view
|

Re: Fall back to relay after a 5XX reply from destination?

John Stoffel-2
>>>>> "Matus" == Matus UHLAR <- fantomas <[hidden email]>> writes:

Matus> On 26.07.18 13:38, Luc Pardon wrote:
>>>> Recently, my provider forced me from ADSL (being phased out here) to
>>>> VDSL, and I now find myself sending mail from a "dynamic" IP address...

>>>>>>> "Matus" == Matus UHLAR <- fantomas <[hidden email]>> writes:
Matus> is it really dynamic? Was the previous one dynamic?
Matus> If not, ask them to assign you a DNS name that does NOT look like dynamic
Matus> (and is not listed in dynamic dns blacklists).
>>
Matus> Wietse told you the rest. Imho there's no point in playing with what you
Matus> propose inatead of fixing the IP reputation.

Matus> On 26.07.18 11:14, John Stoffel wrote:
>> Or do what I do and spin up a Digital Ocean droplet for $6/mo that
>> lets me run postfix/dovecot and my own domain (DNS costs extra, of
>> course) to handle all my email needs for my private domain.

Matus> or do what I do and have own dedicated server in ISP's hosting centre
Matus> running own services...

*grin*  That too!

Matus> well, everyone has their possibilities.  if an ISP forces aDSL
Matus> user to vDSL, they should take care of things like blacklists
Matus> and DNS records.

Matus> Anyway, whole point of this discussion that working around
Matus> problems by violating RFC and re-sending hardly (5xx) refused
Matus> mail through an ISP is not way to go.

Matus> and thus it's not problem to solve at postfix level, unless you
Matus> of course configure (temporarily) your ISPs mailserver as
Matus> relayhost.

True... in my experience here in the US, trying to send personal
domain email via ISP's mailservers is just not going to work ever.

It's a pain at times, but hosting it myself is good experience.
Reply | Threaded
Open this post in threaded view
|

Re: Fall back to relay after a 5XX reply from destination?

Luc Pardon
In reply to this post by Wietse Venema
First off, thanks for reading and replying to the real question, as always.

> And if they were to accept your email, they may very well deliver
> your message to the spam folder, because you are sending from an
> inappropriate IP address.

   True, but there are many _other_ reasons why "they" may think that my
message belongs in the spam folder.

   It is also not unheard of that a destination replies "OK" and yet
discards or looses the mail.

   These things happen all the time. If one can't live with that, better
not use e-mail at all.

   Also, IMHO a spam folder is meant for "in doubt" cases, so it is
supposed to be inspected regularly.

   Upon inspection, "they" can see at first sight that my mail is not
spam. At the very least, "they" can then release it. They also could
(and IMHO should) use it to improve their hit/miss rate.

   On the other hand, if people choose to use their spam folder as a
black hole, they may loose business. My business, or other people's
business, I don't care. Their choice, their problem, not mine.

   That doesn't mean I don't appreciate your heads-up.

   It only means that the risk is acceptable - to me and my specific
situation. But others may have a different situation (volume, mix of
mail etc.) and come to a different conclusion.


   As an aside, I have also read Ralf Hildebrandt's ten-year old
analysis of the issues of running a mail server on a dynamic IP, here:

  https://www.arschkrebs.de/postfix/postfix_why_dyndns_does_not_work.shtml

   His chapter on "receiving mail" was very helpful for my own thinking
through the risks involved, but here too the probability of his "worst
case" scenario is sufficiently low - in my case - to consciously accept
the risk of loosing some mail in that case.

   And implementing a test for the presence of a mail server on my old
IP (after the change-over) is now on my to-do list <g>.

   Luc
Reply | Threaded
Open this post in threaded view
|

Re: Fall back to relay after a 5XX reply from destination?

Luc Pardon
In reply to this post by Matus UHLAR - fantomas


On 26-07-18 17:19, Matus UHLAR - fantomas wrote:
> Anyway, whole point of this discussion that working around problems by
> violating RFC and re-sending hardly (5xx) refused mail through an ISP is
> not
> way to go.

No, the "whole point" of the discussion is *not* that I want to work
around just any 5xx problem.

The only "problem" that I am trying to solve is how to detect that the
other side is telling me to re-send through my ISP, so that I can oblige.

With other types of 5xx, I would of course let the mail bounce as usual.

In fact, if the other side replies with "5xx No such user", or "5xx
mailbox full", there is absolutely no point in re-sending through the relay.

That distinction might not be immediately apparent from the subject of
my message, but I thought it was clear enough from the body.


Let's say I go to a restaurant and get refused entry because I do not
wear a tie. So I go put on a tie, come gack to the restaurant and am now
allowed in because I'm no longer violating their dress code.

That is, I am willing to put on a tie, but only if/when the restaurant
requires it.

Otherwise, I prefer to go out eating tie-less, and will do so if the
restaurant allows it.

How is that a Bad Thing?


Translated: if/when some server refuses my mail with a "5xx no
dynamics", meaning "please relay through your ISP", I am willing to
comply with their access policy.

OTOH, if the destination has no problems with direct delivery from a
dynamic IP, I prefer to use that method.

How is that a Bad Thing?


Anyhow, by now I have scripted a solution to do just that.

Technically, it works. I'll see what happens in practice.


Luc


Reply | Threaded
Open this post in threaded view
|

Re: Fall back to relay after a 5XX reply from destination?

Wietse Venema
Luc Pardon:

>
>
> On 26-07-18 17:19, Matus UHLAR - fantomas wrote:
> > Anyway, whole point of this discussion that working around problems by
> > violating RFC and re-sending hardly (5xx) refused mail through an ISP is
> > not
> > way to go.
>
> No, the "whole point" of the discussion is *not* that I want to work
> around just any 5xx problem.
>
> The only "problem" that I am trying to solve is how to detect that the
> other side is telling me to re-send through my ISP, so that I can oblige.
>
> With other types of 5xx, I would of course let the mail bounce as usual.

Conceivably, you could use the smtp_delivery_status_filter feature
to selectively replace 5xx responses with 4xx if the receiver does
not say things that look like 'user unknown'.

    # Example for single-line server responses.
    # If you add support for multiline replies, remember that the
    # Postfix SMTP client uses the SMTP status from the last line.
    if !/user unknown|unknown user|[^0-9]5\.1\.1[^0-9]/
    /^5(.+)$/ 4$1
    endif

Combined with smtp_fallback_relay=[mail.isp.com], this would punt
potentially resendable mail to the ISP.

        Wietse


Reply | Threaded
Open this post in threaded view
|

Re: Fall back to relay after a 5XX reply from destination?

Bill Cole-3
In reply to this post by Luc Pardon
On 6 Aug 2018, at 14:12, Luc Pardon wrote:

> On 26-07-18 17:19, Matus UHLAR - fantomas wrote:
>> Anyway, whole point of this discussion that working around problems
>> by
>> violating RFC and re-sending hardly (5xx) refused mail through an ISP
>> is
>> not
>> way to go.
>
> No, the "whole point" of the discussion is *not* that I want to work
> around just any 5xx problem.
>
> The only "problem" that I am trying to solve is how to detect that the
> other side is telling me to re-send through my ISP, so that I can
> oblige.

That is NEVER the message of ANY 5xx reply. ANY 5xx reply ALWAYS
indicates that you should not resend automatically. Really. Read RFC5321
and its ancestors.

You should expect that at some point your workaround will be detected,
deemed abusive, and actively countered so that you cannot deliver your
mail by any means to some places. That may be done silently, since it is
entirely fitting that violation of basic interop rules be met with the
same.



Reply | Threaded
Open this post in threaded view
|

[SOLVED] Re: Fall back to relay after [some] 5XX repl[ies] from destination?

Luc Pardon
In reply to this post by Wietse Venema
(Please note that I also changed the remainder of the subject line to
try and avoid further confusion.)

On 06-08-18 20:48, Wietse Venema wrote:

> Luc Pardon:
>> The only "problem" that I am trying to solve is how to detect that the
>> other side is telling me to re-send through my ISP, so that I can oblige.
>>
>> With other types of 5xx, I would of course let the mail bounce as usual.
>
> Conceivably, you could use the smtp_delivery_status_filter feature
> to selectively replace 5xx responses with 4xx if the receiver does
> not say things that look like 'user unknown'.
>

Yes, that was indeed what I ended up using (with the minor difference
that I go looking for strings like "blocked using ...", to be more
selective).

Thanks for confirming that this hook was the proper thing to look at.

> Combined with smtp_fallback_relay=[mail.isp.com], this would punt
> potentially resendable mail to the ISP.
>

I decided to work with transport maps instead, one per domain.

One of the reasons is that, if I already know that example.com doesn't
like my current IP, it doesn't feel right to keep trying again and again
for each and every message. With a low traffic site like mine, the extra
load on example.com may be negligible, but in any case it serves no
useful purpose (unlike greylisting, SAV, etc.). Compare to my restaurant
example: if I know that they want me to wear a tie, it is only proper to
remember to put one on before I go there next time.

Another (very) important reason to _not_ use smtp_fallback_relay is
that, unless I am mistaken, *all* the deferred mail would go to the
relay, including mails that are being greylisted by domains that would
otherwise accept them directly from me after the greylist time.

That is Doubleplus Ungood, because - as I repeatedly said - I want to
avoid to relay if I can. Sending via an ISP in Belgium is asking for
trouble, believe me.


Bottom line, when my DSN filter detects one of the "blocked using ..."
tell-tale strings, it first creates the appropriate
"nexthop=mail.isp.com" transport map for the example.com domain, and
then it defers the mail by returning "4xx" instead of the original "5xx".

At the next attempt to deliver the mail to [hidden email], the
"example.com" transport map will be waiting for it.

Problem solved.



Of course, the disadvantage (for my purpose) of transport maps is
precisely that they are "static". Meaning, once the map for example.com
is in place, all the mail for them will go through "mail.isp.com"
forever and ever - until the map gets removed again.

Now, example.com may refuse my IP today, yet they may start to accept it
tomorrow, or next week, or whenever my (then current) IP is not (or no
longer) listed by the RBL's they consult.

This has happened before, even in the short time (a little over 2 weeks
now) that I was forced from static to dynamic, and even though I am
forcing a DSL reconnect every night, just to stress-test the whole thing.

So yes, it really can happen that example.com "changes their mind" over
time.

But because of the transport map, created at their first refusal, I
would keep sending through the relay for nothing, because they would now
accept direct delivery if I tried.


So I keep the maps in an SQL table and plugged a tcp_table map script
into the "transport_maps" hook.

If the table script finds an expired transport map for example.com, that
map will be ignored, and the mail will "go direct" again.

Time will tell how best to expire the maps, but anyway these details are
not relevant to get the overall picture.


You may wonder how the DSN filter knows how to insert a map for
example.com, since it doesn't know the intended recipient address?

Indeed, the filter map gets only queried with this:

    enhanced-status-code SPACE explanatory-text

And of course the explanatory text in this case does not usually mention
the recipient...

Taking that hurdle was actually the easier part of the job. A few minor
changes to the Postfix source code were enough to make the
dsn_filter_lookup() function (in global/dsn_filter.c) take an extra
"RECIPIENT *rcpt" parameter, so that it now can (and does) query the
maps with:

    recipient-address SPACE enhanced-status-code SPACE explanatory-text


Of course, this is a radically incompatible change that brutally breaks
all existing DSN filters big time, but I myself had no such filters
before, so there were none to break, and, as a private patch (applied
here on my own computer when I compile my own Postfix from source for my
own use), it serves me just fine.


So, as I said, problem solved.

It has been working fine for several days now. We'll see what happens in
the future.


Anyway, all it took was a handful lines of (mostly boilerplate) Perl code.

As to Postfix itself, it says much about the quality of the code that I
had only 9 lines to change and one to add (not including some comments
and one change to a debug statement).

All in all it was well worth the relatively small effort, if only to see
what the real issues are when sending mail from a dynamic IP...

Technical comments welcome, although I have left out a lot of irrelevant
details in the outline above.

Luc
Reply | Threaded
Open this post in threaded view
|

Greylisting (Was Re: Fall back to relay after [some] 5XX repl[ies] from destination?)

@lbutlr
On 07 Aug 2018, at 04:49, Luc Pardon <[hidden email]> wrote:
> but in any case it serves no useful purpose (unlike greylisting, SAV, etc.

Are people still finding grey listing to be useful? I found it caused far more problems than it solved and the endless game of scanning logs for sites like Amazon that resend from different machines or many banks that will never resend was time consuming and tedious.

--
If lawyers are disbarred and clergymen defrocked, doesn't it follow that
electricians can be delighted, musicians denoted?

Reply | Threaded
Open this post in threaded view
|

Re: Greylisting (Was Re: Fall back to relay after [some] 5XX repl[ies] from destination?)

Dominic Raferd


On Tue, 7 Aug 2018, 20:58 @lbutlr, <[hidden email]> wrote:
On 07 Aug 2018, at 04:49, Luc Pardon <[hidden email]> wrote:
> but in any case it serves no useful purpose (unlike greylisting, SAV, etc.

Are people still finding grey listing to be useful? I found it caused far more problems than it solved and the endless game of scanning logs for sites like Amazon that resend from different machines or many banks that will never resend was time consuming and tedious.

I gave it up a while ago and haven't missed it. The delayed delivery drove users wild.
Reply | Threaded
Open this post in threaded view
|

Re: Greylisting (Was Re: Fall back to relay after [some] 5XX repl[ies] from destination?)

Wietse Venema
In reply to this post by @lbutlr
@lbutlr:
> On 07 Aug 2018, at 04:49, Luc Pardon <[hidden email]> wrote:
> > but in any case it serves no useful purpose (unlike greylisting, SAV, =
> etc.
>
> Are people still finding grey listing to be useful? I found it caused =
> far more problems than it solved and the endless game of scanning logs =
> for sites like Amazon that resend from different machines or many banks =
> that will never resend was time consuming and tedious.

Not since I started using postscreen.

With postscreen 'after 220' checks turned off, a 'good' client gets
to talk to the Postfix SMTP server without having to reconnect.
This is what I have been doing since 2011 or so.

With postscreen 'after 220' checks turned on, a 'good' client has
to reconnect, which brings all the issues of greylisting. I found
that this blocked practically nothing that wasn't already blocked
otherwise.

Greylisting (whether in postscreen or otherwise) may still be an
option for sites that don't want to use DNSBLs.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Greylisting (Was Re: Fall back to relay after [some] 5XX repl[ies] from destination?)

Matus UHLAR - fantomas
In reply to this post by @lbutlr
>On 07 Aug 2018, at 04:49, Luc Pardon <[hidden email]> wrote:
>> but in any case it serves no useful purpose (unlike greylisting, SAV, etc.

On 07.08.18 13:57, @lbutlr wrote:
>Are people still finding grey listing to be useful? I found it caused far
> more problems than it solved and the endless game of scanning logs for
> sites like Amazon that resend from different machines or many banks that
> will never resend was time consuming and tedious.

I migrate greylisting towards postscreen (some clients still send unauth
mail through port 25, so it's not so easy)

whitelist is important with greylisting, but it's usually already settled.
Lyckily there's not much services connecting always from different IPs...

Postscreen provides BL scoring and pregreeting tests, and with after-220
checks provides something very similar to greylisting.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Eagles may soar, but weasels don't get sucked into jet engines.
Reply | Threaded
Open this post in threaded view
|

Re: Greylisting (Was Re: Fall back to relay after [some] 5XX repl[ies] from destination?)

Patrick Ben Koetter-2
In reply to this post by @lbutlr
* @lbutlr <[hidden email]>:
> On 07 Aug 2018, at 04:49, Luc Pardon <[hidden email]> wrote:
> > but in any case it serves no useful purpose (unlike greylisting, SAV, etc.
>
> Are people still finding grey listing to be useful? I found it caused far
> more problems than it solved and the endless game of scanning logs for sites
> like Amazon that resend from different machines or many banks that will
> never resend was time consuming and tedious.

Yes, I find it still useful, but I don't use it as a primary tool ever since
postscreen has landed. Actually I was very happy to send it back into line,
because it kills one of the most attractive features in email: instant
communication.

Nowadays we use it in rspamd, where it works as "dynamic greylisting" addon.
Whenever a certain threshold has been reached rspamd sends the client off to
greylisting. Any mail that stays below that threshold will not be subject to
greylisting.

I like that conditional behaviour better. It adds delay to email delivery only
when in doubt.

p@rick

--
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein