Dave Platt
2015-Jun-03 17:43 UTC
[asterisk-users] sedwards@sedwards.com causes me to be knocked off the list
> Someone on this list uses the address @sedwards.com > > I doubt this is their actual email address as there is no MX record for > sedwards.com and I can't find registration for their domain either. > > Part of my mail servers reject these emails because they cannot be > replied to, or are likely to be spam. > > Every so often I get a mail from the list management to say that I've > been unsubscribed because of excessive bounces and it takes a single > click to re-register. > > It's a bit of a niggle for me. What do you think I should do? Change my > servers so that I don't check sender domains?If the SMTP session is saying "MAIL FROM: <xxxxx at sedwards.com>", and if "sedwards.com" has no MX or A addresses on file with DNS, then I think it's appropriate to reject the mail at that stage, either permanently or temporarily. The latter is probably better in case there's a transient DNS problem. Your server should send an error message in response to the "MAIL FROM" command. The Asterisk mailing list servers should *not* be forwarding messages to list subscribers in this way. Most of the big mail providers are now performing SPF (or similar) validation on the "MAIL FROM" addresses, and will reject a lot of mail which is "reflected" through mailing-list servers. Current practice is for mailing-list servers to "rewrite" the sender address in the envelope (to a form which identifies their own domain as the intermediate relay/sender) or to just use an address such as "asterisk-users at list.digium.com" as the MAIL FROM address. Now... if you're digging into the message headers themselves (e.g. looking at the "From: " header) and rejecting the mail because the address therein isn't legitimate... that's a different issue and a bigger problem. Your mail server can't do this during the initial SMTP handshake... only after it accepts the entire message from the sending system. This creates an anomalous situation, because your server provisionally accepted the message (by saying OK to the MAIL FROM, RCPT TO, and DATA requests from the sender), and then rejected the message as undeliverable "at the last moment". Not a good thing, according to the SMTP spec, and it's not surprising that some servers will consider this a practice which justifies blocking further deliveries to your system. In this case, you'd be better off accepting the mail normally via SMTP, using your spam filter to "tag" it with a "suspicious" label, and the filing it in a "spam" folder or just discarding it after reception.>From the point of view of the sending system, it will have been acceptednormally (rather than rejected or bounced) . One thing you definitely should *NOT* ever do, is accept a mail message via SMTP (saying "OK"), determine that you think it's spam, and then have your mail server "mail back" a "rejected" bounce message to the sender. This is bad, bad, bad. It causes "back-scatter" - if mail is sent with a forged sender address (which is quite common) the poor schlub whose address was stolen for this purpose is likely to get a reject message for every copy of the forged mail. This can put a horrible burden on the victim's mail server.