[asterisk-users] sedwards at sedwards.com causes me to be knocked off the list

[Dave Platt]

> 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 accepted
normally (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.