Antonio,
While I understand your point, I think you have some misunderstandings
about how the "real" mail (snail-mail) works.
- If my address is 1234 Main St N, Anytown USA 12345 and you mail a
letter to 123 Main St, Sometown USA 12346 -- that letter will likely
*never *make it to *me *(You don't even have to bungle it in 3 places
like I did -- any SINGLE of those errors not just MAY, but PROBABLY
WILL, result in the failure of the INTENDED recipient getting the
letter. The days of your local postal carrier looking closely and
attempting (sometimes with great effort) to make the delivery to the
RIGHT PERSON are long (in some areas LONG LONG) since gone! If the
address is wrong, it'll be delivered to a nearby address (most likely
wrong), where it'll most likely be trashed. Want to test this? Send a
letter addressed to Daniel G McAllister, Saint Petersburg, FL 33712...
and see if you get anything back. (You won't -- and I won't get the
letter, either!)
/ - Sad but funny aside: a neighbor of mine got into trouble at
the US post office by self-reporting that she received mail
addressed to me, but improperly delivered to her. She was threatened
with a fine and/or jail time because she gave me the mail instead of
returning it to the post office for re-delivery./
- JUST like the mail service, there is no guarantee that an e-mail has
been delivered UNLESS you ask for delivery confirmation.
- UNLIKE the mail service, you can choose NOT to verify delivery in e-mail
- UNLIKE the mail service, email has ZERO security during the
transmission of your message. (essentially, the "envelope" is NOT sealed!)
- LIKE the mail, email only promises a "best effort" to deliver the
message -- and like mail, the definition of "best effort" has changed
over the years.
But you also mentioned RFCs, and believe me I am a believer in
RFCs...however:
- While SOME RFCs state that there should be REJECT messages sent,
there are others that state that dropping undeliverable messages is
equally valid (e.g.: RFC 5321, ca. 2008) which noted the increased
implementation of NOT bouncing undeliverable messages for multiple
reasons. While the RFC cautioned against being too aggressive in
dropping messages, I think that reference was more to the act of
dropping SPAM and other "legitimately addressed" mail, based on content.
(And that is a DIFFERENT discussion)
NOTE: The RFCs also state that you should NOT accept RELAY mail on
port 25 (that is, outbound messages from users) [RFC 6409]. Unless
you're careful (and I am), QMAIL (and more specifically, QMT) violates
that RFC. Anyone know an ISP that blocks port 25 (Verizon residential)?
How about one that accepts mail on port 8080? (That's supposed to be for
non-root web servers) -- all "violations" of RFCs. But since RFCs are
there for "easy interoperability", so long as all of your own clients
know that you use port 8080 for SUBMISSION, you're perfectly OK.... you
just have to handle it when a client comes to you and says "my mail
program won't do that".
- RFCs are "standards" that are in place to make it easier for people
to send/receive data on the Internet without having to separately
negotiate and design the interfaces. They are not "laws" and not even
"rules"... they are more "guidelines"... what happens when you VIOLATE
RFCs is simply that you risk not being able to be easily accessed by
others... and in many cases (like the ESPs that use port 8080),
sometimes those "violations" are on purpose (to hide from abusers).
Another RFC that is broken OFTEN is the message coding for REJECT
messages -- 4.x.x messages are supposed to be for "delayed" delivery,
and 5.x.x messages for solid rejects. Also, the x and x values are
supposed to tell you the detailed REASON for the reject. Far too many
ESPs use "generic" failure reject messages, or will reject a message
with a 4.x.x result, or delay a message with a 5.x.x result... all in error.
FINALLY: I'm not against users(senders) getting information back, but
I'm also not about to _/facilitate /_/_abusers_ /in deceiving my
clients/users either. The BOUNCE mechanism isn't solely about address
phishing -- it is also abused by SPAMMERS who forge reply-to addresses
so that the "payload" SPAM is delivered as a BOUNCE message from a
legitimate server, even though the original source is illegitimate.
I adhere to some basic principles:
- properly addressed messages are ALWAYS delivered (even if SA gives
it a 100 score!).
- the only exceptions are when the sender's domain provides a
mechanism to validate the source & tells me to reject messages that
don't meet that validation. (This is what SPF, DomainKeys, DKIM, etc.
all try to do).
In that vein, I provide properly formatted and detailed REJECT messages
(so that a user might know why I rejected him as a sender), but I do NOT
provide BOUNCE messages.
The difference?
- a REJECT is a reply back to the original *sender's server*. I can be
reasonably certain I'm talking to the real server, as we're expecting to
trade TCP messages back and forth
- a bounce is a new message sent back to the person purporting to be
the sender. I have NO FAITH in the sender's self-reported address, so I
refuse to use it in ANY automated fashion - including, and especially,
bounce messages.
===
These are just my thoughts -- but after being an ESP (Email Service
Provider) for more than 15 years now, I'm pretty strong in my opinions!
Not that they haven't changed... they have! I used to have a single
catchall account for ALL of my domains, and I used to have a paid
staffer whose job was to cull through those emails to see if any could
be forwarded to their legitimate recipients. What a naive little nave I
was back then! :^)
I don't represent that "I'm right & you're wrong" -- I am only
describing what I do, and attempting to explain why... I'm a firm
believer in the free market (of ideas AND of money), and firmly believe
that the Internet would have FAILED if people hadn't bent, poked,
prodded, and occasionally broken things over the years in the name of
improvements!
Dan McAllister
IT4SOHO
Anyone else remember ROT13 as a way to "encode" NSFW content?
Abj vf gur orfg gvzr! :)
On 5/19/2014 5:05 PM, Tonix - Antonio Nati wrote:
Strange, I have an opposite opinion on the most of catch-all and
delete usage I'm reading here in this thread.
Personally, and as provider of email business, I consider catch-all
account useful only when you have a new domain, and customer does not
know which mailboxes were running. So you set up a catchall account
and start creating all necessary accounts, and stop catch-all when the
most of accounts are created.
About deleting all email for not existing users, I consider it a bad
service to customers, as they have legitimate raports with business
partners, and if someone writes to the wrong address it is correct and
ethical to report them back that address is wrong, so they can use
another way to contact the recipient, instead of waiting for never
coming reply messages.
More, the abuse of deletion and missing respect for RFC forces users
to ask always for delivery and read receipt, incrementing the volume
of useless emails.
About signing headers with authenticating sender address, is a must
because it makes senders responsable for what they are sending, and
the most of our business customers wants their domain to be used only
for legitimate emails,
Of course other opinions may be based on different needs, but I think
respect of RFC should always be at first place, otherwise people will
look soon for other stable and reliable message delivery methods.
Something I think often about: as email providers, we should look like
real postmen: we cannot read (intentionally I mean), lose, damage
others emails. Virus and SPAM must be fought, and apart real viruses
and real spam all the remaining MUST be delivered. Any not valid
damage or loss could be legally pursued.
Regards,
Tonino
Il 19/05/2014 21:10, Eric Shubert ha scritto:
On 05/19/2014 08:06 AM, Jim Shupert wrote:
How might one do - have a DELETE rule for badly addressed messages. I
just drop them and forget about it?
is it as easy as: " Set catchall email deleted " from admin
in truth ... i thought you HAD to have a catch all account -- yes - i
would rather not.
thanks
Personally, I use a catchall account for my domain, and I don't get
very much spam there at all. I do a few use a few tools for
mitigating this.
1) the badmailto file can specify addresses with a regex. So for
example, if your domain accounts don't contain numbers or whatever
special characters, or your accounts always follow a certain pattern,
you can write badmailto rules to reject these attempts. I used to get
a lot of spam with numbers in the account name, and eliminated them
witha few badmailto rules. This file can also be used to reject
messages to defunct accounts.
2) use spamdyke to blacklist local domains. This seems counter
intuitive, but so long as legit users always authenticate and only
send email via your server, this works nicely.
That being said, I can see where some domains would want to simply
delete these messages. While deleting messages goes against the RFCs,
doing so certainly appears to be a best practice. Some rules, while
well intended, have unintended consequences. I think this is one such
rule.
also that strategy of : " giving each user a separate mailbox name and
e-mail address "
yes , that is interesting -- I can see how that would work
....unfortunately in my current situation folks already have the
"configuration " that we have.
but maybe for a new bunch of folks a new domain
This is a most excellent method of managing user accounts. I've
considered doing this, but haven't actually implemented it yet. Along
these lines, I've also considered modifying the header record qmail
adds so that the authentication account isn't listed in its entirety.
This would help to protect the actual account name.
thanks for the food for thought ,,, a hardy meal.
jim
Thanks as well.
--
IT4SOHO, LLC
33 - 4th Street N, Suite 211
St. Petersburg, FL 33701-3806
CALL TOLL FREE:
877-IT4SOHO
877-484-7646 Phone
727-647-7646 Local
727-490-4394 Fax
We have support plans for QMail!
