On 09/13/2017 02:25 AM, Paul Smith wrote:
This changes if you have another MSA submitting to yours. We have this here when we have customers running our mail server software on their networks and send through our relay service. (They can't have their local mail server send direct because they don't want the hassle of handling all the stuff involved with doing that). We charge for this service based on usage, so they have a monthly allowance.
Your email teased an interesting (to me) thought from my brain.It sounds like you are describing a situation where there are really (effectively) two sending servers. (Terms in a moment.) The client's local mail server, which then sends through your (remote to the client) mail server.
I think it's easy to call the client's local mail server an MSA. But is your (remote to the client) mail server functioning as an MSA or MTA? IMHO your mail server is functioning like an MTA and not an MSA.
Which brings up the follow up question, is the client's MSA speaking to your MTA (?) on TCP port 25 or port 587 to avoid ISP's (justified) egress port 25 filters?
If the client is using TCP port 25 to talk to you, then IMHO your server is an MTA, hands down. If the client is using TCP port 587 to talk to you then someone could make an argument that your server is an MSA.
Which brings me around to thinking that different behaviors may be appropriate for different points.
I think that 4xy or 5xy are okay on real MSA that is accepting submissions from MUAs. However, I think that a 4xy is more appropriate for use between MTAs for the reasons that you outline in your email.
So, they may have 100 people sending mail to their MSA which then sends it to ours.
Seems sensible enough. I had a number of clients with local Microsoft Exchange and / or Mercury Mail servers in a similar configuration.
If they reach their send allowance, and we reject with a 4xx response then their MSA queues them up. Then, the local mail admin can contact us and say 'oops, we need to increase our sending allowance', we charge them a few quid more, and their MSA then sends all the messages with no more user interaction.If we reject with a 5xx response, then their MSA sends NDRs to all the users, who then have to re-send all the failed messages. That may be a lot of messages depending on how they have their MSA set up and how busy they are. The users won't know what is going on (you can't expect them to read the NDR), so they'll waste their time trying to resend when it's just going to fail again. So, the mail admin gets hassled by users, and has to get in touch with each of them and walk them through how to read NDRs, how to check whether messages were sent or not, and how to re-send messages, the user may even have to rewrite messages from scratch depending on how they have things set up.
That all makes perfect sense and matches my experience. IMHO the 4xy is a MUCH better experience for all parties involved.
...for the MSA to MTA communications.
So, we use 4xx when rejecting due to send limits, because it's less hassle for the users (and admins) in this situation.To be honest, whether an MSA rejects a message with a 4xx or a 5xx response, I'd expect the MUA to alert a user that the message can't be sent.
I expect that there will be a non-normal (read: send and don't alert the user) process. Sadly I've quit expecting (or even hoping) that the MUA will give any meaningful message to the end user, much less expect that said end user(s) will relay that message to me.
I wouldn't expect an MUA to queue up messages which failed with a 4xx response because that's not what the user would expect to happen. But, maybe that's a bit optimistic of me.
I've seen a number of MUAs that will leave the message in the Outbox. However that doesn't mean that the MUA will automatically re-try to deliver the message. Sometimes it will, other times the end user must get involved. Either way, it is a bad experience for the end user.
So, I'd say reject with a 4xx response because MUAs should tell the user immediately and MSAs should automatically resend the messages when the problem is resolved.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
