3 ms·

I would say it's also important to receive mail on RFC2142 [1] addresses as well. I usually set up abuse@, hostmaster@, postmaster@, and webmaster@ for idle do

by ryan29 6y ago

I would say it's also important to receive mail on RFC2142 [1] addresses as well. I usually set up abuse@, hostmaster@, postmaster@, and webmaster@ for idle domains. 1. https://tools.ietf.org/html/rfc2142 https://tools.ietf.org/html/rfc2142

deleted 6y ago
[deleted]
gumby 6y ago
In 30+ years I have only received spam on any of those addresses. I suppose that means that "abuse" is appropriately named :-/ A couple of years ago I pointed them at /dev/null. I considered rejecting them but that would not be compliant.
- eli 6y ago
  I'm not sure I see the benefit in following the letter of the RFC but not the intent
  - gumby 6y ago
    In this case you’re right. I really doubt someone is probing the RCPT TO response to decide if a server is legit or not! Certainly there are protocols where you might be required to accept an option or configuration value you can’t implement and so simply discard it. Perhaps some QoS request for example. Or termcap info for cursor movement when all you do is act like you’re talking to a printing terminal.
  - technion 6y ago
    In this case there actually is a benefit. I've seen issues where people weren't able to communicate with customers because someone's running a mail server that rejects email based on the RFC-Clueless RBL or its predecessor, RFC-Ignorant[0]. I've never in history seen postmaster@domain every receive anything but spam, and I have seen it receive so much spam that I would never identify a legitimate email amongst the screens full of junk if one ever did arrive. [0] http://rfc-clueless.org/pages/faq http://rfc-clueless.org/pages/faq
TrueDuality 6y ago
That RFC by definition doesn't apply to domains that don't support email. Right in the abstract is this line: > ...organizations which support email exchanges with the Internet are encouraged to support AT LEAST each mailbox name These recommendations are all for domains that don't run mail servers. If you do have a mail server, then yeah it is best practice to have those present but these recommendations won't apply to you.

by ryan29 6y ago

deleted 6y ago

[deleted]

gumby 6y ago

In 30+ years I have only received spam on any of those addresses. I suppose that means that "abuse" is appropriately named :-/ A couple of years ago I pointed them at /dev/null. I considered rejecting them but that would not be compliant.

eli 6y ago
I'm not sure I see the benefit in following the letter of the RFC but not the intent
- gumby 6y ago
  In this case you’re right. I really doubt someone is probing the RCPT TO response to decide if a server is legit or not! Certainly there are protocols where you might be required to accept an option or configuration value you can’t implement and so simply discard it. Perhaps some QoS request for example. Or termcap info for cursor movement when all you do is act like you’re talking to a printing terminal.
- technion 6y ago
  In this case there actually is a benefit. I've seen issues where people weren't able to communicate with customers because someone's running a mail server that rejects email based on the RFC-Clueless RBL or its predecessor, RFC-Ignorant[0]. I've never in history seen postmaster@domain every receive anything but spam, and I have seen it receive so much spam that I would never identify a legitimate email amongst the screens full of junk if one ever did arrive. [0] http://rfc-clueless.org/pages/faq http://rfc-clueless.org/pages/faq

TrueDuality 6y ago

That RFC by definition doesn't apply to domains that don't support email. Right in the abstract is this line: > ...organizations which support email exchanges with the Internet are encouraged to support AT LEAST each mailbox name These recommendations are all for domains that don't run mail servers. If you do have a mail server, then yeah it is best practice to have those present but these recommendations won't apply to you.