4

RFC6761 states about example domains (such as example.com):

Application software SHOULD NOT recognize example names as special and SHOULD use example names as they would other domain names.

Currently, these example domains are set up with a webserver that explains their purpose. The domains lack any MX records; it doesn't have a null MX record either. Because of this, an MTA will try to deliver mail to the A record, which is the IP of the web server, which doesn't accept mail, causing mail to be queued on my MTA until it eventually expires.

Clearly, following RFC6761 doesn't work so well if you're a postmaster.

Are there disadvantages to rejecting all mail to example addresses? Are there any sources that have a recommendation about this?

EDIT For context: We automatically check queue size and if it gets too big someone has to manually check why that is happening. Lately this happens because of one application sending to example domains. Naturally, it should not do that and the correct solution is to fix the application, but that's not going to happen for reasons I won't get into. Since that is the situation, I feel rejecting mails in our mail filters is a better solution than ignoring mails in our alerting software.

FWIW: I agree with the "you should not need to do this" sentiment, but sometimes the world is not perfect.

jornane
  • 1,096
  • 1
  • 8
  • 25

1 Answers1

3

Most scenarios that could cause such mail to enter your systems fall into one of the following categories, none of which necessitates special treatment for example domains:

  1. Humans enter those domains on purpose to see whats going to happen.

    They should test using domain names under their control / having well-defined (not merely known/observed) records. A less useful results from a less useful test method should not concern you as postmaster.

  2. Applications erroneously configured with documentation examples send mail there, when they should have been configured to send mail somewhere else.

    Whoever committed such mistake should start receiving "Delayed Mail" warnings long before timeouts happen. The delay until the mails actually do expire in queue does not matter for the purpose of noticing such mistakes.

  3. Abuse of a public method of triggering mail causes resource exhaustion in your MTA.

    This must be dealt with for valid, mail-receiving domains anyway. The example domains are probably the least important target domains - they are the only recipients which will not rightfully complain about unsolicited mail.

  4. The events leading to such mail entering your systems cannot be resolved at their source, but their number is causing issues anyway.

    I believe most such issues can be avoided with better mail system configuration.

    • Is physical mail queue size becoming an issue?

      Your MTA should be prepared to queue all of your incoming mails for significant time; likely in relation to admin response time and/or queue expiration time. Again, no special treatment for example domains needed.

    • Are unnecessary contents of mail queue causing administrative overhead?

      I do not understand that recommendation to extend to filters the postmaster explicitly enters to help decide which delivery issues to review in detail. In any case, i highly recommend deploying tools that aggregate the mail queue statistics before passing them to monitoring / notifications to postmaster.

      Not just because it is annoying to repeatedly deal with false positives, also because it helps quickly estimate the gravity of real problems when you can immediately see "99% of the failures are related to this one provider".

anx
  • 6,875
  • 4
  • 22
  • 45